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
