Re: Unexpected/unexplained difference between git pull --rebase and git rebase

From: John Keeping <john@keeping.me.uk>
Date: Mar 3, 2015, 23:40 UTC
Message-ID: <20150303234057.GR890@serenity.lan>
In-Reply-To: <CAPfvZp5jTTbWVL0QuZTP83=SWvsvyZWX0BG_q7jPLK5wNNvCgg@mail.gmail.com>

On Tue, Mar 03, 2015 at 03:20:48PM -0800, Mike Botsko wrote:

Show 6 quoted lines

> Maybe I'm lacking the distinction regarding what I'm being specific about.
> 
> In both examples, I'm asking it specifically to rebase in changes from
> the remote "upstream" and a named branch at that location. I'm giving
> git the same information, it's just interpreting it differently - and
> I'm not understanding why.

Not quite.  If you say:

	git rebase $sha1

then you're telling git-rebase to apply the commits $sha1..HEAD onto $sha1.

If you say:

	git rebase

then it will be re-written as:

	git rebase --fork-point @{upstream}

in which case Git will apply more complicated logic so that you can recover from the case where @{upstream} has been re-written.

Consider the following scenario:

                      F			branch
                     /
               C -- D			master@{1}
              /
	A -- B -- C' -- D' -- E		master

where C' and D' are rewritten versions of C and D.

In this case, imagine you are at F on "branch", "git rebase master" will replace C, D and F onto E because you have explicitly selected to replay master..branch onto master.

"git rebase" will apply the fork-point logic and realise that D is a previous version of master, so it will only replay F onto E.

In general if you just want to rebase onto your upstream it is simpler to just call "git rebase" which will do the right thing; it's also shorter to type ;-)

Show 5 quoted lines

> My local branch would have been created from the
> upstream/feature-branch, and will eventually be merged back into it.
> Until I'm ready for that, I regularly rebase the work done on
> upstream/feature-branch so that my local work is always clean and
> above anything else.

In this case the problem stems from the fact that upstream/feature-branch has been rewritten. Building on top of branches that will be rewritten is not advisable unless you have a really good reason to do so.

Show 14 quoted lines

> On Tue, Mar 3, 2015 at 3:15 PM, Junio C Hamano <gitster@pobox.com> wrote:
> > John Keeping <john@keeping.me.uk> writes:
> >
> >> git-rebase assumes that if you give an explicit upstream then you want
> >> precisely what you asked for.  From git-rebase(1):
> >>
> >>       If either <upstream> or --root is given on the command line,
> >>       then the default is `--no-fork-point`, otherwise the default is
> >>       `--fork-point`.
> >
> > Correct.
> >
> > You ask it to rebase the history without guessing by being explicit;
> > the command guesses when you are not explicit and being lazy ;-).