On Mon, Feb 9, 2015 at 12:36 AM, Jens Lehmann <Jens.Lehmann@xxxxxx> wrote: > 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 -- 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