IIRC, the squash option is only available when GitHub thinks the rebase part will be clean. The committer then has control over the commit message, though it does break things into a "subject" box and a "body" box. the subject is placed first in the message followed by two newlines and then the body.
committers always have the option of handling the PR committing locally. Just please remember to include a note in the message to close the PR[1]. Or manually go close the PR afterwards with a note about when it was merged. [1]: http://hbase.apache.org/book.html#_close_related_github_prs On Tue, Apr 23, 2019 at 11:21 AM Nick Dimiduk <[email protected]> wrote: > > I am +1 for linear commit history. > > Does the “squash” option give the committer enough control over the commit > message format and structure? I personally prefer to perform all of my > commit rewriting locally, verify it locally, and then force-push the > desired history to the feature branch before using the “rebase” variant of > the button. Maybe that process is not necessary with the “squash” option? > > Thanks, > Nick > > On Tue, Apr 23, 2019 at 7:33 AM Sean Busbey <[email protected]> wrote: > > > Folks, > > > > Looking at history for the current master branch, we had several PRs > > accepted over the last week where the committer used the "merge > > commit" option. As a reminder, previous consensus was that we would > > avoid this since it makes the history harder to follow. > > > > Please ensure you are selecting either "rebase commits" or "squash > > commits" when accepting a PR. > > > > I have filed INFRA-18264 to disable the merge commit option. > >
