Re: [PATCH/RFD 0/3] worktree.* config keys and submodule and multiple worktrees
- From
Duy Nguyen <pclouds@gmail.com>
- Date
- Feb 9, 2015, 09:35 UTC
- Message-ID
- <CACsJy8D8Ur4W348t-WFUPrb7SQxmff5MJ4aRp+w+ZiQ7VVvipg@mail.gmail.com>
- In-Reply-To
- <54D79EAB.6060301@web.de>
On Mon, Feb 9, 2015 at 12:36 AM, Jens Lehmann <Jens.Lehmann@web.de> wrote:
Show 6 quoted lines
> I wonder if it's worth all the hassle to invent new names. Wouldn't > it be much better to just keep a list of per-worktree configuration > value names and use that inside the config code to decide where to > find them for multiple work trees. That would also work easily for > stuff like EOL-config and would push the complexity in the config > machinery and not onto the user.
It's certainly possible to relocate core.worktree to outside $GIT_DIR/config. But I don't think it helps. If anything it'll make it harder to distinguish the old setup and the new one. I think we need a clear signal that will make old git barf on new setup, to be safe. Maybe stepping core.repositoryformatversion, or breaking .git file format when we switch to the new setup (with $GIT_COMMON_DIR).
Or.. perhaps we could use the old setup for "primary" worktree and the new one for secondary worktrees of the same submodule. In these secondary submodules, $GIT_COMMON_DIR is enough to make old git reject them. And we could just reuse core.worktree, if we can make core.worktree in $GIT_DIR/config.worktree shadow one in $GIT_DIR/config..
Need to study git-submodule.sh some more..
-- Duy