* Have git-merge-base support multiple IDs
@ 2009-07-31 15:51 Jan Engelhardt
2009-07-31 16:22 ` Michael J Gruber
0 siblings, 1 reply; 4+ messages in thread
From: Jan Engelhardt @ 2009-07-31 15:51 UTC (permalink / raw)
To: git
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?
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Have git-merge-base support multiple IDs
2009-07-31 15:51 Have git-merge-base support multiple IDs Jan Engelhardt
@ 2009-07-31 16:22 ` Michael J Gruber
2009-08-03 13:39 ` Jan Engelhardt
0 siblings, 1 reply; 4+ messages in thread
From: Michael J Gruber @ 2009-07-31 16:22 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: git
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Have git-merge-base support multiple IDs
2009-07-31 16:22 ` Michael J Gruber
@ 2009-08-03 13:39 ` Jan Engelhardt
2009-08-03 21:52 ` Michael J Gruber
0 siblings, 1 reply; 4+ messages in thread
From: Jan Engelhardt @ 2009-08-03 13:39 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git
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?
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Have git-merge-base support multiple IDs
2009-08-03 13:39 ` Jan Engelhardt
@ 2009-08-03 21:52 ` Michael J Gruber
0 siblings, 0 replies; 4+ messages in thread
From: Michael J Gruber @ 2009-08-03 21:52 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: git
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
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2009-08-04 12:30 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-07-31 15:51 Have git-merge-base support multiple IDs Jan Engelhardt
2009-07-31 16:22 ` Michael J Gruber
2009-08-03 13:39 ` Jan Engelhardt
2009-08-03 21:52 ` Michael J Gruber
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).