You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
My issue is that this "Conventional commits" style isn't really conventional; it's actually pretty opinionated.
Since the Conventional Commits spec allows arbitrary xxx[yyy]:, it seems like the only thing that structuring a message in this way does is enable easier machine readability1 (and not work directly to Documentation Driven Development in the sense of legible and accurate documentation around development). It's just a punctuation spec, not a content spec, and despite it's name is not very generalized.
Describe the solution you'd like
Something as generic as possible, while still being able to describe something that's actually useful.
In my opinion there are more useful resources we can draw from for outlining a rubric for a "good" commit message, for example
I spent 10 minutes looking through "top starred" repos on Github for examples (for lack of a better "canon of the conventional").
A list of example repos that don't follow this pattern:
https://github.com/golang/go/commits/master - Note here that cmd/api: fix no go files package panic is used, where cmd/api: is the package containing the changes. In fact, this kind-of-almost fits the Conventional Commit style, except that "scope" (optional) is used in place of "type" (mandatory).
While you make some very good points, for me, its a hard sell to change to anything else for 1 reason: tooling.
Conventional commit style ATM has the best tooling from what I could see. Basically we need out of the box validation of messages in CI, and ideally changelog generators, etc etc.
Is your feature request related to a problem? Please describe.
Currently conventional commits refers and adheres to http://conventionalcommits.org/.
My issue is that this "Conventional commits" style isn't really conventional; it's actually pretty opinionated.
Since the Conventional Commits spec allows arbitrary
xxx[yyy]:
, it seems like the only thing that structuring a message in this way does is enable easier machine readability1 (and not work directly to Documentation Driven Development in the sense of legible and accurate documentation around development). It's just a punctuation spec, not a content spec, and despite it's name is not very generalized.Describe the solution you'd like
Something as generic as possible, while still being able to describe something that's actually useful.
In my opinion there are more useful resources we can draw from for outlining a rubric for a "good" commit message, for example
Describe alternatives you've considered
scope: message
; useful for big repos, not so much for small onesproblem: xxx / solution: yyy
structureResources
I spent 10 minutes looking through "top starred" repos on Github for examples (for lack of a better "canon of the conventional").
A list of example repos that don't follow this pattern:
cmd/api: fix no go files package panic
is used, wherecmd/api:
is the package containing the changes. In fact, this kind-of-almost fits the Conventional Commit style, except that "scope" (optional) is used in place of "type" (mandatory).suggestion
ed commits or when using their browser editor, like:Repos I found that do use it:
The text was updated successfully, but these errors were encountered: