# Usability issue with rebase fork-point option

2 messages from 2017-12-18 to 2017-12-18. Participants: Robert Dailey, Junio C Hamano.
Thread: https://gitlist.dev/t/47458

## Robert Dailey, 2017-12-18 15:47

Subject: Usability issue with rebase fork-point option
Message-ID: <CAHd499BwrEAxoGX++xRJz_p-_7Uh7vm=+FstRbCv1+wqeCiYbw@mail.gmail.com>
URL: https://gitlist.dev/e/CAHd499BwrEAxoGX%2B%2BxRJz_p-_7Uh7vm%3D%2BFstRbCv1%2BwqeCiYbw%40mail.gmail.com

```
When upstream is not specified for the rebase command (e.g. I just do
`git rebase`), `--fork-point` is assumed which results in commits
regenerating SHA1 even if the merge-base would otherwise be identical.

Here's my scenario:

I set my remote tracking branch to my parent branch:

$ git branch -u origin

I do a status to see that I'm 1 ahead:

$ git status -sb
## feature/foo...origin/master [ahead 1]

I then execute `git rebase`:

$ 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.


The expected behavior is that if merge-base does not change, even with
--fork-point enabled, that SHA1's do not get rewritten.

As a workaround, I've created an alias that always assumes --no-fork-point:

[alias]
    rb = rebase --no-fork-point


Possible long term solutions I'd be happy with:

1. A config option to disable fork point completely, something like
`rebase.forkPoint` and I can set it to `false`.
2. Change rebase to always assume `--no-fork-point` as a default,
which is opposite of the current behavior.
3. Assuming the behavior I'm observing is a bug, put more priority on
a matching merge-base instead of the reflogs, not sure of the
internals of how this fork-point behavior is implemented, but this
feels like the issue to me. The most ideal outcome is that this is a
bug and no interface or config changes are needed.

Would love to get feedback from the Git community on this. Thanks for reading!!

```

## Junio C Hamano, 2017-12-18 18:54

Subject: Re: Usability issue with rebase fork-point option
Message-ID: <xmqqbmivyih1.fsf@gitster.mtv.corp.google.com>
URL: https://gitlist.dev/e/xmqqbmivyih1.fsf%40gitster.mtv.corp.google.com
In-Reply-To: <CAHd499BwrEAxoGX++xRJz_p-_7Uh7vm=+FstRbCv1+wqeCiYbw@mail.gmail.com>

```
Robert Dailey <rcdailey.lists@gmail.com> 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.

```