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

From: Mike Botsko <botsko@gmail.com>
Date: Mar 3, 2015, 23:20 UTC
Message-ID: <CAPfvZp5jTTbWVL0QuZTP83=SWvsvyZWX0BG_q7jPLK5wNNvCgg@mail.gmail.com>
In-Reply-To: <xmqq61ahad18.fsf@gitster.dls.corp.google.com>

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.

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.

On Tue, Mar 3, 2015 at 3:15 PM, Junio C Hamano <gitster@pobox.com> wrote:

Show 14 quoted lines

> 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 ;-).
>

-- 
Mike Botsko
Lead Dev @ Helion3
Ph: 1-(503)-897-0155