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!!
