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

From: Jeff King <peff@peff.net>
Date: Feb 21, 2019, 15:10 UTC
Message-ID: <20190221151009.GA24309@sigill.intra.peff.net>
In-Reply-To: <87bm355h6p.fsf@evledraar.gmail.com>

On Thu, Feb 21, 2019 at 03:50:38PM +0100, Ævar Arnfjörð Bjarmason wrote:

Show 31 quoted lines

> > 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...
>     [...]

Have you tried with "git rebase --fork-point"? It does more than just pass --fork-point to merge-base. It seems to also skip some of the "is up to date", I think due to 1e0dacdbdb (rebase: omit patch-identical commits with --fork-point, 2014-07-16).

I'm still not clear on whether my 4f21454b55 actually changed something menaingful here, or if it's simply that you're getting the fork-point behavior more consistently.

-Peff