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 -- All messages to this mailing list should adhere to the Code of Conduct: https://www.lyrasis.org/about/Pages/Code-of-Conduct.aspx --- You received this message because you are subscribed to the Google Groups "DSpace Technical Support" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/d/msgid/dspace-tech/CAKZKfqrSc4gk2Ry0DS1T%2BKqqc8DheVoxGJKNrpBDPpfKDHZrhw%40mail.gmail.com.
