Re: worktree add already exists

From: Eric Sunshine <sunshine@sunshineco.com>
Date: Jun 3, 2019, 18:32 UTC
Message-ID: <CAPig+cQ0po+cqdqohkVqFyk=aowtjuYGM2J=31pFu6ZuPeAUFA@mail.gmail.com>
In-Reply-To: <CACsJy8CxSN90-EfTpkd6RUHFVp2iGjZXokpMqw7Tf0EMXT5LfQ@mail.gmail.com>

On Mon, Jun 3, 2019 at 5:47 AM Duy Nguyen <pclouds@gmail.com> wrote:

Show 13 quoted lines

> 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.