I’m ok with squashing, but if the PR only has one commit in it, then a rebase and merge seems appropriate.
Dan > On Oct 23, 2018, at 5:19 PM, Driesprong, Fokko <[email protected]> wrote: > > Hi all, > > Allow me to start the great debate. > > > > I would like to get the Avro's dev-community's opinion on the merge strategy > of pull requests. By default Github supports three options: > - Create a merge commit > - Squash and merge > - Rebase and merge > https://help.github.com/articles/about-merge-methods-on-github/ > <https://help.github.com/articles/about-merge-methods-on-github/> > > Currently I see the PR's being merged into master using the merge commit > (with some exceptions). From my perspective this has two major disadvantages: > - It will add ugly merge commits on top of master, which don't add any value. > - The git commit tree history isn't lineair. For example, a PR that has been > merged recently <https://github.com/apache/avro/pull/270>, added a commit > back in 19 dec 2017. > - It makes it tricky to revert commits, since a PR merged using a merge > commit might add one or more commits over the history of master. > > Therefore I would only allow two merge strategies: > - Squash and merge: This will squash all the commits of the PR into one > single commit, and push it on top of master. This should be the default > strategy. > - Rebase and merge: This can be used for very big PR's, in which you don't > want to squash the original. > > Github allows us to disable merge-options. My suggestion would be to disable > the merge commit option, but I'd like to get the community's opinion on it. > > Cheers, Fokko > > -- Daniel Kulp [email protected] <mailto:[email protected]> - http://dankulp.com/blog <http://dankulp.com/blog> Talend Community Coder - http://talend.com <http://coders.talend.com/>
