Re: worktree add already exists

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