Proposal: Set 'rebase and merge' as the standard method for commits about skip HOT 9 OPEN

Done.

from skip.

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

@jasone does that sound reasonable for now?

from skip.

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

from skip.

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.

from skip.

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.

from skip.

@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.

from skip.

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?

from skip.

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.

from skip.

@josephsavona Yep, we can choose any combo.

from skip.