>>>>> "LT" == Linus Torvalds <[EMAIL PROTECTED]> writes:
LT> But I'm really happy that you seem to have implemented my first
LT> suggestion and I seem to have been wasting my time.
Thanks for the kind words.
>> 5. for each path involved:
>> 5.0 if neither heads change it, leave it as is;
>> 5.1 if only one head changes a path and the other does not, just
>> get the changed version;
>> 5.2 if both heads change it, check all three out and run merge.
LT> You missed one case:
LT> 5.0.1 if both heads change it to the same thing, take the new thing
LT> but maybe you counted that as 5.0 (it _should_ fall out automatically from
LT> the fact that "diff-tree" between the two destination trees shows no
LT> difference for such a file).
Actually I am not handling that. It really is 5.1a---the exact
same code path as 5.1 can be used for this case, and as you
point out it is really a quite important optimization.
I have to handle the following cases. I think I currently do
wrong things to them:
5.1a both head modify to the same thing.
5.1b one head removes, the other does not do anything.
5.1c both head remove.
5.3 one head removes, the other head modifies.
Handling of 5.1a, 5.1b and 5.1c are obvious.
5.1a Update dircache to the same new thing. Without -f or -o
flag do not touch ,,merge-temp/. directory; with -f or
-o, leave the new file in ,,merge-temp/.
5.1b Remove the path from dircache and do not have the file in
,,merge-temp/. directory regardless of -f or -o flags.
5.1c Same as 5.1b
I am not sure what to do with 5.3. My knee-jerk reaction is to
leave the modified result in ,,merge-temp/$path~ without
touching dircache. If the merger wants to pick it up, he can
rename $path~ to $path temporarily, run show-diff on it (I think
giving an option to show-diff to specify paths would be helpful
for this workflow), to decide if he wants to keep the file or
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