git work trees
- Date: Tue, 11 Apr 2017 15:14:57 +0000
- From: "taylor, david" <David.Taylor@xxxxxxxx>
- Subject: 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
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 [<path>...] 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