How to automatically rebase?

[snowzurfer]

When merging a chain of PRs that I created with revup on the main branch of the repository, say main, I notice that the commits of the previous PRs get put in the newer PRs.

How can I make it so that this doesn't happen?

[jerry-skydio]

hello! 👋

for revup chains to work properly (ie prs get retargeted to the base branch and are immediately ready to merge) you need to set up your repo to do real merges. if it is setup to rebase on merge, this rewrites the commit hashes and git will no longer know how to handle follow-ups. squash on merge is even worse and will break multi commit PRs completely (because git rebase won't know to drop them when pulling)

[snowzurfer]

Thank you, using real merges worked.

[snowzurfer]

@jerry-skydio I've been doing real merges for a bit now with revup, and I've noticed that the history in main gets very messy: it has both the merged PR commit, and the commits from the branch. Ideally, I'd like the behavior that one gets from squash on merge.

How could I go about preserving the functionality of revup, without polluting the main with "double" commits?
Notic here how after doing real merges on the revup-created PR, main has both the merge commit, and the old branch's commit.

[jerry-skydio]

unfortunately these are the only options that github provides https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/about-merge-methods-on-github. you can see they specifically mention that there is no support for fast-forward merges, and that rebase on merge will always rewrite commit ids. with github as it is right now, there isn't a way to get both of no merge commit and automatic follow-up retargeting. note that this is not specific to revup, that is to say that you cannot avoid these limitations by manually creating relative prs.

it seems that gitlab does support a fast forward option for merge prs https://docs.gitlab.com/user/project/merge_requests/methods/, maybe github will one day support this with enough pressure

[snowzurfer]

I see, thank you. Do you think I could write a github action that listens to a label being present, and does fast forward merges?

[jerry-skydio]

maybe, you'd have to give that github action push access to the repo which has security implications in a company setting. but if its a personal project it could work