Re: git work trees

[Duy Nguyen]

On Tue, Apr 11, 2017 at 10:14 PM, taylor, david  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 [...] 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

git work trees

[taylor, david]

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.