If the pull request looks like all or some or it should have been squashed, that should be referred back to the author (the first time, authors may need some guidance about how to proceed).
Options like squash on accept that only need to exist because:
- Not all developers are aware of git squash.
- Not all developers are aware of git rebase.
- Not all developers are aware of git amend commit.
- Not all developers are aware that if you force push your change branch, GitHub notices that and correctly treats it as a new version of your pull request (the equivalent of a new patchset in Gerrit).
- And worst of all, some developers clearly never look at what they have actually pushed.
I don't expect people to become experts in git as well as everything else. However, reviews should identify when the pull request is poorly constructed, and that's a good time for a developer to learn how to clean it up.
My ideal workflow would be:
(1) Developer gets the pull request clean, which means one or more commits, where each commit is a suitable size. If a commit has an error (eg a spelling error in a comment), the original commit should be fixed up and replaced; the correction should not be a separate commit. There MUST NOT be any commit in the chain where master is merged into the pull request - that's what rebase is for.
(2) If the clean pull request is a single commit, then that can be rebased master, and then fast forward.
(3) If the clean pull request is a multiple commits, then it's a feature branch, and it can be rebased on master, and then merge (don't FF at this point, even though it is possible, but use a merge so that the series of commits for the feature is preserved).
If you don't like the command line, EGit can do all this.
FWIW!
Matthew
