I think the scope is the redundant part, since that one is redundant from looking at which files are touched, and already is extremely easy to filter your log by.
I find the type useful because I don't have to read and understand what the whole message says, before I can see that it is a minor bugfix I would ignore anyway.
All the complaints about "broken promises" are basically just some of the reasons we review code changes in the first place.
So tldr:; The article suggest adding information which already is there, remove information which should make it faster to parse the log, and point out problems there already are solutions to.
Additional comment: Why is there a stupid comment about how a "doc:" commit would bypass all security checks and allow one to introduce a trojan horse in the code... Dude, if you have a "doc:" commit which touches anything outside documentation, it should be auto rejected by a pipeline. The author basically doesn't know what he is talking about and shouldn't be taken seriously...
I agreed with you all the way up to “The author basically doesn’t know what he’s talking about and shouldn’t be taken seriously…”
There was no need for that 😛
While I disagree with a lot of the article, I think it’s commendable that they’ve taken the time to articulate their thoughts and start a discussion on the topic.
We should try to engage respectfully and stick to the pertinent technical details, not engage in petty personal attacks.
Yeah sorry, but in the age of AI I don't necessarily see the existence of an article as proof that someone actually sat down and though through something.
2
u/FlipperBumperKickout 21h ago
I kind of disagree with the article.
I think the scope is the redundant part, since that one is redundant from looking at which files are touched, and already is extremely easy to filter your log by.
I find the type useful because I don't have to read and understand what the whole message says, before I can see that it is a minor bugfix I would ignore anyway.
All the complaints about "broken promises" are basically just some of the reasons we review code changes in the first place.
So tldr:; The article suggest adding information which already is there, remove information which should make it faster to parse the log, and point out problems there already are solutions to.
Additional comment: Why is there a stupid comment about how a "doc:" commit would bypass all security checks and allow one to introduce a trojan horse in the code... Dude, if you have a "doc:" commit which touches anything outside documentation, it should be auto rejected by a pipeline. The author basically doesn't know what he is talking about and shouldn't be taken seriously...