11 Matching Annotations
- Jun 2021
We also get a hook to alter commit messages so that they include a common suffix. We can then use this to set up a server-side hook that refuses changes that don’t have this in their messages.
- Mar 2021
- May 2020
I encourage people to write good commit messages, with a good description that explains what it does.
Personally I enjoy writing commit messages
It seems weird to me that we are trying to enforce commit messages when they are not really visible or used in the GitLab workflow at all. This is what you see most of the time when interacting with the commit list. I've taken time to compose a nice descriptive body and it is hidden by default:
which might or might not be useful depending on what is the content of the commit.
One way of encouraging users to create good commit message would be to have a better integration with the content of commit message in GitLab itself,
This also ties in the "Single Source Of Truth", where even if I craft descriptive commit messages I will probably have to describe what I did in the MR comments anyways, so that feels like duplicate work.
I never understood why we enforce The commit body must not contain more than 72 characters per line.
It is considerably harder to write proper sentences when you have to insert an enter every now and then just to follow the rule.
- arbitrary rules/policies
- good commit messages
- annoying restrictions
- this could be improved
- duplication of work/effort
- arbitrary limitations
- it depends
- commit messages
- line length
- hard work unappreciated / wasted / done for nothing
- I have this problem
- Nov 2019
You should not only say what you did, but also why you did it. It’s even more useful if you explain why you did this over any other options.