# Have git-merge-base support multiple IDs 4 messages from 2009-07-31 to 2009-08-03. Participants: Jan Engelhardt, Michael J Gruber. Thread: https://gitlist.dev/t/20320 ## Jan Engelhardt, 2009-07-31 15:51 Subject: Have git-merge-base support multiple IDs Message-ID: URL: https://gitlist.dev/e/alpine.LSU.2.00.0907311745100.4901%40fbirervta.pbzchgretzou.qr ``` Hi, I am using git merge-base as sort of a hack to determine where to start rebasing. Suppose this is the commit log (git log --oneline), of course, all unpublished, which is why rebase comes in: 98683793 Fix For faae2553 3365a01b Fix For ab80794f 62943a23 Feature Baz ab80794f Feature Bar faae2553 Feature Foo To determine the rebase point (i.e. first commit in a series), one can (ab)use git-merge-base: p=$(git merge-base ab80794f faae2553) git re -i ${p}^ And then reorder ab80794f, faae2553 to squash the fixes into the appropriate commits. This practice works well somewhat. The twist is that merge-base in git 1.6.3.3 happens to ignore any further arguments following two IDs. In short: git merge-base A B C... Only yields the merge-base of A and B, and ignores C... Perhaps this missing feature could be added in a future version? ``` ## Michael J Gruber, 2009-07-31 16:22 Subject: Re: Have git-merge-base support multiple IDs Message-ID: <4A731A39.3090506@drmicha.warpmail.net> URL: https://gitlist.dev/e/4A731A39.3090506%40drmicha.warpmail.net In-Reply-To: ``` Jan Engelhardt venit, vidit, dixit 31.07.2009 17:51: > Hi, > > > I am using git merge-base as sort of a hack to determine where to start > rebasing. > Suppose this is the commit log (git log --oneline), of course, all > unpublished, which is why rebase comes in: > > 98683793 Fix For faae2553 > 3365a01b Fix For ab80794f > 62943a23 Feature Baz > ab80794f Feature Bar > faae2553 Feature Foo > > To determine the rebase point (i.e. first commit in a series), > one can (ab)use git-merge-base: > > p=$(git merge-base ab80794f faae2553) > git re -i ${p}^ > > And then reorder ab80794f, faae2553 to squash the fixes into the > appropriate commits. This practice works well somewhat. > The twist is that merge-base in git 1.6.3.3 happens to ignore any > further arguments following two IDs. In short: > > git merge-base A B C... > > Only yields the merge-base of A and B, and ignores C... Uhm, are you sure about this? The first argument is special. merge-base computes the merge base between two commits: - the first argument - a (hypothetical) merge between all other arguments. It may look a if C was ignored, though. Michael ``` ## Jan Engelhardt, 2009-08-03 13:39 Subject: Re: Have git-merge-base support multiple IDs Message-ID: URL: https://gitlist.dev/e/alpine.LSU.2.00.0908031539070.2603%40fbirervta.pbzchgretzou.qr In-Reply-To: <4A731A39.3090506@drmicha.warpmail.net> ``` On Friday 2009-07-31 18:22, Michael J Gruber wrote: >Jan Engelhardt venit, vidit, dixit 31.07.2009 17:51: >> To determine the rebase point (i.e. first commit in a series), >> one can (ab)use git-merge-base: >> >> p=$(git merge-base ab80794f faae2553) >> git re -i ${p}^ >> >> The twist is that merge-base in git 1.6.3.3 happens to ignore any >> further arguments following two IDs. In short: >> >> git merge-base A B C... >> >> Only yields the merge-base of A and B, and ignores C... > >Uhm, are you sure about this? >The first argument is special. merge-base computes the merge base between two commits: >- the first argument >- a (hypothetical) merge between all other arguments. >It may look a if C was ignored, though. Hm indeed. Is there a better way to find the common ancestor of commits? ``` ## Michael J Gruber, 2009-08-03 21:52 Subject: Re: Have git-merge-base support multiple IDs Message-ID: <4A775C20.9070109@drmicha.warpmail.net> URL: https://gitlist.dev/e/4A775C20.9070109%40drmicha.warpmail.net In-Reply-To: ``` Jan Engelhardt venit, vidit, dixit 03.08.2009 15:39: > > On Friday 2009-07-31 18:22, Michael J Gruber wrote: >> Jan Engelhardt venit, vidit, dixit 31.07.2009 17:51: >>> To determine the rebase point (i.e. first commit in a series), >>> one can (ab)use git-merge-base: >>> >>> p=$(git merge-base ab80794f faae2553) >>> git re -i ${p}^ >>> >>> The twist is that merge-base in git 1.6.3.3 happens to ignore any >>> further arguments following two IDs. In short: >>> >>> git merge-base A B C... >>> >>> Only yields the merge-base of A and B, and ignores C... >> >> Uhm, are you sure about this? >> The first argument is special. merge-base computes the merge base between two commits: >> - the first argument >> - a (hypothetical) merge between all other arguments. >> It may look a if C was ignored, though. > > Hm indeed. Is there a better way to find the common ancestor of commits? I haven't tested thorougly, but at least for the standard example git show-branch --merge-base A B C seems to do what you want. Note that for this command, the order of arguments is irrelevant, whereas for git merge-base it makes a huge difference. Also, git show-branch documentation is a bit outdated. I expect to look into this... Michael ```