It would be nice to have an autosquash option in github merge button, this will help people to check for corrections in github review.
Send a PR
- Test commit
Fix the PR after the review with fixup!:
- Test commit
- fixup! Test commit
And, if the PR is approved and merged the history could be:
- master old commit
- Test commit
Right now we have already some good merge options here.
But rebase with --autosquash option, and not a normal squash or merge could help us to do better reviews and catchup corrections around the commit history.
I want to make sure I understand what you're requesting. How is what you're proposing better than doing a rebase with autosquash before the PR is merged and then using the standard merge options?
When doing rebase with autosquash before the PR you must force push if any fixup comes up.
If you can rebase with autosquash on GitHub, no force push is needed.
I, too, would like to see an `--autosquash` option in the web interface.
Github's support for working with forced pushes is less than stellar. In general it's hard to figure out what changed between revisions and in turn this makes it harder to keep track of comments. Only for providing a comparison point, Gerrit supports a workflow where forced pushes are more common, only that it does not call it that, nor are those necessary. In Gerrit each revision gets its own pseudo-branch so it's possible to compare between revisions as if you were comparing branches. In Github by contrast this does not exist, so there are two options:
1. Add new commits, never force-push. If the intention of the developer is to merge a single commit, they can choose to squash the whole thing and all the PR noise disspaears. If they don't do this and simply merge the PR as is, you end up with a lot of PR noise in the repository ("fixing linter errors", "addressing comments", "fix build error", "merge master into ...", etc).
2. Locally fix the commits, force-push. This keeps a clean history, but it makes it harder to work with the web UI.
Option 1 also makes it hard to create a PR that contains multiple clean steps: "adding API for this", "using new API for that", etc.
If Github supported the git convention of "fixup!" it would be possible to use 1. and simply rebase and squash when it's time to merge the PR into the target branch. This would make it easier to keep track of the changes and comments, and works better with the existing web UI.
Indeed, @mem nails it. Fixup commits allow iteratively working on things and providing a clear timeline of changes to reviewers while enabling a clean commit when rebasing. If Github enabled the "--autosquash" option when doing rebase&merge on the web UI, we wouldn't have to go through the hassle of locally rebasing and force-pushing before merging once the PR is approved, and the commit message would be cleaner than when using squash&merge.
In addition, commit suggestions via the review UI should use the fixup convention rather than generic and not so meaningful messages.