Web lists-archives.com

Re: git work trees

On Tue, Apr 11, 2017 at 10:14 PM, taylor, david <David.Taylor@xxxxxxxx> 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.