threads / discuss / 20320

Have git-merge-base support multiple IDs

Subject: Have git-merge-base support multiple IDs

## tl;dr

4 messages between Jul 31, 2009 and Aug 3, 2009.

replies: 3people: 2as markdown or json

Jan Engelhardt· Jul 31, 2009, 15:51 UTC · lore

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· Jul 31, 2009, 16:22 UTC · re: Jan Engelhardt · lore

Re: Have git-merge-base support multiple IDs

Jan Engelhardt venit, vidit, dixit 31.07.2009 17:51:

Show 28 quoted lines

> 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· Aug 3, 2009, 13:39 UTC · re: Michael J Gruber · lore

Re: Have git-merge-base support multiple IDs

On Friday 2009-07-31 18:22, Michael J Gruber wrote:

Show 19 quoted lines

>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· Aug 3, 2009, 21:52 UTC · re: Jan Engelhardt · lore

Re: Have git-merge-base support multiple IDs

Jan Engelhardt venit, vidit, dixit 03.08.2009 15:39:

Show 23 quoted lines

> 
> 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