Re: Our merge bases sometimes suck
- From
Jakub Narębski <jnareb@gmail.com>
- Date
- Jun 13, 2014, 15:52 UTC
- Message-ID
- <539B1E59.1030604@gmail.com>
- In-Reply-To
- <539AC690.6000906@drmicha.warpmail.net>
W dniu 2014-06-13 11:38, Michael J Gruber pisze:
Show 33 quoted lines
> 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