MAINT: use "Squash and Merge" for merging PRs? about simpeg HOT 7 CLOSED

cc @lheagy @jcapriot

from simpeg.

After discussing this topic in today's meeting, @jcapriot expressed he's in favor of using Squash and Merge.

So if we all agree on that, we can implement the change and set Squash and Merge as the only way to merge PRs to main.

from simpeg.

Thanks for raising this @santisoler! I am supportive of using Squash and Merge. There is the drawback of not having the full (and messy -- but real life :) ) history, but to me that is far outweighed by easy navigation of the purpose of changes and the peace-of-mind that we could always revert back to a valid and passing state.

In terms of capturing this decision, would a pr that updates the contributor guide be fitting?

from simpeg.

Sure! We can add some words to the Contributors Guide explaining how the merge process works with Squash and Merge. In there we can also instruct contributors to be more thorough with the PR description, rather than with commit messages.

from simpeg.

I've just configured Squash and Merge as the only way to merge Pull Requests in the repo. And I've opened #1375 to include some details in the docs about the merge process.

from simpeg.

Late to the game - and something I am not particular good myself, but it might be worth to add it to the docs @santisoler where you explain the process: Given the Squash & Merge as only option, it is also good to make as small PR's as possible, and each PR should "ideally" only address one thing - not massive PR's adding a feature, fixing some things, correct a few typos, remove a deprecated feature, etc., all in one.

from simpeg.

I fully agree on that. This is something we've been enforcing and promoting in the past years. But we should probably make it more explicit in the docs. Thanks for the input @prisae!

from simpeg.