worktree add already exists

worktree add already exists

[Ingo Wolf]

x@y MINGW64 ~/gittest
$ ls
bare/  barework/

x@y MINGW64 ~/gittest
$ ls -a barework
./  ../  test.txt

x@y MINGW64 ~/gittest
$ git -C bare branch
* master

x@y MINGW64 ~/gittest
$ git -C bare worktree add --no-checkout ../barework
Preparing worktree (new branch 'barework')
fatal: '../barework' already exists

x@y MINGW64 ~/gittest
$ git -C bare branch
   barework
* master

Why this doesn't just work and if not why is barework branch made then,
why at all ?

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 can do that tricking around with a little dir renaming, new empty dir,
move the .git file and rename back...

Re: worktree add already exists

[Eric Sunshine]

On Mon, May 27, 2019 at 11:32 AM Ingo Wolf <ingo.wolf@gmx.de> wrote:
> $ ls -a barework
> ./  ../  test.txt
> $ git -C bare worktree add --no-checkout ../barework
> Preparing worktree (new branch 'barework')
> fatal: '../barework' already exists
> $ git -C bare branch
>    barework
> * master
> Why this doesn't just work and if not why is barework branch made then,
> why at all ?

It is by design that "git worktree add" (in general) fails if the
target directory already exists and is non-empty. This is consistent
with how "git clone" behaves. As for why your particular use-case
isn't directly supported, it's likely that nobody has yet asked for
it, and nobody thought about this particular case when --no-checkout
was added (which came some time after basic "git worktree add" itself
was implemented).

It is an accident of implementation that the new branch gets created
before "git worktree add" errors out due to the existing non-empty
directory (and, likely, nobody complained about it, so it went
unnoticed). This particular issue probably can be easily fixed now
that the logic for checking if the target directory can be a valid
worktree has been factored out of the code which actually creates the
new directory[1].

[1]: 45059e6468 (worktree: prepare for more checks of whether path can
become worktree, 2018-08-28)

> 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():

    if (file_exists(path) && !is_empty_dir(path))
        die(_("'%s' already exists"), path);

to:

    if (opts->checkout && file_exists(path) && !is_empty_dir(path))
        die(_("'%s' already exists"), path);

or something.

Re: worktree add already exists

[Duy Nguyen]

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:
> > $ ls -a barework
> > ./  ../  test.txt
> > $ git -C bare worktree add --no-checkout ../barework
> > Preparing worktree (new branch 'barework')
> > fatal: '../barework' already exists
> > $ git -C bare branch
> >    barework
> > * master
> > Why this doesn't just work and if not why is barework branch made then,
> > why at all ?
>
> It is by design that "git worktree add" (in general) fails if the
> target directory already exists and is non-empty. This is consistent
> with how "git clone" behaves. As for why your particular use-case
> isn't directly supported, it's likely that nobody has yet asked for
> it, and nobody thought about this particular case when --no-checkout
> was added (which came some time after basic "git worktree add" itself
> was implemented).
>
> It is an accident of implementation that the new branch gets created
> before "git worktree add" errors out due to the existing non-empty
> directory (and, likely, nobody complained about it, so it went
> unnoticed). This particular issue probably can be easily fixed now
> that the logic for checking if the target directory can be a valid
> worktree has been factored out of the code which actually creates the
> new directory[1].
>
> [1]: 45059e6468 (worktree: prepare for more checks of whether path can
> become worktree, 2018-08-28)
>
> > 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():
>
>     if (file_exists(path) && !is_empty_dir(path))
>         die(_("'%s' already exists"), path);
>
> to:
>
>     if (opts->checkout && file_exists(path) && !is_empty_dir(path))
>         die(_("'%s' already exists"), path);
>
> or something.

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"?
-- 
Duy

Re: worktree add already exists

[Eric Sunshine]

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.

Re: worktree add already exists

[Duy Nguyen]

On Tue, Jun 4, 2019 at 1:32 AM Eric Sunshine <sunshine@sunshineco.com> wrote:
>
> 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.

Or you could just git-clone directly to the place you unpacked the tarball.

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

Yeah I'm not suggesting we do anything immediately either.

I still think though that we should change --no-checkout behavior.
"worktree add --no-checkout --keep-worktree" is quite readable (and I
assume this is not a popular use case that people will have to specify
both options often)
-- 
Duy

Re: worktree add already exists

[Ingo Wolf]

Am 05.06.2019 um 12:17 schrieb Duy Nguyen:
> "worktree add --no-checkout --keep-worktree" is quite readable

worktree add --no-checkout -f (orce)

I've expected to work on an not empty directory

Re: worktree add already exists

[Duy Nguyen]

On Wed, Jun 5, 2019 at 10:30 PM Ingo Wolf <ingo.wolf@gmx.de> wrote:
>
> Am 05.06.2019 um 12:17 schrieb Duy Nguyen:
> > "worktree add --no-checkout --keep-worktree" is quite readable
>
> worktree add --no-checkout -f (orce)
>
> I've expected to work on an not empty directory

Yeah --force works too. Not sure how it interacts with "--force
--force". But --force is already overloaded, I don't think forcing
harder is going to make it much worse.
-- 
Duy