Wherefor worktrees?

[Marc Branchaud <marcnarc@xiplink.com>]

On 2018-09-26 11:48 AM, Duy Nguyen wrote:
> 
> I believe the main selling point of multiple worktrees is sharing
> refs. You could easily avoid expensive clones with --local, but
> synchronizing between different clones is not very convenient. Other
> than that, different worktrees tend to behave like separate clones.

Sharing hooks is also useful, but yes mainly the refs.

I love being able to work in more than one branch at a time.  I often 
have a couple of ongoing big, messy topics, and being able to easily 
jump onto some release branch for a quick bugfix, without having to 
first stash things or finish an interactive rebase or fix a conflicting 
merge, is a godsend.

And the reason I use worktrees for this, instead of clones, is for the 
shared refs.  It makes sense to me that I'm working with different 
checkouts from a single repo, with all my local branches and local tags. 
  "git fetch" updates the remote refs regardless of which worktree I'm 
in when I run it.  The setup is lightweight and efficient; it's just how 
I want to work.

Having used git-new-workdir for a long time, it's main deficiency for me 
is submodules (the shared bisection state didn't bother me much).  It 
would be nice if all my worktrees' submodules also shared refs.  That's 
"nice", but not "essential".  Mainly it would be convenient if a 
recursive-submodule fetch performed in one worktree updated the 
submodule refs in my other worktrees.  Similarly, if I create a local 
branch in a submodule in one worktree, it would be nice to see that 
branch in the submodule in other worktrees.  Again, "nice", but probably 
just because I've lived with git-new-workdir's limitations for so long 
that I'm used to them.

That said, I really appreciate Duy's work here -- thanks!  Git deserves 
to have a cool feature like worktrees be part of its standard toolkit.

		M.


> This leaves a gray area where other things should be shared or not. I
> think the preference (or default mode) is still _not_ shared (*).
> Sharing more things (besides refs and object database) is just a new
> opportunity popping up when we implement multiple worktrees. Since
> multiple worktrees (or clones before its time) are grouped together,
> sometimes you would like to share common configuration. We could sort
> of achieve this already with includeIf but again not as convenient.
> 
> (*) real life is not that simple. Since refs are shared, including
> _remotes_ refs, so configuration related to remotes should also be
> shared, or it will be a maintenance nightmare. Which is why
> $GIT_DIR/config so far has been shared besides the two exceptions that
> are core.bare and core.worktree. And I really like to get rid of these
> exceptions.
> 
>> Is there a better way to achieve that without the
>> downside of multiple worktrees (e.g. configuration need to be
>> uniform)?
> 
> Is there a better way to achieve sharing refs between clones? I gave
> it a minute but couldn't come up with a good answer :(
> 
>>> (*) "git config --worktree" points back to "config" file when this
>>>      extension is not present so that it works in any setup.
>>
>> Shouldn't it barf and error out instead?
> 
> The intention is a uniform interface/api that works with both single
> and multiple worktrees configurations. Otherwise in your scripts you
> would need to write "if single worktree, do this, else do that". If
> "git config --worktree" works with both, the existing scripts can be
> audited and updated just a bit, adding "--worktree" where the config
> should not be shared, and we're done.
> 
>> A user who hasn't enabled
>> the extension uses --worktree option and misled to believe that the
>> setting affects only a single worktree, even though the change is
>> made globally---that does not sound like a great end-user experience.
> 
> I was talking about a single worktree. But I think here you meant the
> user has multiple worktrees, but the extension is not enabled. I'm
> probably not clear in the commit message, but "git config" can detect
> that the extension has not been enabled, automatically enable it (and
> move core.bare and core.worktree (if present) to the main worktree's
> private config), so "git config --worktree" will never share the
> change.
> 
> But perhaps the user should be made aware of this situation and asked
> to explicitly enable the extension instead? It's certainly a more
> conservative approach.
>