non-conventional commit provided as example #222

New Issue

GiteaMirror · 2026-02-17T11:54:37-06:00

GiteaMirror commented

2026-02-17 11:54:37 -06:00

Originally created by @FyiurAmron on GitHub (Mar 18, 2025).

The example commit message of

feat!: send an email to the customer when a product is shipped

is actually non-conventional. The conventional style of commit message is that the imperative verb describes the character of the change done by the commit (add, allow, fix, drop, change, prevent, correct, substitute etc.) - in this example, however, the verb is part of the functionality of the feature that was implemented. Arguably, the commit verb says what the commit will do - and here, the commit doesn't "send an email", it "allow[s] to send an email" or "add[s] sending an email" etc.

Also, the rules say commit should say "what" and "why". In this case, grammatically the "what" is not obvious, and has to be explicated from the context (are we adding this functionality? maybe there is a post-commit hook that actually sends the emails and the commit is needed for that?)

If a style allowing just the title of the functionality implemented is allowed, it's possible it will be even more ambiguous than here - what if you're working on a bug tracker software patch? (Jira or Redmine e.g.) You'd then have e.g. "feat: remove bug list view", and now tell me: does this remove the bug list view from the software, or adds the functionality to remove the bug list view for the software user? :)

Originally created by @FyiurAmron on GitHub (Mar 18, 2025). The example commit message of ``` feat!: send an email to the customer when a product is shipped ``` is actually non-conventional. The conventional style of commit message is that the imperative verb describes _the character of the change done by the commit_ (add, allow, fix, drop, change, prevent, correct, substitute etc.) - in this example, however, the verb is part of the functionality of the feature that was implemented. Arguably, the commit verb says what the commit _will do_ - and here, the commit _doesn't_ "send an email", it "allow[s] to send an email" or "add[s] sending an email" etc. Also, the rules say commit should say "what" and "why". In this case, grammatically the "what" is not obvious, and has to be explicated from the context (are we adding this functionality? maybe there is a post-commit hook that actually sends the emails and the commit is needed for that?) If a style allowing just the title of the functionality implemented is allowed, it's possible it will be even more ambiguous than here - what if you're working on a bug tracker software patch? (Jira or Redmine e.g.) You'd then have e.g. "feat: remove bug list view", and now tell me: does this remove the bug list view from the software, or adds the functionality to remove the bug list view for the software user? :)

GiteaMirror commented

2026-02-17 11:54:38 -06:00

@changeschung commented on GitHub (Apr 10, 2025):

Dude it feels like you guys wanted to come back with full recorses if I had it I already started earning the hexa was gone the 2nd day of my minting

@changeschung commented on GitHub (Apr 10, 2025): Dude it feels like you guys wanted to come back with full recorses if I had it I already started earning the hexa was gone the 2nd day of my minting

GiteaMirror commented

2026-02-17 11:54:39 -06:00

@changeschung commented on GitHub (Apr 10, 2025):

Try your best find it out if you can cause seriously I don't have it
I just took what I paste

@changeschung commented on GitHub (Apr 10, 2025): Try your best find it out if you can cause seriously I don't have it I just took what I paste

GiteaMirror commented

2026-02-17 11:54:40 -06:00

@bcoe commented on GitHub (May 2, 2025):

@FyiurAmron feel free to send a patch with an alternate example 👍

@bcoe commented on GitHub (May 2, 2025): @FyiurAmron feel free to send a patch with an alternate example 👍

GiteaMirror commented

2026-02-17 11:54:41 -06:00

@Michael21107 commented on GitHub (Dec 12, 2025):

Also, isn't the term ''breaking'' in the context of a public API, rather than a ''major feature''?

@Michael21107 commented on GitHub (Dec 12, 2025): Also, isn't the term ''breaking'' in the context of a public API, rather than a ''major feature''?

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/conventionalcommits.org#222