W dniu 2014-06-13 11:38, Michael J Gruber pisze:
Michael Haggerty venit, vidit, dixit 13.06.2014 00:12:I've been thinking a lot about merge bases lately and think I have discovered something interesting. tl;dr: When two branches have multiple merge bases, git merge-base $master $branch picks one merge base more or less arbitrarily. Here I describe a criterion for picking a "best" merge base. When the best merge base is used, the diff output by git diff $master...$branch becomes shorter and simpler--sometimes dramatically so. I have quantified the improvement by analyzing historical merges from the Git project (see attached image). Best merge bases might also help reduce conflicts when conducting merges.Everytime I looked at our merge base code, my head started spinning. So it's admirable you even started this endeavor :) We use merge bases for several things: - merging - resolving "A...B" rev notation (rev-list and friends), aka symmetric difference - left/right selection/annotation of commits (rev-list/log) - resolving "diff A...B", which may be a handy notation, but is horribly misleading because it is a very unsymmetric form of diff
I don't know if it has been fixed, but there is a difference between "git diff A...B" when A and B have one merge base, and "git diff A...B" when there are more than one merge base. When there is one merge base, "git diff A...B" returns simple unified diff equivalent to "git diff $(git merge-base A B) B". It is unsymmetric. But where there are more than one merge base, by design or by accident for "git diff A...B" git 1.9.2 / 1.7.4 returns git diff --cc $(git merge-base --all A B) A B which is *symmetric*, and is combined not unified diff. -- Jakub Narębski -- 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