Re: git rebase behaviour changed?

From: Martin Langhoff <martin.langhoff@gmail.com>
Date: Jan 17, 2006, 06:52 UTC
Message-ID: <46a038f90601162252y7e2d9227p4eb4091b653d5c6d@mail.gmail.com>
In-Reply-To: <43CC89DC.5060201@codeweavers.com>

On 1/17/06, Mike McCormack <mike@codeweavers.com> wrote:

Show 6 quoted lines

>  > summary was: "if you do a merge, do not rebase; if you are going
>  > to rebase, do not merge".  The thread is this one:
>
> I want to do rebases.  So is it that behaviour of "git pull" that has
> been changed to do merges, and I should be using "fetch" instead of
> "pull" or something similar?

Now, I have realised that a simple mistake (merging from origin in you scenario) would lead git-rebase to discard earlier patches during the rebase. If you had a single commit *after* the merge, git-rebase would have rebased that single patch, and dropped earlier patches.

git-rebase should refuse to run in the above scenario. Is there a straightforward way to ask if the merge base is "shared"?

<thinking> If the commit following right after the merge base on "our" side is a merge commit, there's a good chance we're about to fuck up. To make double sure, we can walk up that commit to the other parent (the one that is not the merge base for the current merge) and get what merge base between that commit and the current merge base. If it returns anything interesting, we bail out if we are conservative -- or walk up the history again if we take a more adventurous approach.

If it returns empty, it's a splice merge and get outta here -- you are not supposed to rebase a splice merge. And if the merge after our original merge base was an octopus, die too. Those are not rebasable either. </thinking>

So, the conservative (and easy) approach would be to make rebase bail out when it finds any merge commit.

cheers,

martin