Merging .gitmodules files

Merging .gitmodules files

[David Turner]

Consider two commits: one adds file A, and the other adds file B.  These commits don't conflict; you can merge them with no problem.

But if the two commits instead add submodules A and B, and you try to merge, you'll likely get a conflict in .gitmodules.  This seems wrong; .gitmodules happens to be a plain text file as an implementation detail, but in terms of interpretation, it is more like a map of maps (name1 -> {path -> "...", url -> "..."}, name2 -> ...).  

We (Two Sigma) keep our .gitmodules file in alphabetical order (so we don't use git submodule add -- our .gitmodules file is instead generated by some more complicated offline process).  But even for ordinary .gitmodules files, order is not important so long as it's consistent.

I could set my .gitattributes for the .gitmodules file to use a custom merge driver. But: (a) I don't see an off-the-shelf one that does what I want ("union" happens to work in the add/add case, but not in the add/remove case or other cases) and (b) I would have to rewrite my whole history in order to have the .gitmodules file exist at every commit (or find a way to get .git/info/attributes into each of my users' clones) and (c) this should work correctly without customization; Git already treats the .gitmodules file as special for commands like "status"; there's no reason it shouldn't do so for merge and rebase.

I'm not sure I'll necessarily have time to implement this -- for our use case ( http://github.com/twosigma/git-meta ), we might be able to get away with doing it in JS, and using something like https://github.com/mirkokiefer/diff-merge-patch#sets .  But if I did have time, do others agree that it would be reasonable to special-case this file?  (Naturally, before doing the merge, we would check that the file was in fact parseable as a git config file; merging two changed gitmodules files of which either is unparseable would fall back to merging as text). 

Re: Merging .gitmodules files

[Junio C Hamano]

David Turner <David.Turner@twosigma.com> writes:

> I could set my .gitattributes for the .gitmodules file to use a
> custom merge driver. But: (a) I don't see an off-the-shelf one
> that does what I want ("union" happens to work in the add/add
> case, but not in the add/remove case or other cases) and (b) I
> would have to rewrite my whole history in order to have the
> .gitmodules file exist at every commit (or find a way to get
> .git/info/attributes into each of my users' clones) and (c) this
> should work correctly without customization; Git already treats
> the .gitmodules file as special for commands like "status";
> there's no reason it shouldn't do so for merge and rebase.
> ... if I did have time, do others agree that it would be
> reasonable to special-case this file?  (Naturally, before doing
> the merge, we would check that the file was in fact parseable as a
> git config file; merging two changed gitmodules files of which
> either is unparseable would fall back to merging as text).

I do not see a fundamental reason why Git shouldn't know what
.gitmodules file is and how it should merge.

Our philosophy has always been "give users enough flexibility so
that they can experiment and come up with a solution that is general
enough (i.e. you can do it with custom merge driver), and then fold
it back into the core if it is an issue that is general enough and
it makes sense for the core to care about (i.e. my "why not?"
above).  If you already have a custom merge driver, then you have
already cleared the first step ;-)