Re: worktree add already exists

[Eric Sunshine <sunshine@sunshineco.com>]

On Mon, Jun 3, 2019 at 5:47 AM Duy Nguyen <pclouds@gmail.com> wrote:
> On Sun, Jun 2, 2019 at 2:11 PM Eric Sunshine <sunshine@sunshineco.com> wrote:
> > On Mon, May 27, 2019 at 11:32 AM Ingo Wolf <ingo.wolf@gmx.de> wrote:
> > > I would like to attach an existing dir to git (make it a workdir) and
> > > then update the index with git reset and checkin the differences.
> >
> > I haven't thought through the possible ramifications, but the actual
> > implementation might be as simple as changing this code in
> > builtin/worktree.c:validate_worktree_add():
>
> Coming from "git clone" background I would still expect --no-checkout
> to abort on non-empty directory (i.e. we always start at a good known
> state). Maybe another option can be used in combination with
> --no-checkout for this. And do we want the same option in "git clone"?

Taking a potential use-case into account, it might be more appropriate
to compare this suggested behavior to git-init rather than to
git-clone. Say, for instance, someone downloads a "tarball" of a
project (with no .git/ directory), experimentally hacks on it for a
while and then decides that that work is worthy of being submitted to
the project as patches or a pull-request. One could imagine that a way
to accomplish this would be to "git clone ..." the project, and then
"git worktree add --no-checkout /path/to/my/hacking", followed by a
series of "git add ..." and "git commit ..." invocations to formalize
the changes into discreet commits.

This is analogous to how you might start hacking from scratch on a new
experimental project before you know if it will pan out, and before
you know if it will be worthy of placing under revision control. If it
does pan out, then you "git init" the existing populated directory,
and follow with a series of "git add ..." and "git commit ..."
invocations.

I'm not sure how common such a use-case is, though. I recall being in
such a situation once or twice over the years, but that's not
necessarily a good metric. So, I'm not suggesting that such a feature
should or need be added to git-worktree, but the above thought
experiment perhaps provides some context for possible behavior.