On Thu, Feb 21, 2019 at 03:50:38PM +0100, Ævar Arnfjörð Bjarmason wrote:
> > 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
