[PATCH v4 0/4] Split .git/config in multiple worktree setup

["Nguyễn Thái Ngọc Duy" <pclouds@gmail.com>]

On Wed, Jul 20, 2016 at 6:14 AM, Duy Nguyen <pclouds@gmail.com> wrote:
>> If yes, do you know if someone is working on this? If nobody is working on this, do
>> you have some pointers for me what the main problems are?
>
> The blocker is config file being shared (you do not want to share
> core.worktree and submodule.*). I made some progress last weekend,
> just needed to add some tests to see if submodule works as expected
> and will post the series soon. Then you can take over if you want ;)

Here it is. I'm going to describe some more for new people. Let's
start with the problem, then the high level solution and finally
what's done in submodule. These are separated by ^----$

Multipl worktrees in its current form share the config file. The only
exceptions are core.bare and core.worktree which will be applied for
the main worktree only, if present in the config file.

This does not make submodules happy because submodules use
core.worktree to link back to the real repos stored inside .git dir of
the super modules. This is not so bad right now because the
submodule's worktree would be "main" worktree and core.worktree sticks
to it. If one day "git submodule add" initialize the worktree as a
linked worktree, problem arises.

The second problem is more real. When you initialize submodules,
submodule info is stored in the supermodule's config file, which is
shared. So the secondary worktree will not be able to initialize its
own submodules (and may be confused by the existing submodule.*
section).

----

So we need to split the config file into two logical parts: a shared
part and a worktree-specific one. This makes everybody happy even
though it's not easy.

What this series does is adding "git config --worktree" which writes
to the worktree-specific part, while "git config" writes to the shared
part. "git config" as a read operation will read the shared part
first, then the worktree specific part.

Now. In current multiple worktrees setup, both the shared and private
parts are in the same file, "config". And "git config --worktree" will
refuse to work if you have more than one worktree. For it to work with
multiple worktree, you need to enable extensions.worktreeConfig (in
config file).

This extension designates the file "config.worktree" as storage for
the private part. It can be .git/config.worktree for main worktree, or
.git/worktrees/xxx/config.worktree for linked ones.

Before enabling extensions.worktreeConfig (or soon after it), you need
to move core.bare and core.worktree to .git/config.worktree because
the exceptions above are gone. If they are present in "config" file,
they are _shared_ (and hell follows)

If you have followed through the first four iterations, v4 [1] has
very close design. The main difference is: in v4, "config" is
per-worktree and the shared part is split away, hidden in
.git/common/config. This leads to the migration and backward
compatibility problems.

The new design is free of that because "config" remains shared while
the private is hidden away. The risk is "git config" by default writes
to the shared part. Accidentally sharing something may be more
dangerous than accidentally _not_ sharing something like v3 [1] (which
defaults to per-worktree). I've thought about this and I'm willing to
take the new direction, bettting that 90% of the time people want to
share, so it's a rare problem.

----

With all that in place, what does a command have to do to take
advantage of it?

- Whenever you need to write a per-worktree config (you decide it!),
  use "git config --worktree". That's it. You don't really need to
  care where it ends up to. This is what 3/4 is, for submodule.

- Avoid "git config /path/to/.git/config" because that may or may not
  be the right place (there's also config.worktree now). Builtin
  commands have this worse because if you look at _another_ repo, then
  you may need to go through repo detection and stuff before you can
  read its config. I just fall back to running "git config" in 2/4.

So that's it. It seems to be running ok. But I know very little about
submodules to test it properly.

The only problem left that I have to work out is config deletion. I
suppose we could follow the chain backward again: try to delete in
per-worktree config file first. If not found, try again in the shared
config file...

[1] http://thread.gmane.org/gmane.comp.version-control.git/281906/focus=284803
-- 
2.9.1.566.gbd532d4