On Sat, 16 Apr 2005, Linus Torvalds wrote: > > Having slept on it, I think I'll merge all the trivial cases that don't > involve a file going away or being added. Ie if the file is in all three > trees, but it's the same in two of them, we know what to do.
Junio, I pushed this out, along with the two patches from you. It's still more anal than my original "tree-diff" algorithm, in that it refuses to touch anything where the name isn't the same in all three versions (original, new1 and new2), but now it does the "if two of them match, just select the result directly" trivial merges. I really cannot see any sane case where user policy might dictate doing anything else, but if somebody can come up with an argument for a merge algorithm that wouldn't do what that trivial merge does, we can make a flag for "don't merge at all". The reason I do want to merge at all in "read-tree" is that I want to avoid having to write out a huge index-file (it's 1.6MB on the kernel, so if you don't do _any_ trivial merges, it would be 4.8MB after reading three trees) and then having people read it and parse it just to do stuff that is obvious. Touching 5MB of data isn't cheap, even if you don't do a whole lot to it. Anyway, with the modified read-tree, as far as I can tell it will now merge all the cases where one side has done something to a file, and the other side has left it alone (or where both sides have done the exact same modification). That should _really_ cut down the cases to just a few files for most of the kernel merges I can think of. Does it do the right thing for your tests? Linus - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html