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_ ..."

[KeithCheongWaiKeong]

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