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@xxxxxxxxxxx> www.herland.net - 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
