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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html