Merge strategy "Squash and merge" at project level about wstg

[ThunderSon]

@kingthorin Moving forward, let's set it to Squash and Merge, and when need be, the reviewer can manually take in all commits. Sounds good?

[kingthorin]

Seems fine to me, but it’s not something I can set.

As things are people can use the drop down on the merge button. (It seems to stick with whichever method was most recently used, until changed again.)

[caperutxa]

I do not like squash strategy for merges.

Squash remove the commit history in benefit to merge in order to obtain a single view to a group of commits but there are ways to see all changes in a group of commits, between tags... and the history commits is not lost

[kingthorin]

IMHO the user's feature branch (for lack of a better term) commit history is irrelevant to the overall project. But that's just my 2 cents.

[kingthorin]

Refs:

• https://help.github.com/en/articles/about-merge-methods-on-github
• https://help.github.com/en/articles/configuring-pull-request-merges

[ThunderSon]

I'd mainly recommend the usage of squash strategy when a lot of bad commits have been committed to a PR. Otherwise, the commits are needed to re-track the changes if need be, instead of having it all in one commit.

[patrickceg]

Should we close this issue? We've been through a whole month of awesome contributions and I don't think this was ever a problem.