RE: git worktrees must exist even if locked
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 > > . create an empty directory /home/somedir/worktree-tests > > . use 'git worktree add' to add /home/somedir/worktree-tests/ name> > as a worktree on branch . 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/ 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
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 . create an empty directory /home/somedir/worktree-tests . use 'git worktree add' to add /home/somedir/worktree-tests/ as a worktree on branch . 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/ 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: [PATCH] worktree add: add --lock option
> From: Duy Nguyen [mailto:pclo...@gmail.com] > Sent: Friday, April 14, 2017 9:01 AM > To: Junio C Hamano > Cc: Git Mailing List; taylor, david > Subject: Re: [PATCH] worktree add: add --lock option > > On Fri, Apr 14, 2017 at 5:50 AM, Junio C Hamano <gits...@pobox.com> > wrote: > > Nguyễn Thái Ngọc Duy <pclo...@gmail.com> writes: > > > >> As explained in the document. This option has an advantage over the > >> command sequence "git worktree add && git worktree lock": there will be > >> no gap that somebody can accidentally "prune" the new worktree (or > soon, > >> explicitly "worktree remove" it). > >> > >> "worktree add" does keep a lock on while it's preparing the worktree. > >> If --lock is specified, this lock remains after the worktree is created. > >> > >> Suggested-by: David Taylor <david.tay...@dell.com> > >> Signed-off-by: Nguyễn Thái Ngọc Duy <pclo...@gmail.com> > >> --- > >> A patch that adds --lock may look like this. > > > > This looks more like "I do believe the idea by David is a useful > > addition and here is how I did it to the best of my ability---let's > > make sure we polish it for eventual inclusion" than a mere "it may > > look like so---do whatever you want with it" patch. > > It is a good addition, which is why I added tests and documents, so it > may have a chance for inclusion. I would not strongly defend it though > if there's objection. > > > To me "git worktree add --lock" somehow sounds less correct than > > "git worktree add --locked", but I'd appreciate if natives can > > correct me. > > That was my first choice too. Then I saw --detach (instead of > --detached). I didn't care much and went with a verb like the rest. While I personally would prefer --locked, I also prefer keeping it 'parallel construction' with --detach. That is either [--detach][--lock] or [--detached][--locked]. But, ultimately, my intended use is within a script, so even if it was --totally-non-mnemonic-option I would cope. A stronger desire, regardless of whether it's Duy's implementation, mine, or someone elses, is to have something acceptable to the community so that we are not maintaining a fork with the attendant need to merge changes in each time we upgrade. > -- > Duy
git work trees
We are using Git in a distributed environment. In the United States, we have the master repository in one state and a build cluster in a different state. In addition to people in the US doing builds, we have people in other countries (Ireland, India, Israel, Russia, possibly others) doing builds -- using the build cluster. The local mirror of the repository is NFS accessible. The plan is to make builds faster through the use of work trees. The build cluster nodes involved in the build will have a worktree in RAM -- checked out for the duration of the build. Since the worktree is in RAM, it will not be NFS accessible. [Cloning takes 20+ minutes when the network is unloaded. Building, with sources NFS mounted, takes 5-10 minutes.] This presents a few problems. When we are done with a work tree, we want to clean up -- think: prune. But, you cannot prune just one worktree; you have to prune the set. And no machine has access to all the worktrees. So, no machine knows which ones are prunable. There is no 'lock' option to 'add'. If someone does a 'prune' after you do an 'add' and before you do a 'lock', then your 'add' is undone. Are there any plans to add a '[--lock]' option to 'add' to create the worktree in the locked state? And/or plans to add a [...] option to prune to say 'prune only this path / these paths'? If there are no plans, is the above an acceptable interface? And if we implemented it, would it be looked upon favorably? Thanks.