On Tue, Apr 11, 2017 at 10:14 PM, taylor, david <david.tay...@dell.com> wrote: > 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.]
Using worktrees in this scenario kinda defeats the distributed nature of git. Cloning takes long, yes. But what about just "git pull" (or "git fetch && git checkout -f" if you want to avoid merging)? > 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. By "prune one worktree", did you mean delete one? Or delete a branch the worktree uses and prune the object database? > 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 [<path>...] option to prune to say 'prune only this path / > these paths'? So this is "git worktree prune". Adding "worktree add --locked" sounds reasonable (and quite simple too, because "worktree add" does lock the worktree at creation time; we just need to stop it from releasing the lock). I might be able to do it quickly (it does not mean "available in the next release" though). If you need to just prune "this path", I think it's the equivalent of "git worktree remove" (i.e. delete a specific worktree). Work has been going on for a while to add that command. Maybe it'll be available later this year. > If there are no plans, is the above an acceptable interface? And if we > implemented it, would it be looked > upon favorably? Speaking of this use case (and this is my own opinion) I think this is stretching "git worktree" too much. When I created it, I imagined this functionality to be used by a single person. -- Duy
