Re: Usability issue with rebase fork-point option

From: Junio C Hamano <gitster@pobox.com>
Date: Dec 18, 2017, 18:54 UTC
Message-ID: <xmqqbmivyih1.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <CAHd499BwrEAxoGX++xRJz_p-_7Uh7vm=+FstRbCv1+wqeCiYbw@mail.gmail.com>

Robert Dailey <rcdailey.lists@gmail.com> writes:

Show 9 quoted lines

> $ git rebase
> First, rewinding head to replay your work on top of it...
> Applying: Fix state machine hang after integrity checking
>
> Since my merge-base is already the tip of `origin/master`, I expected
> it to say it was up-to-date, as it would if I disabled fork point:
>
> $ git rebase --no-fork-point
> Current branch feature/foo is up to date.

I haven't studied the symptom deeply enough but I have a feeling that hunk @@ -572,7 +573,7 @@ in 1e0dacdb ("rebase: omit patch-identical commits with --fork-point", 2014-07-16) may be what goes wrong. I do not offhand see why the "already up to date" check need to be bypassed when fork-point mode is in use, and the log message of the commit does not explain the reason behind that change, either.

I wonder what happens if we simply enabled the "avoid unnecessary rebase if we are already up to date" check even when $restrict_revision is not empty.