Fixed type lengths [suggestion] #94

New Issue

GiteaMirror · 2026-02-17T11:45:13-06:00

GiteaMirror commented

2026-02-17 11:45:13 -06:00

Originally created by @ArisKallergis on GitHub (Mar 16, 2020).

I'm not really sure if I should be posting a suggestion here, I'm sorry in advance if I shouldn't!

It was bothering me that types didn't have a fixed length, because I had to zip around to look at the actual commit messages. I propose for types to be exactly 3 characters, followed by a colon, followed by a whitespace. Furthermore, I find that I like types being all-caps, allowing for messages to begin with a lowercase letter. I believe that the scope, which is optional, should be added in the end of a message, either in parentheses, or in square brackets. Square brackets in my opinion are the better solution, because you might need a parentheses inside your message.

Types are:
FTR: feat
FIX: fix

PRF: perf
TST: test
RFC: refactor (I'm also thinking of RFR for this)

CHR: chore
BLD: build
CIN: ci

DOC: docs
STL: style

REV: revert

Here I include a sample from a repo I'm working on alongside a tutorial (I have my own EXA=example type here):

EDIT: I understand that my commits may be silly in this case of course!

In the screenshot you might also notice:

I'm trying to use verbs as a first word as much as I can
I tried to see if a merge commit would look ok with MRG:
I like using the -ing form of verbs in my custom EXA type :) for anyone interested

I think readability improves a lot with this, let's discuss if you'd like!

Originally created by @ArisKallergis on GitHub (Mar 16, 2020). I'm not really sure if I should be posting a suggestion here, I'm sorry in advance if I shouldn't! It was bothering me that types didn't have a fixed length, because I had to zip around to look at the actual commit messages. I propose for types to be exactly 3 characters, followed by a colon, followed by a whitespace. Furthermore, I find that I like types being all-caps, allowing for messages to begin with a lowercase letter. I believe that the scope, which is optional, should be added in the end of a message, either in parentheses, or in square brackets. Square brackets in my opinion are the better solution, because you might need a parentheses inside your message. Types are: FTR: feat FIX: fix PRF: perf TST: test RFC: refactor (I'm also thinking of RFR for this) CHR: chore BLD: build CIN: ci DOC: docs STL: style REV: revert Here I include a sample from a repo I'm working on alongside a tutorial (I have my own EXA=example type here): ![git guidelines example](https://user-images.githubusercontent.com/15965631/76760076-b0125180-6795-11ea-9786-9837b695c744.png) EDIT: I understand that my commits may be silly in this case of course! In the screenshot you might also notice: * I'm trying to use verbs as a first word as much as I can * I tried to see if a merge commit would look ok with MRG: * I like using the -ing form of verbs in my custom EXA type :) for anyone interested I think readability improves a lot with this, let's discuss if you'd like!

GiteaMirror commented

2026-02-17 11:45:14 -06:00

@damianopetrungaro commented on GitHub (Mar 18, 2020):

Hey @ArisKallergis thanks for opening an issue!

Personally I do not see a high value in introducing it as standard in the specs since the tooling around it should also have to implement it, and, it is not a hard tech solution to iterate over the bytes of a string until there's a :.

To clarity: since the specs allow you to define your own custom type it's totally fine to define custom one as you did,and if those fit your use case it is totally fine!

@damianopetrungaro commented on GitHub (Mar 18, 2020): Hey @ArisKallergis thanks for opening an issue! Personally I do not see a high value in introducing it as standard in the specs since the tooling around it should also have to implement it, and, it is not a hard tech solution to iterate over the bytes of a string until there's a `:`. To clarity: since the specs allow you to define your own custom type it's totally fine to define custom one as you did,and if those fit your use case it is totally fine!

GiteaMirror commented

2026-02-17 11:45:16 -06:00

@erdaltsksn commented on GitHub (Jul 21, 2020):

I have a little different approach about this. I use four-letters types, but there is exception for fix so it is easier to spot the fixes.

In my dotfiles, you can find an example commit template with a Vim plugin.

# fix : Fix an issue e.g. bug, code typo, accident, misstatement
# feat: < Add | Delete | Update > a feature
# test: < Add | Delete | Update > a test
# docs: < Add | Delete | Update > documentation
# chor: < Update | Downgrade > {pkg} , <Run> {task}
# redo: Refactor e.g. a change neither fixes a bug nor adds a feature
# tidy: Style e.g. indent, space, layout, text typo

@erdaltsksn commented on GitHub (Jul 21, 2020): I have a little different approach about this. I use four-letters types, but there is exception for `fix` so it is easier to spot the fixes. In my dotfiles, you can find an example [commit template](https://github.com/erdaltsksn/dotfiles/blob/master/git/.gittemplate) with a [Vim plugin](https://github.com/erdaltsksn/dotfiles/blob/master/vim/ftplugin/gitcommit.vim). ```sh # fix : Fix an issue e.g. bug, code typo, accident, misstatement # feat: < Add | Delete | Update > a feature # test: < Add | Delete | Update > a test # docs: < Add | Delete | Update > documentation # chor: < Update | Downgrade > {pkg} , <Run> {task} # redo: Refactor e.g. a change neither fixes a bug nor adds a feature # tidy: Style e.g. indent, space, layout, text typo ``` <img alt="Screen Shot for Conventional Commits" src="https://user-images.githubusercontent.com/22197800/88052947-b9586400-cb63-11ea-8d47-3c9c998ac1a4.png">

GiteaMirror referenced this issue

2026-02-17 11:57:22 -06:00

[PR #94] [MERGED] Add bumped #283

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/conventionalcommits.org#94