On Wed, Jul 20, 2016 at 6:14 AM, Duy Nguyen <pclouds@xxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html