Conventional Commit messages have big https://goomics.net/361 energy. Or at least the mechanisms that repositories use to programmatically enforce their use.
(I can't believe nobody has pointed this out yet.)
Conventional Commits encourages focus on the wrong things
241–250 of 294 posts
Re: Conventional Commits encourages focus on the wrong things
#242Earlier quoted context omitted.
Reminds me of a place I worked at where a "naming committee" had to approve variable names. And no, you could not use "i" as an index in a one-line loop.
i and j etc is bad though, but for a different reason than usually claimed. it's suboptimal because it's hard to search for. just use ii, jj, kk, etc
If you need to search for a variable named i - you should have named it something else (and no, jj is NOT an improvement in that case).
One letter variables are supposed to be used in scopes that fit on the screen completely. You might as well search for "for"
TL; DR: it's on purpose.
Re: Conventional Commits encourages focus on the wrong things
#243As programmers I feel like we'll always nitpick and bitch over what the optimal setup is for rather mundane things (tabs v spaces, yada yada). I'm not saying that conventional commits are God's given best way to structure a commit message, but they are a defined structure , and I find it much more effective and important that some expectations be set around commit messages, and I think conventional commits are as goo…
Great perspective! As a sidenote, I really like json5 for everything that would be needed for a human to read and it has great support everywhere. It fixes so many of JSONs shortcomings like comments.
Edit: forgot the link if anyone’s interested https://json5.org/
Re: Conventional Commits encourages focus on the wrong things
#244As programmers I feel like we'll always nitpick and bitch over what the optimal setup is for rather mundane things (tabs v spaces, yada yada). I'm not saying that conventional commits are God's given best way to structure a commit message, but they are a defined structure , and I find it much more effective and important that some expectations be set around commit messages, and I think conventional commits are as goo…
Who reads commit messages anyway?
Commit messages are usually more useful than code comments. For one thing they change when the code changes, so they are much less likely to lie.
Re: Conventional Commits encourages focus on the wrong things
#245Earlier quoted context omitted.
Defined structure does not constitute quality. A commit message can be loosely structured, but be very insightful and good at communicating the nature of the change. On the flip side, one can make a very structured but confusing or non-informative commit message. I generally tend to agree with the author, conventional commits do not solve the core issue of the poor commit messages problem.
Conventional commits made it easier to generate changelogs and automate semantic version bumps. I suppose LLMs can usually do that the right way with looser structure, but in the before times it made a lot more sense, and even now is much less ambiguous
I suppose it is a significant downside that you could get misled into thinking you can autogenerate a changelog from commit names.
Re: Conventional Commits encourages focus on the wrong things
#246Earlier quoted context omitted.
Curious: what are the primary advantages you see?
I'm not yolkedgeek but I can give my own answer: EDN has tags. Tags start with `#` and are followed by a symbol (which is a lot like an identifier except that a lot of punctuation is allowed in symbols, because EDN derives from Lisp syntax rules). The `/` character is used for namespacing, and a user-defined tag must use a namespace. The tag meaning is application-defined, but there are a couple standard tags with we…
I haven't used EDN, but I know YAML has an equivalent feature, and that had been a security issue in some instances because it deserialized into objects the system wasn't expecting. Perhaps their deserializer had learned from that doesn't have that issue?
Re: Conventional Commits encourages focus on the wrong things
#247Earlier quoted context omitted.
I'm not yolkedgeek but I can give my own answer: EDN has tags. Tags start with `#` and are followed by a symbol (which is a lot like an identifier except that a lot of punctuation is allowed in symbols, because EDN derives from Lisp syntax rules). The `/` character is used for namespacing, and a user-defined tag must use a namespace. The tag meaning is application-defined, but there are a couple standard tags with we…
I haven't used EDN, but I know YAML has an equivalent feature, and that had been a security issue in some instances because it deserialized into objects the system wasn't expecting. Perhaps their deserializer had learned from that doesn't have that issue?
Haven't used EDN myself but from a read through the docs, I'm pretty sure that on user tags, the deserializer just says "Here's the tag, and here's the object it was tagging" and lets the consuming code decide what to do with the tag. (And on canonical tags like dates and GUIDs, there's no security risk to deserializing them as the recipient language's version of timestamps and UUIDs).
Actually, https://github.com/edn-format/edn says "It is envisioned that a reader implementation will allow clients to register handlers for specific tags. Upon encountering a tag, the reader will first read the next element (which may itself be or comprise other tagged elements), then pass the result to the corresponding handler for further interpretation, and the result of the handler will be the data value yielded by the tag + tagged element, i.e. reading a tag and tagged element yields one value. This value is the value to be returned to the program and is not further interpreted as edn data by the reader."
So if the client is specifying the handlers, then it's up to the client's handler implementation to sanitize the incoming data before instantiating the objects. And since the client supplies the list of handlers, the only tags that will be handled are ones the client was expecting. Assuming sanitizing the incoming data before instantiating objects is done correctly, I don't see any way for that to become a security issue.
Re: Conventional Commits encourages focus on the wrong things
#248Conventional commits is one of the weirder cargo-culty things we do in this industry. I do take issue with this, though:
> Automatically determining a semantic version bump (based on the types of commits landed): This sounds nice, but the realities of software engineering often interfere significantly with the viability of accurately accomplishing this... imagine a situation where the breaking change you introduced was actually so breaking that you have to revert it... maybe the breakage is subtle and you don’t realise a change is a breaking change when you make the change. Only in retrospect realise that it’s breaking. You will incorrectly increment a minor/patch version when a major version bump is necessary...say you later add a commit which, in composition with a previously breaking commit, results in a diff which is not breaking. Similar to the revert situation, tooling would incorrectly identify a breaking change.
This is a problem with Semver, not conventional commits. You're liable to do this regardless of how your commits are formatted, which is one of several reasons why conventional commits are silly. But in this case, Semver itself drew semantic lines that aren't clear, and are easily broken.
Re: Conventional Commits encourages focus on the wrong things
#249Earlier quoted context omitted.
i and j etc is bad though, but for a different reason than usually claimed. it's suboptimal because it's hard to search for. just use ii, jj, kk, etc
If you need to search for a variable named i - you should have named it something else (and no, jj is NOT an improvement in that case). One letter variables are supposed to be used in scopes that fit on the screen completely. You might as well search for "for" TL; DR: it's on purpose.
Also the fact that every search function since the dawn of interactive computing can search for whole words only (like -w in grep or C-w in emacs).
Re: Conventional Commits encourages focus on the wrong things
#250Earlier quoted context omitted.
> The only thing I've found useful, and which the article doesn't even consider, is a link / id for the relevant change request. The commit already contains all the information about what was done in the change, what's missing is the context about why. The "why" is THE thing that needs to go in the git commit message. Capturing "why" is the entire point of that message and slapping a link to some external (and eventu…
It is a good substitute. 1. Usually the commit message is often too short to capture the "why" adequately. 2. It is very beneficial to capture the why in one single source of truth, and that usually is not the Git commit message in a business context. Hate on Jira all you want, but if you capture the "why" there, you can add comments, view history, add rich context, link dependencies, add rich context, etc. Can't do…
Jira contains discussion and requirements. It can meander for months before the right action is chosen. It can be important to have background, but it replaces the mailing list discussion that led up to the change, it does not replace the commit message.
The commit message is writen in retrospect and is written for someone with the code in front of them to explain why this change was made, and why it was done in this particular way.
If your commit message is too short then than is your problem right there. The easy fix is you taking five seconds out of your busy day to save an hour for you readers.
Have you seen how commit messages are written for git itself, or for the Linux kernel? Let me help you by linking the currently latest commit in the github mirror of git, it is not chosen to be particularly good or bad but is pretty representative of how git developers write commit messages: https://github.com/git/git/commit/b809304101
As you can see, without knowing much of the specifics of the code, we can get an idea why this change was made the way it was. There is a certain art to writing short and concise commit messages, but the same is true for code itself. Some, but comparably very little, practice is required.