On Thu, May 11, 2017 at 3:24 AM, taylor, david <david.tay...@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
