Remove implicit rebase during merge when branch is up to date

Our repo settings and policy is:

  1. Only rebase merge strategy is allowed
  2. No merge commits in the master branch
  3. Branches should be up to date.

Use case:

  • Developer creates his branch on top of master, makes a small fix (let’s say, commit SHA is abcabc) and creates a PR.
  • This PR is quickly approved and passes CI. No new commits in master, the branch is still up to date. Commit is still abcabc.
  • PR gets merged as “Rebase and merge”.
  • Someone looks at master branch. Bingo - there is no commit “abcabc”! Github did some implicit rebase by itself when there was no need in this. This led to divergence in the history, this did remove the signature made by the commiter (because SHA is now different and commit is not made by the commiter any more).

Expected behavior: Github should do some kind of “git merge --ff-only”. So if commit(s) are up-to-date, they should be kept as is (for example, look at Gitlab, it does exactly like this).

Please fix this behavior to avoid extra not needed rebase and changing history!

Hey @okainov thanks for taking the time to write this up! I don’t have any experience with this behavior myself, do you maybe have an example?

In addition, I’d recommend reporting any feedback or suggestions at the official form.