PR's "Rebase and Merge" should not alter commits if the head branch is already on top of the main one

[castarco]

Let's say that we have the following branches:

main: A->B->C->D
new:  A->B->C->D->E->F->G

It's clear that if we rebased new on top of main, nothing should change, the commits should remain as they are (and git, locally, honors this behavior).

Sadly, that's not what happens when we press the PR's "Rebase and Merge" button, the commits are modified, and the attached PGP signatures are lost. This is not how rebases work locally, and neither how they work in other platforms, such as Gitlab.

In order to support more workflows, it would be preferable that Github sticks to more intuitive and common behaviours when it comes to "rebase and merge" pull requests.

Why the current behavior is problematic?
Because it does not allow us to have strict linear history (or to enforce it through the repository rules) and keep our PGP signatures at the same time... unless we commit directly to the main branch.

[mxr576]

Related:
#4618
https://github.com/marketplace/actions/merge-fast-forward-only
https://github.com/marketplace/actions/fast-forward-pr
https://stackoverflow.com/questions/60597400/how-to-do-a-fast-forward-merge-on-github

(Kudos to my colleague, @lekob, who collected these.)

[osievert-gpfw]

When managing a repository, a common task is to go back in time and clean up old stale branches. When those branches are simply references on a linear git history, this cleanup is easy and obvious, and most importantly: reliable. I know I will never lose anything valuable by deleting these kinds of branches, because I know that ALL the branch changes made it to the main branch. This is what happens when you perform a local rebase using git. It is the expected behavior. It is the intuitive behavior.

When branches with the same commits, containing the same changes, do not share the same SHA as the merged commits, it creates a maintenance headache. "Was this branch ever merged? (wastes time looking for the same commits in the main branch). I see it was merged. Hmm, why are the commit SHAs different? Is it because github has a poorly-thought-out merge policy, or is it because there are outstanding changes on this branch that never got merged? (has to deeply compare every.single.commit on the branch with the one that was merged, one by one)." Then repeat this process for every.single.branch in the repository. The worst part, though, is not the hours of my life wasted because of this design decision. The worst part is that my trust in github is eroded. Without putting a bunch of effort into this sort of cleanup, when I use github pull requests there is always a doubt that I might be losing data.

The alternatives are not very appealing:

• don't use pull requests - not ideal because pull requests are simple and easy and a best-practice for teams
• don't use the rebase-and-merge strategy - not ideal because a linear git history is also a best-practice

At the very least, when repository branch protection settings include "Require branches to be up to date before merging", github's rebase policy should match the git rebase policy - do not change the committer timestamp if the branch is already fully rebased.

I appreciate the links to fast-forward actions, but all of this should be the built-in behavior. I should not have to further complicate my pull request workflow by delegating the merge to a github action.

[janderssonse]

I was so upset :) I did a bug report of this to GitHub... at least they are very aware of this and calls it a pain point, so I guess there will be a solution in the future:

"....
a known issue we are tracking internally and a pain point for a number of folks....

Currently reverted pull requests created from a previously squash and merge pull request or a rebase and merge pull request are indeed not signed. You can find some more information about this scenario here.

While we don’t yet have a specific ETA for when this might be implemented, we recommend keeping an eye on our Changelog_ ..."

[kiwiboy-dev]

I've tried to run a pull request after my first rebase and merge PR and GitHub refuses to let me approve the PR and merge at all, stating that I have some kind of conflict. "Resolve Conflict" did not bring me anywhere, and the Desktop app version did not help at all. I've ended up closing that PR and merged my branches locally, after resolving conflicts that should not even be conflicts in the first place. My only guess to why the conflicts exist is because the prior commits on both branches have different SHAs thanks to the rebase and merge PR, which is probably true based on what I've looked up.

Why is that the case? I thought that this is some new policy or best practice that I didn't know of, but I found this thread that is 2 years old. Honestly, I can tolerate rebase and merge changing the SHAs and signatures, but it would be great if there is some kind of reasoning officially stated by GitHub on why this has to be the case in the first place.

But it shouldn't need a big solution since Git and other platforms already serve this feature by default, I don't see why it is taking so long for GitHub to implement a feature to toggle between reusing commits and creating new commits when rebase and merge is selected. I might be wrong on the complexity of the solution, but it's been 2 years... c'mon

[shinebayar-g]

On top of this, squash merge shouldn't generate a new commit sha if it's only merging a single commit. Completely unnecessary.

[Jorropo]

Squash let you change the commit title and description.
By default it adds (#XXX) link to the PR so you would need to manually remove that, and ensure they are equal so it does not do this and then it could not change the hash.

Or the defaults of squash would need to change depending on if there are one or multiple commits, which could also be confusing.

I don't think this is as straight forward as Rebase and Merge when the head is already on top (which literally has no reason to do this).

[andreynering]

I created a related discussion, before noticing this one: #110560.

[mangelajo]

This also becomes a big issue if you are also enforcing signed commits because even if your PR is on top of the branch.

Once you enable branch protection with:

[samveen]

I just hit this issue. First, I was so disappointed that Github had a bug. Then I was so excited that I hit a Github bug, and would get to report it. Finally, the disappoint was back to discover that this is a known issue, and that too from the last 3 years 🥹 .

[mangelajo]

Can we get this fixed please?, it does not make sense that github can sign squash commits, but can't sign rebases.

[pomirkovany]

If this can't be fixed, can we at least get an explanation about why it has to work this way?
On top of that, I think it's wrong to call the operation rebase if the behavior differs from what git rebase does. This is counterintuitive because it's not crazy to assume that Github would follow the default behavior. A different name could have been chosen if this was so necessary

[Slashcash]

This behavior is really frustrating me :(

[vrubleg]

This behavior also breaks local git branch -d branchname (removal of the local branch) and to have to force the operation because local git can't see that the branch was already merged.

[mdalpozzo]

plus one on this issue. blows my mind that true rebase behavior isn't supported by github... do i need to go back to gitlab?

[castarco]

Not the same, but something I started to do because of Github is to fast-forward locally & push directly to main (Github detects it and marks the PR as "merged").

[janderssonse]

Same here but it quickly gets errorprone when working in a bigger team.