Re: BUG: 2.11-era rebase regression when @{upstream} is implicitly used

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Feb 21, 2019, 14:50 UTC
Message-ID: <87bm355h6p.fsf@evledraar.gmail.com>
In-Reply-To: <20190221141042.GA21737@sigill.intra.peff.net>

On Thu, Feb 21 2019, Jeff King wrote:

Show 27 quoted lines

> On Thu, Feb 14, 2019 at 02:23:04PM +0100, Ævar Arnfjörð Bjarmason wrote:
>
>> This is not a 2.21 release issue, and pre-dates the built-in rebase.
>>
>> When you clone any repository, e.g. git.git, and add one commit on top
>> of the cloned branch, then run "git rebase" you'll get e.g.:
>>
>>     $ git rebase
>>     First, rewinding head to replay your work on top of it...
>>     Applying: foo
>>
>> Before 4f21454b55 ("merge-base: handle --fork-point without reflog",
>> 2016-10-12) you'd get:
>>
>>     $ git rebase
>>     Current branch master is up to date.
>
> I'm not entirely sure this is a regression, and not the patch bringing
> the behavior into line with what would happen when you _do_ have a
> reflog.
>
>> The results are not the same for "git rebase @{u}" or "git rebase $(git
>> rev-parse @{u})":
>
> Those aren't using "--fork-point", so they're going to behave
> differently. The default with no arguments is basically "--fork-point
> @{u}".

Yeah, that's what it *should* do, but it's not equivalent to using --fork-point manually:

    # my series on top of origin/master
    $ git rev-parse HEAD
    2a67977d3f70fa7fc4bce89db24a1218dc9ab2aa
    
    # Junio's origin/master upstream
    $ git rev-parse @{u}
    35ee755a8c43bcb3c2786522d423f006c23d32df
    
    # Where my fork point is
    $ git merge-base --fork-point @{u}
    35ee755a8c43bcb3c2786522d423f006c23d32df
    
    # OK
    $ git rebase 35ee755a8c43bcb3c2786522d423f006c23d32df
    Current branch master is up to date.
    
    # OK
    $ git rebase $(git merge-base --fork-point @{u})
    Current branch master is up to date.
    
    # ???
    $ git rebase
    First, rewinding head to replay your work on top of it...
    [...]