I’d recommend against it. The most prominent aspect of it, the “feat:”, “fix:”, etc. labels, are better done with git trailers. The “module” that appears in parens could be another trailer, if you so desire. You don’t consume valuable bytes in the short message and you lose nothing in terms of search-ability. You could probably even use the trailer values to reconstruct conventional commit format if you really need to see it in that way.
Scope labels are great, but I'd just recommend being super freeform with them. They can help encapsulate what part of a codebase is primarily impacted by them.
Git trailers are neat, but ultimately suffer from a UI issue: most people are using interfaces to git that don't use the plumbing, and they put all the important info in the first line (and sometimes have a frustrating cutoff of 50 characters) and git trailers are considered a remnant that gets no special handling (if you're lucky, the Co-Authored-By trailer has special handling, but that's about it).
If you're trying to quickly conceptualize why the history of a file is the way it is, then being somewhat consistent with scope labeling helps a lot.
In practice, the style will just be different depending on the project. A hobby project doesn't need a hypervigilant git history, given you're usually just using git as a special save button. A rebasing fork will probably want to structure it's commits more on a per-patch basis (since they should be kept on top of all other commits), so most conventional advice doesn't make sense (since the git commit in this situation also acts as the code comment for the patches; you're usually trying to keep patches as small as possible for ease of maintenance). It's when you get professional that you'll want a commit style.
> Git trailers are neat, but ultimately suffer from a UI issue: most people are using interfaces to git that don't use the plumbing, and they put all the important info in the first line (and sometimes have a frustrating cutoff of 50 characters)
It’s not git’s fault if you choose not to use git(1). Trailers work great with it. You can use other tools that claim some level of compliance with git, but you do so with the understanding that YMMV.
I'm just going by the practical reality here; I personally do like using the git commandline, but the reality is that most people are using Git from forges like GitHub and terrible UI programs like, well, GitHub Desktop, which do both of these things.
Ultimately git is a tool for version control and software collaboration, so what you end up doing should encompass the tools that people use. It's easier to find a compromise than to hardline on a position that requires a lot more upfront work (it's much harder to switch people off of software that they are familiar with than you might expect.)
If you limit your quality by what the lowest common denominator tool does you will guarantee that your process deteriorates until you're all just rolling around on the floor gurgling at each other.
The answer to "my tool doesn't render trailers" is not "let's waste the short message" it's "then don't use that crap tool"
I won't recommend it specifically, but I recommend to have a standard. I prefer a standard that I don't like rather than a not having a standard. Other options that I remember:
- Gitmoji: https://gitmoji.dev/, similar to conventional commits but using emoji
Personally we may like them or not. But again, even though I don't like it, I would a history with "<bug emoji>: do foo in bar" instead of a history with a lot of commits only named "fix", "now it works" and things like that.
You don’t need a standard for everything. If standard means a machine-readable format.
> Personally we may like them or not. But again, even though I don't like it, I would a history with "<bug emoji>: do foo in bar" instead of a history with a lot of commits only named "fix", "now it works" and things like that.
It is good to have standards which will disqualify low-quality commit messages.
Having a standard is better than having no standard. If you don't like conventional commits probably you have a commit guideline that everyone in your team understands and follows and that is better suited for you case.
So, it is not for you anyway, as the problem it solves is already solved for you.
reply