Re: git work trees

From: Duy Nguyen <pclouds@gmail.com>
Date: Apr 12, 2017, 13:36 UTC
Message-ID: <CACsJy8CBjO+Wg187LUTGs1nna1trV2nukgS9uK74PcY-dEFGaA@mail.gmail.com>
In-Reply-To: <63F1AEE13FAE864586D589C671A6E18B0CFBF7@MX203CL03.corp.emc.com>

On Tue, Apr 11, 2017 at 10:14 PM, taylor, david <David.Taylor@dell.com> wrote:

Show 12 quoted lines

> 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)?

Show 5 quoted lines

> 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?

Show 5 quoted lines

> 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