Re: merging .gitignore

[Johan Herland <johan@herland.net>]

On Wednesday 03 October 2007, Andy Parkins wrote:
> I am still having difficult seeing why you want to hide conflicts 
> in .gitignore.  It's just as possible to get and resolve conflicts in 
> gitignore as in any other file.

Agreed. What about the following:

- No special merge rules for .gitignore

- Teach the .gitignore parser to ignore conflict markers (i.e. regard them 
as comments)


This way, the user will have to merge .gitignore like any other file, but if 
for some reason, the user is not able to do so (say, git needs to 
consult .gitignore before the user has had a chance to resolve the 
conflict), the fallback result will be similar to a union merge, which 
shouldn't be extremely harmful in .gitignore's case.

I do not think we really want to create an auto-merge algorithm 
for .gitignore, and then depend on this auto-merge algorithm to _always_ 
succeed with the _correct_ result and _no_ conflicts. These algorithms tend 
to be extremely tricky to get right, especially for the "always correct" 
requirement.

<rant>
Mercurial had a similar problem some months ago. They have their tag 
definitions stored in a versioned file in the working tree (.hgtags IIRC). 
But the repo tag state (i.e. Mercurial's opinion at any time as to _which_ 
tags are defined and _where_ they point) is not deduced from the copy in 
your current working tree at all. (That would of course limit you to only 
ba able to refer to tags defined earlier on the particular branch you're 
currently on.) Instead the repo tag state was found by consulting 
the "head-most" copy of the .hgtags file (for some definition 
of "head-most" including non-obvious things like which branch has the most 
recent commit, etc). The end result was that you could get some _really_ 
interesting behaviour depending on the order in which you commited totally 
unrelated changes to two different branches which happened to have 
different .hgtags files. (E.g.: Given two branches A, B, and  - in .hgtags 
on branch A - tag Foo is defined to point at rev X, and - in .hgtags on 
branch B - Foo points at rev Y. Now, whether you got rev X or rev Y when 
you checked out Foo, depended on which of branch A or branch B had the most 
recent (totally unrelated, i.e. not even touching .hgtags) commit.)

I (and others) pointed out this bug on their ML, and instead of fixing the 
braindeadness of allowing branched tag definitions in the repo in the first 
place, they set about trying to create an auto-merge algorithm for deducing 
the repo tag state from the various versions/branches of .hgtags found in 
the repo. I didn't stick around for long enough to see how well this 
auto-merge algorithm works (the misdesign of tags in Mercurial was one of 
the reasons I started looking at git), but I would be surprised if 
Mercurial today has a simple and straightforward way of deducing the repo 
tag state that _always_ gives _correct_ (i.e. unsurprising) results, even 
in the corner cases.
</rant>


Have fun! :)


...Johan

-- 
Johan Herland, <johan@herland.net>
www.herland.net