Proposal: Set 'rebase and merge' as the standard method for commits

[jasone]

The git history is already looking a bit hairy due to merge commits. I propose that we change the github settings for this repository to default to 'rebase and merge'.

[vjeux]

@JoelMarcey could you set it if you don't mind? Thanks!

[pikatchu]

Are you cool with "squash and merge"?

This seems to be the default right now and I actually like it. Otherwise I usually end up squashing my "mini diffs" by hand on my branch and then push -f to the pull request before merging.

So that option already does that for me :-)

If you feel strongly about it I am happy to change it.

[jasone]

I don't have a strong opinion on squashing, though I tend to think it's something that we should at least be able to opt out of, so that on occasions a pull request can cleanly be broken into multiple stacked diffs, we preserve that. The thing that's bugging me is the messiness caused by merge commits. Here's part of what tig currently shows.

We just need a slightly faster commit rate to make the commit graph inscrutable. Oh, and git bisect gets a bit weirder to work with when merge commits are common. I can live with merge commits, but I view them as an obfuscating force.

[JoelMarcey]

@jasone @vjeux @pikatchu I personally also like squash and merge, but I definitely understand the merits of rebase and merge. Just let me know which way to go here.

I can remove the option of Merge Pull Request if we just want to start there too.

[jasone]

Interesting, it sounds like there's not clear agreement on this, so let's leave things as they are for now. However, I am curious to understand what benefit you see in the merge commits. Do they provide a more detailed commit history that you find useful for some purposes?

[josephsavona]

I can remove the option of Merge Pull Request if we just want to start there too.

@JoelMarcey Do you mean we can remove the option that creates a merge commit? Having just squash-merge and rebase-merge at least means we always keep the commit history clean. Most commits (especially from the community) are small and squashing makes sense, larger commits will likely be from maintainers and they (we) can choose rebase-merge when it makes sense.

[JoelMarcey]

@josephsavona Yep, we can choose any combo.

[josephsavona]

Cool, let's just disable "allow merge commits" and keep squash-merging as the default?

@jasone does that sound reasonable for now?

[JoelMarcey]

Done.