Robert Dailey <rcdailey.lists@xxxxxxxxx> writes:
> $ 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.
