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.
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:
- resolving "A...B" rev notation (rev-list and friends), aka symmetric
- 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.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html