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.
