Clarify that we use merge commits when mergeing PRs

[daschuer]

No description provided.

[Swiftb0y]

I was not aware we had this policy. Moreover, there have been exceptions in the past where I merged when I should've rather squashed and merge. See: #4108 (comment)

[Holzhaus]

I was not aware we had this policy. Moreover, there have been exceptions in the past where I merged when I should've rather squashed and merge. See: #4108 (comment)

Yes. In general, we should always merge. Squashing should only be done in these cases:

• The PR contains broken (non-building) commits and the contributor is not willing to fix them up.
• Minor changes with lots of back-and-forth where the commits are not worth keeping (e. g. a PR that updates the changelog does not need a separate commit for every typo pointed out during review).
• Controller mapping PRs where the contributor failed to use meaningful commit messages (e. g. "Update Foo.midi.xml", "fixes", "changed stuff", "hurr durr ima sheep")

[Swiftb0y]

Yes. In general, we should always merge. Squashing should only be done in these cases:

Thats fine, but we should write down these exceptions too instead of just saying to always merge.

[daschuer]

I have rephrased the suggestions without the "is not willing" part, because that is another issue where we will find an individual solution.

In general we should stick with the "Merge pull request .. " commits whenever possible for consistency when crawling through the git tree.

[daschuer]

Does this fit to your needs?

[Holzhaus]

Thank you. pre-commit complains about trailing whitespace. Please fix, then we can merge IMHO.

[daschuer]

Done

[Be-ing]

Whoa there. I didn't even have a chance to comment before this was merged. I am opposed to this. In my experience this policy is unusual and unwarranted. Most projects do not use merge commits; they rebase.

[Holzhaus]

We shall we revert until the discussion is concluded? Unsure, because in my understanding using merge commits was always our policy until now. Telling people to rebase would be a change IMHO. In any case, squash-and-merge should generally be discouraged.

@Be-ing Can you open a topic on Zulip? I'm pretty much against rebasing because you need to retest every single commit, but let's not discuss that here.

[Be-ing]

Let's continue the discussion on Zulip. No need to rush a reversion.