On Thu, Feb 21 2019, Jeff King wrote:
> 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.
Yes it's a regression. Here's a fix for it. As seen in 2/2 how we got
to the point of regressing was an interesting combination of factors.
Ævar Arnfjörð Bjarmason (2):
rebase tests: test linear branch topology
rebase: don't rebase linear topology with --fork-point
builtin/rebase.c | 6 +++--
t/t3421-rebase-topology-linear.sh | 44 +++++++++++++++++++++++++++++++
2 files changed, 48 insertions(+), 2 deletions(-)
--
2.21.0.rc0.258.g878e2cd30e
