Hi Gabriel,
interesting, mildly contentious, and with some practical application difficulties all at the same time… a few observations:
- Having a full explanation in the commit message is a non-starter IMHO, we cannot ask committers to repeat the level of detail provided in the ticket. I believe we’ll eventually switch to another issue tracking, yes, but it’s not a problem, as long as we remember to include the GEOS-XYZW reference in the new issue title. E.g. we could have a Github issue titled “GEOS-11625: Add ‘Challenge Anonymous Sessions’ Option to AuthKey Filter” and the problem is gone, one can easily search by id to find the issue, with full details, screenshots, and eventual discussion.
- I also dislike all the small/temporary commit messages that provide no useful information, but I’m also aware of the git rebase gymnastic I have to go through every time I make a pull request, and I’m not sure knowledge to keep a cleaner commit history is commonplace. For those PRs I normally end up squash-merging, especially when I already had to go back and forth 10 times with the contributor about other more critical stuff (code issues).
- When squash merging and backporting, the backport is still composed of many small commits… that’s something that I would like to see solved but I have higher priorities in my spare time to do list (e.g. CITE tests). Anyone interested in having a look? Maybe the backport bot has some settings to avoid it, or code changes are needed.
- The request to keep the history to a minimum is right there in the checklist BTW, the issue is that we’re not enforcing it… is there any bot that can control the final commit message for common misbehaviors and just prevent the merge? In the end, that’s the only way we’ll get it done systematically, asking the merger to pay more attention won’t get us very far.
- Btw, I apologize for the GEOS-11673 example, I forgot to squash merge there.