Re: git work trees
- Date: Wed, 12 Apr 2017 20:36:03 +0700
- From: Duy Nguyen <pclouds@xxxxxxxxx>
- Subject: 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.