Re: git rebase behaviour changed?

From: Junio C Hamano <junkio@cox.net>
Date: Jan 17, 2006, 05:50 UTC
Message-ID: <7vslrnh080.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <43CC695E.2020506@codeweavers.com>

Mike McCormack <mike@codeweavers.com> writes:

Show 11 quoted lines

> git-rebase origin
> -> Current branch refs/heads/master is up to date.
>
> However, I can do the "rebase" manually with:
>
> git branch master-20060117
> git reset --hard origin
> git-format-patch -k --stdout --full-index origin master-20060117 | \
> 	git am --binary -3 -k
>
> Is this broken, or am I meant to be doing something different now?

What does "git-merge-base master-20060117 origin" give you? If it is the same as "origin", then the master-20060117 has been merged with origin, and rebase does not run in this case.

Here is the simplest example:

                  1---2---3---4 master
                 /
        origin  0

Of course, you _could_ extract patches #1, #2, #3, and #4 between origin and master, and apply them on top of #0 to reconstruct "master" as you found out, but there is not much point doing so.

Rebase changes the "master" branch when the development track between you (master) and upstream (origin) have forked:

                  1---2---3---4 master
                 /
        origin' 0---5---6 origin

In this case, things are rearranged by rebase:

                        1'--2'--3'--4' master
                       /
        origin' 0--5--6 origin

End of on-topic answers.

BTW, what this means is that it would not rearrange something like this:

                    2---3
                   /     \
                  1---4---5---6 master
                 / 
        origin  0

But a structure like this could be rebased:

                    2---3
                   /     \
                  1---4---5---6 master
                 / 
        origin' 0---7---8 origin

to produce something like this:

                          1'--2'--3'--4'--6' master
                         / 
        origin' 0---7---8 origin

The ordering of patches may turn out to be wrong; #4 might conflict with already applied #2 and #3. In general, rebasing such a merged structure is highly discouraged. I think there was a discussion on this topic on the list recently, and a short summary was: "if you do a merge, do not rebase; if you are going to rebase, do not merge". The thread is this one:

	http://thread.gmane.org/gmane.comp.version-control.git/14308

Especially please look at a couple of message from Linus:

	http://article.gmane.org/gmane.linux.kernel/365410
        http://article.gmane.org/gmane.linux.kernel/365409
        http://article.gmane.org/gmane.linux.kernel/365501

I guess we could decompose the commit ancestry chain in such a case, and reproduce something like this:

                            2'--3'
                           /     \
                          1'--4'--5'--6' master
                         / 
        origin' 0---7---8 origin

Rebase has never done this, though. It is left as an exercise for the reader ;-).