Disable merge commit in PRs - only enable squash merging to tidy up the commit history

[hendrywiranto]

Hi!

I saw that the project recently has multiple PRs merged, but the commit history in master is bugging me since it has multiple merge commit that feels unnecessary
Can we just enable the squash and merge option for the repo?
like this

also please do correct me if there is a reason for this.. many thanks 🙏

[brackendawson]

I'm selective about my use of squash merging. If the author has done a great job they might have clearly distinct commits for the parts needed to implement a feature, the ability to revert a single one of those is lost if you squash.

On the flip side someone has commits like "and another thing" then I will probably squash it.

The Go project seem to be happy with the results of doing only rebase merging to clean up their history.

[brackendawson]

Though, going back in time it looks like @boyan-soubachov always squashed?

[brackendawson]

The repo is currently set up as so:

I didn't do that, so I'd like to hear from the person that set it.

[hendrywiranto]

If the author has done a great job they might have clearly distinct commits

I think it's good if all authors have the same mindset at this, but often times it's not and reverting 1 part of the PR is rare compared to reverting the whole PR itself (just in my opinion)

[ccoVeille]

I agree merge commits in commits history is noisy.

I agree that we could avoid them when there is only one commit in the PR. The one that could be easily reverted.

But if we do that I feel we lost somehow the PR identifier in the commit history. I can live with that.

I wouldn't be against using squash to merge when the commit history in the PR is the result of iterative changes due to the code review process, and it's messy and we face an inactive contributor. Or someone who is not a ninja in using git rebase --interactive

But all these are in fact "merge policy for maintainer" that we could discuss further and document

[dolmen]

I don't want sqash commits.

But I also don't want dirty commits, so in reviews I'm asking authors to do cleanups.

Personally I do great care at making specific focused commits and carefully document them, amending when necessary. I don't want another maintainer to come and squash them at merge time.

[dolmen]

This said, we should have more automated feedback about commit message quality, so contributors would clean that early for more constistency in messages.