"Rebase and merge" should autosquash fixup commits

[dhimmel]

Select Topic Area

Product Feedback

Body

It would be a killer feature if the Rebase and merge method of merging a pull request would apply the git rebase --autosquash argument:

When the commit log message begins with "squash! ...​" or "fixup! ...​" or "amend! ...​", and there is already a commit in the todo list that matches the same ..., automatically modify the todo list of rebase -i, so that the commit marked for squashing comes right after the commit to be modified, and change the action of the moved commit from pick to squash or fixup or fixup -C respectively.

This would allow users to add commits to a PR using git commit --fixup, where fixup is applied to another commit in the PR but not the base branch. Then when rebase merging via GitHub the fixup commits would be automatically squashed into the specified commit. It would save users from having to perform the git rebase --autosquash --interactive locally and having to force push to the PR branch. Force pushing to the PR branch has many downsides including obsoleting CI runs and making reviews anchored to commits that are no longer part of the PR.

[andreas-karlsson]

Killer feature indeed! That's currently the number one annoyance in the PR workflow. PRs getting rebased during or "after" reviews.

[connorjclark]

Please support this. I can get non experienced git devs to use fixup, but not to rebase locally. This would greatly help with PR workflows.

[Castavo]

This would be much appreciated, I have merged too many fixup! commits by accident 🥸

[hickford]

See also GitLab feature request https://gitlab.com/gitlab-org/gitlab/-/issues/212

[justingrant]

If fixup commits aren't autosquashed on merge, at least there should be some sort of warning shown to make it harder to accidentially merge fixup commits.

[tuukkamustonen]

There are several GitHub actions for that, e.g. https://github.com/13rac1/block-fixup-merge-action

[benoitdm-oslandia]

Sorry, but I don't know how these threads work, but should we wait and hope that a GitHub core contributor drops into this discussion or is there something else that needs to be done to get an answer if this is feasible or not? (no offense here)

[dhimmel]

Not sure. I assume the more upvotes this discussion receives, the more likely it is for the request to be evaluated by someone at GitHub for inclusion in their roadmap. 99 upvotes is a good start, tell all your friends!

[alanhamlett]

I don't see any way to filter discussions by number of upvotes, so I bet GitHub employees won't notice this even with many upvotes.

[nicolalunghi-xlnx]

+1100000 here
would solve all the issue with force push

also can be used by the ```suggestion feature -> that could create fixup commits

[Muzer]

100%, the lack of this feature combined with the poor ability to diff across force-pushes basically makes a multi-commit-per-PR workflow needlessly difficult.