git worktrees must exist even if locked

git worktrees must exist even if locked

[taylor, david]

The Git documentation in describing worktrees says that one reason
why you might want to lock a worktree is to prevent it from being pruned
if it is on a removable media that isn't currently mounted.

So, my expectation was that if the worktree is inaccessible (and locked), Git
would pretend that there is no worktree by that name.

In reality, if you have such a worktree, Git gets an error.

 On local systems, /home is local to a machine; home directories are elsewhere.
Home directories are NFS mounted; /home is not.

. create a repository in /my/home/dir/my-repo.git with

    git clone --bare <some arguments>

. create an empty directory /home/somedir/worktree-tests

. use 'git worktree add' to add /home/somedir/worktree-tests/<branch-name>
  as a worktree on branch <branch-name>.  It gets populated with the correct
  content.

. lock it using'git worktree lock'

So far, so good.  Now, go to a different computer -- one on which
/home/somedir/worktree-tests does not exist (and therefore
/home/somedir/worktree-tests/<branch-name> does not exist).

. cd /my/home/dir/my-repo.git

Now, try issuing Git commands.  Many will fail.

  git fetch ==> fails:

  fatal: Invalid path '/home/somedir/worktree-tests': No such file or directory

  git status ==> fails -- same error as above
  git help worktree ==> fails -- same error as above

RE: git worktrees must exist even if locked

[taylor, david]

The original report was against Git v2.12.2.  I have since tried v2.12.3, v2.13.0,
and the next branch.  All exhibit the same symptoms.

Even if you ignore the original scenario for creating the problem, if I do a 'rm -rf' or 'mv'
of a tree that contains within it worktrees, that should not break the use of Git with
worktrees that live elsewhere nor commands that don't require a repository.

> -----Original Message-----
> From: taylor, david
> Sent: Wednesday, May 10, 2017 4:25 PM
> To: git@vger.kernel.org
> Subject: git worktrees must exist even if locked
> 
> The Git documentation in describing worktrees says that one reason
> why you might want to lock a worktree is to prevent it from being pruned
> if it is on a removable media that isn't currently mounted.
> 
> So, my expectation was that if the worktree is inaccessible (and locked), Git
> would pretend that there is no worktree by that name.
> 
> In reality, if you have such a worktree, Git gets an error.
> 
>  On local systems, /home is local to a machine; home directories are
> elsewhere.
> Home directories are NFS mounted; /home is not.
> 
> . create a repository in /my/home/dir/my-repo.git with
> 
>     git clone --bare <some arguments>
> 
> . create an empty directory /home/somedir/worktree-tests
> 
> . use 'git worktree add' to add /home/somedir/worktree-tests/<branch-
> name>
>   as a worktree on branch <branch-name>.  It gets populated with the correct
>   content.
> 
> . lock it using'git worktree lock'
> 
> So far, so good.  Now, go to a different computer -- one on which
> /home/somedir/worktree-tests does not exist (and therefore
> /home/somedir/worktree-tests/<branch-name> does not exist).
> 
> . cd /my/home/dir/my-repo.git
> 
> Now, try issuing Git commands.  Many will fail.
> 
>   git fetch ==> fails:
> 
>   fatal: Invalid path '/home/somedir/worktree-tests': No such file or directory
> 
>   git status ==> fails -- same error as above
>   git help worktree ==> fails -- same error as above

Re: git worktrees must exist even if locked

[Junio C Hamano]

"taylor, david" <David.Taylor@dell.com> writes:

> The original report was against Git v2.12.2.  I have since tried v2.12.3, v2.13.0,
> and the next branch.  All exhibit the same symptoms.
>
> Even if you ignore the original scenario for creating the problem, if I do a 'rm -rf' or 'mv'
> of a tree that contains within it worktrees, that should not break the use of Git with
> worktrees that live elsewhere nor commands that don't require a repository.

Duy, any ideas?

Thanks.

>
>> -----Original Message-----
>> From: taylor, david
>> Sent: Wednesday, May 10, 2017 4:25 PM
>> To: git@vger.kernel.org
>> Subject: git worktrees must exist even if locked
>> 
>> The Git documentation in describing worktrees says that one reason
>> why you might want to lock a worktree is to prevent it from being pruned
>> if it is on a removable media that isn't currently mounted.
>> 
>> So, my expectation was that if the worktree is inaccessible (and locked), Git
>> would pretend that there is no worktree by that name.
>> 
>> In reality, if you have such a worktree, Git gets an error.
>> 
>>  On local systems, /home is local to a machine; home directories are
>> elsewhere.
>> Home directories are NFS mounted; /home is not.
>> 
>> . create a repository in /my/home/dir/my-repo.git with
>> 
>>     git clone --bare <some arguments>
>> 
>> . create an empty directory /home/somedir/worktree-tests
>> 
>> . use 'git worktree add' to add /home/somedir/worktree-tests/<branch-
>> name>
>>   as a worktree on branch <branch-name>.  It gets populated with the correct
>>   content.
>> 
>> . lock it using'git worktree lock'
>> 
>> So far, so good.  Now, go to a different computer -- one on which
>> /home/somedir/worktree-tests does not exist (and therefore
>> /home/somedir/worktree-tests/<branch-name> does not exist).
>> 
>> . cd /my/home/dir/my-repo.git
>> 
>> Now, try issuing Git commands.  Many will fail.
>> 
>>   git fetch ==> fails:
>> 
>>   fatal: Invalid path '/home/somedir/worktree-tests': No such file or directory
>> 
>>   git status ==> fails -- same error as above
>>   git help worktree ==> fails -- same error as above

Re: git worktrees must exist even if locked

[Duy Nguyen]

On Tue, May 16, 2017 at 5:43 AM, Junio C Hamano <gitster@pobox.com> wrote:
> "taylor, david" <David.Taylor@dell.com> writes:
>
>> The original report was against Git v2.12.2.  I have since tried v2.12.3, v2.13.0,
>> and the next branch.  All exhibit the same symptoms.
>>
>> Even if you ignore the original scenario for creating the problem, if I do a 'rm -rf' or 'mv'
>> of a tree that contains within it worktrees, that should not break the use of Git with
>> worktrees that live elsewhere nor commands that don't require a repository.
>
> Duy, any ideas?

We are supposed to tolerate missing worktrees if locked. I'm guessing
that lots of changes in get_worktrees() lately may perhaps forget
about this and be too strict on locked worktrees.
-- 
Duy

Re: git worktrees must exist even if locked

[Duy Nguyen]

On Thu, May 11, 2017 at 3:24 AM, taylor, david <David.Taylor@dell.com> wrote:
> The Git documentation in describing worktrees says that one reason
> why you might want to lock a worktree is to prevent it from being pruned
> if it is on a removable media that isn't currently mounted.
>
> So, my expectation was that if the worktree is inaccessible (and locked), Git
> would pretend that there is no worktree by that name.
>
> In reality, if you have such a worktree, Git gets an error.
>
>  On local systems, /home is local to a machine; home directories are elsewhere.
> Home directories are NFS mounted; /home is not.
>
> . create a repository in /my/home/dir/my-repo.git with
>
>     git clone --bare <some arguments>
>
> . create an empty directory /home/somedir/worktree-tests
>
> . use 'git worktree add' to add /home/somedir/worktree-tests/<branch-name>
>   as a worktree on branch <branch-name>.  It gets populated with the correct
>   content.
>
> . lock it using'git worktree lock'
>
> So far, so good.  Now, go to a different computer -- one on which
> /home/somedir/worktree-tests does not exist (and therefore
> /home/somedir/worktree-tests/<branch-name> does not exist).
>
> . cd /my/home/dir/my-repo.git
>
> Now, try issuing Git commands.  Many will fail.
>
>   git fetch ==> fails:
>
>   fatal: Invalid path '/home/somedir/worktree-tests': No such file or directory
>
>   git status ==> fails -- same error as above
>   git help worktree ==> fails -- same error as above

FWIW I couldn't reproduce this. The fact that "git help" also fails
suggests this is triggered by some early setup code, which narrows
down the starting point to strbuf_realpath (that can print "Invalid
path", the other call in read-cache.c involves adding index entries
and can be ignored). But I fail to see how early setup code needs to
look at any worktree at all, especially when you issue command
standing from my-repo.git (i.e. bare repo setup, even current worktree
is ignored). An strace output, if possible, might help pinpoint the
problem.
-- 
Duy