I totally agree with the sentiment behind this, so much so that I also made my own standard a while ago, https://commits-with-character.org/ an incredibly light addition to the Git Book guidelines, and also gives more priority to scope. It’s been working really well for me in my small projects.
Conventional Commits encourages focus on the wrong things
181–190 of 294 posts
Re: Conventional Commits encourages focus on the wrong things
#182Old man yells at clouds
Re: Conventional Commits encourages focus on the wrong things
#183Broken promise 1 (Automatically generating CHANGELOGs) is spot on, especially in a monorepo with multiple released artifacts. A single commit could be a breaking change in one package and refactor in another. But the changelog tools see one commit and include it in both changelogs.
Another issue is that once the commit lands on trunk, you can’t revise the entry without editing history. You have to remember to fix it after the changelog is generated.
Changesets (https://github.com/changesets/changesets) is a much better approach. We adopted it in Endo (https://github.com/endojs/endo/tree/master/.changeset) and it’s been a clear improvement.
Re: Conventional Commits encourages focus on the wrong things
#184I agree with the sentiments -- knowing the scope of a change is more essential, in most cases, than knowing whether the change was a "fix" or a "feature" -- but much of the scope in a project can be gleaned from the files which were touched. So the use case of, "i need to quickly at a glance determine what commits touched what parts of the project" can be answered with some variation on
git log --pretty=format:"%n%h %s" --name-onlyRe: Conventional Commits encourages focus on the wrong things
#185Re: Conventional Commits encourages focus on the wrong things
#186Old man yells at clouds
[deleted]
Re: Conventional Commits encourages focus on the wrong things
#187Earlier 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…
Respectfully, I disagree. A good commit message to me is something like: [PRJ-123] Changed blah to foo Blah didn't handle the wangle flange properly in some cases, foo is a better fit for customer requirements. The "why" that justifies the change, is already contained in the JIRA ticket PRJ-123 and explains exactly what the customer requirement was that necessitated the change. It will almost certainly contain a lot…
Hah, maybe its the difference between why as in "this addresses problem X" and why as in "because those jerks in pre-sales sold another imaginary product"
I think the commit ought to describe the purpose of the change in terms of its result for the software's intended use. Feel free to hide the business/political drama behind a ticket number.
This gets down to a more fundamental tension. Are commit messages to communicate between developers? To communicate from developer to consumer? Or some kind of project manager golem? In practice, it is usually some constantly wandering attempt to be a blend of these.
Re: Conventional Commits encourages focus on the wrong things
#188Inverting the order actually addresses my primary annoyance: what is a feature?!
> refactor(core): Update webmcp support to use document.modelContext
As the author points out, the line between a fix, an improvement, and general clean-up is blurry and dividing each semantic change into its own commit (and possibly squashed later anyway) is just creating work for no one's benefit.
I think Conventional Commits are just an artifact of trying to automate SemVer rather than solving any of the other problems directly. I don't think changelogs should be automated anyway - I can `git log` that if I want a list. A changelog is an opportunity to communicate to a wider audience what is actually going on under the hood.
Re: Conventional Commits encourages focus on the wrong things
#189Earlier quoted context omitted.
Respectfully, I disagree. A good commit message to me is something like: [PRJ-123] Changed blah to foo Blah didn't handle the wangle flange properly in some cases, foo is a better fit for customer requirements. The "why" that justifies the change, is already contained in the JIRA ticket PRJ-123 and explains exactly what the customer requirement was that necessitated the change. It will almost certainly contain a lot…
Hah, maybe its the difference between why as in "this addresses problem X" and why as in "because those jerks in pre-sales sold another imaginary product" I think the commit ought to describe the purpose of the change in terms of its result for the software's intended use. Feel free to hide the business/political drama behind a ticket number. This gets down to a more fundamental tension. Are commit messages to commun…
The last part is easy to answer. Commit messages are solely for developers IMHO. The communication between developer and customer / product manager should be via the ticket system.
That said, knowing the commit ID something is fixed in, so that the PM can track what build it emerges in is useful.
Re: Conventional Commits encourages focus on the wrong things
#190I prefer how golang/go commits are organized. Simple but working setup.