RFC: Organisation of commits in pull requests

[Kim Shepherd]

Hi all,

In today's dev meeting I asked whether we should review and discuss our contribution guidelines with respect to how commits are organised within a single pull request.

Some larger PRs that require small tweaks after reviewer feedback or CI test failure can end up with a large trail of tiny "fix" commits which make it hard to isolate a single feature or fix to a set of commits (for cherry-picking to other branches, for example) and just generally make our commit tree a bit less readable.

I also personally think we should try to avoid merge commits in our PRs, because they make it a bit harder to read and move/pick the changes around.

Tim pointed out that we also have the 'Squash and Merge' option when merging a PR, and this might be enough to use for some smaller PRs that don't already have a tidy list of commits, and we all noted that there are often good reasons to have specific changes or sub-tasks within one feature or fix split out into separate commits.

Any thoughts or ideas? Existing guidelines or standards for commit management that we could use as a starting point?

Cheers

Kim

0CCB D957 0C35 F5C1 497E CDCF FC4B ABA3 2A1A FAEC