Required squashing in PR

[Jarod42]

Not sure why you want squashing,

but instead of requiring to do it manually/individually in PR (which is error prone (#1773 closed accidentally), and make incremental review not possible),
it seems that it can be done automatically with merge button with some settings (https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/configuring-commit-squashing-for-pull-requests).

[KyrietS]

This may not be very important, but as far as I know when doing a squash commit the author of the code is the person who clicks the merge button. Therefore, the original author's contribution will not be noted in the change history. I can imagine someone being upset about that.

[Jarod42]

Interesting...
I didn't think about that (and I think Premake contributors are extracted from git log or similar).

From what I quickly read from isaacs/github#1303, they changed/fixed behavior of squash-merging regarding author/co-author in 2020.

[KyrietS]

Oh, it's good to know they fixed it. If the author of a PR is the author of a commit in repository, then I am neutral about squashing commits 👍

[samsinsane]

Not sure why you want squashing

The goal is to avoid consecutive commits of "wip" or "fix", and instead have a concise commit message of "Added X". Secondly, we're not aiming to squash into a single commit, we're just aiming for logical commits. A PR for a large feature may require multiple commits, but we don't need 5 commits for 5 lines changed in a single PR.

Also, as @KyrietS mentioned, the author information is mangled - the issue you link is still open with issues around the author information. Secondly, according to the GitHub docs here there is no merge commit when you squash and merge but maybe there is and they're just being vague about what happens? Regardless, I believe we would still like that merge commit to exist.

While I agree that people not knowing how to do certain things in git does pose an issue, I don't think changing how we expect PRs to be done is the right path forward. Failing people finding the answer on Google, perhaps an example git command could be provided or a guide could be linked?

[Jarod42]

The goal is to avoid consecutive commits of "wip" or "fix".

You ask it even for relevant (IMHO) commit messages :-)
but that not my point. It is opinion based (and again, we might not have the same opinion ;-) ).

I just wanted to highlight an alternative to simplify the process.
but it seems authors information was/is problematic with that :-/
(Maybe can be retested with their changes from 2020+).

I consider my proposal/question answered.