Jonathan Nieder <jrnieder@xxxxxxxxx> writes:
[snipped everything I agree with...]
> On the other hand, the single .gitmodules file will be a pain to merge
> if multiple branches modify it. So I do look forward to a merge
> strategy that deals more intelligently with its content, and wouldn't
> have minded a design that split this information into multiple files
> if we were starting over.
I find it a sensible suggestion to have a content-aware merge
driver. Such a custom merge driver to help merging a structured
datafile in the config format will have other uses when we need to
do more than the current system (outside submodules there will be
other things "frotz" that need "information about frotz" in the
future, and a .gitfrotz file would be one possible way to do so).
I do not think it needs to be split per-submodule.
When a submodule in the common ancestor was at path dirA/, and you
are merging with another branch that moved it to path dirB/, the
contents of .gitmodules file for that module (that is identified by
its <name>) will need a three-way merge of its .path element:
common ancestor: submodule.<name>.path = dirA/
ours: submodule.<name>.path = dirA/
theirs: submodule.<name>.path = dirB/
And your content-aware merge driver should be able to do the
resolving by following the usual three-way merge rules. We started
from the same dirA/ and only they changed, so the result is dirB/.
By the way, that's a "merge driver" (which deals with per-path
content merge), not a strategy (which deals with the entire tree
level merge).
--
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