# New convention for commit messages on GitHub?
**URL:** https://discourse.itk.org/t/new-convention-for-commit-messages-on-github/1427
**Category:** Community
**Created:** [November 19, 2018, 4:56pm UTC](https://discourse.itk.org/t/new-convention-for-commit-messages-on-github/1427 "2018-11-19T16:56:53Z")
**Posts on this page:** 20
**Page:** 1
### Author:  [@Niels\_Dekker](https://discourse.itk.org/u/Niels_Dekker)
#### Post date: [November 19, 2018, 4:56pm UTC](https://discourse.itk.org/t/new-convention-for-commit-messages-on-github/1427/1 "2018-11-19T16:56:53Z")
According to ITK’s commit-msg hook, _“The first line may be at most 78 characters”_. Unfortunately, when the first line of a commit message has more than 72 characters, it gets chopped off, replacing the chopped off characters by “…”, as it appears at [https://github.com/InsightSoftwareConsortium/ITK/commits](https://github.com/InsightSoftwareConsortium/ITK/commits) 🙄
Should the commit-msg hook be modified to only allow up to _72_ characters? Or could the GitHub installation of ITK be adjusted to show up to 78 characters, without chopping or “…”?
I’m in favor of allowing clear and explicit commit messages, so if possible, adjusting the GitHub installation would be my preference! 😀
---
### Author:  [@dzenanz](https://discourse.itk.org/u/dzenanz)
#### Post date: [November 19, 2018, 5:11pm UTC](https://discourse.itk.org/t/new-convention-for-commit-messages-on-github/1427/2 "2018-11-19T17:11:40Z")
I don’t think GitHub instance can be adjusted - I just took a look at settings and could not find anything. I guess somebody will have to update the commit message hook.
---
### Author:  [@Niels\_Dekker](https://discourse.itk.org/u/Niels_Dekker)
#### Post date: [November 19, 2018, 5:31pm UTC](https://discourse.itk.org/t/new-convention-for-commit-messages-on-github/1427/3 "2018-11-19T17:31:23Z")
Thanks, @dzenan You see, the first line of the commit message of my proposed patch [https://github.com/InsightSoftwareConsortium/ITK/pull/204/commits/9e94b2b5cdd0563f40b621d63c84186dd52f6d23](https://github.com/InsightSoftwareConsortium/ITK/pull/204/commits/9e94b2b5cdd0563f40b621d63c84186dd52f6d23) has 72 characters, which appears “GitHub friendly”:
`BUG: ShapedImageNeighborhoodRange should not try to avoid rvalue offsets`
But it chopped off this one of yours, which has just one more character:
`Merge remote-tracking branch 'remotes/upstream/release-4.13' into release`
at [https://github.com/InsightSoftwareConsortium/ITK/commit/d178c9f5cc391650adc1d083311d18fc083d7bc7](https://github.com/InsightSoftwareConsortium/ITK/commit/d178c9f5cc391650adc1d083311d18fc083d7bc7)
---
### Author:  [@dzenanz](https://discourse.itk.org/u/dzenanz)
#### Post date: [November 19, 2018, 5:31pm UTC](https://discourse.itk.org/t/new-convention-for-commit-messages-on-github/1427/4 "2018-11-19T17:31:52Z")
I just looked at [https://github.com/InsightSoftwareConsortium/ITK/tree/master/Utilities/Hooks](https://github.com/InsightSoftwareConsortium/ITK/tree/master/Utilities/Hooks) and could not see where line limit of 78 characters is checked. I did [notice](https://github.com/InsightSoftwareConsortium/ITK/pull/205) an unrelated out of date message.
---
### Author:  [@matt.mccormick](https://discourse.itk.org/u/matt.mccormick)
#### Post date: [November 19, 2018, 6:39pm UTC](https://discourse.itk.org/t/new-convention-for-commit-messages-on-github/1427/5 "2018-11-19T18:39:18Z")
The [client side Git hook is in the `commit-msg` file](https://github.com/InsightSoftwareConsortium/ITK/blob/hooks/commit-msg) on the `hooks` branch of the `ITK` repository.
There is also a check in the `ghostflow` status check – adding more detailed information on what this does and a reference to its configuration is a work in progress.
Ideally, we could extend the GitHub supported line length, but I do think that is possible. There is a tradeoff between enough characters to make a meaningful commit summary and conciseness for tools that use that summary. From my perspective, it is already difficult enough to hit the 78 character limit, and 72 is too short.
CC: @brad.king
---
### Author:  [@dzenanz](https://discourse.itk.org/u/dzenanz)
#### Post date: [November 19, 2018, 7:44pm UTC](https://discourse.itk.org/t/new-convention-for-commit-messages-on-github/1427/6 "2018-11-19T19:44:33Z")
@matt.mccormick Is the stuff in [Utilities/Hooks](https://github.com/InsightSoftwareConsortium/ITK/tree/master/Utilities/Hooks) used any more? If not, we could remove it. And if we don’t remove it we should update it by copying stuff in the [hooks branch](https://github.com/InsightSoftwareConsortium/ITK/tree/hooks).
---
### Author:  [@matt.mccormick](https://discourse.itk.org/u/matt.mccormick)
#### Post date: [November 19, 2018, 7:53pm UTC](https://discourse.itk.org/t/new-convention-for-commit-messages-on-github/1427/7 "2018-11-19T19:53:26Z")
> [@dzenanz](#):
>
> @matt.mccormick Is the stuff in [Utilities/Hooks](https://github.com/InsightSoftwareConsortium/ITK/tree/master/Utilities/Hooks) used any more? If not, we could remove it. And if we don’t remove it we should update it by copying stuff in the [hooks branch](https://github.com/InsightSoftwareConsortium/ITK/tree/hooks).
Both are used. The hooks branch contains scripts shared across many projects, and it should not be copied / forked because that would be difficult to maintain. The `Utilities/Hooks` hooks contains additional ITK-specific hooks that are also executed after the vanilla hooks.
---
### Author:  [@brad.king](https://discourse.itk.org/u/brad.king)
#### Post date: [November 19, 2018, 8:11pm UTC](https://discourse.itk.org/t/new-convention-for-commit-messages-on-github/1427/8 "2018-11-19T20:11:02Z")
The ghostflow check can be updated from 78 to 72 with a one-line change to the deployment’s configuration. @matt.mccormick it sounds like you don’t want to make it shorter though.
---
### Author:  [@Niels\_Dekker](https://discourse.itk.org/u/Niels_Dekker)
#### Post date: [November 19, 2018, 9:35pm UTC](https://discourse.itk.org/t/new-convention-for-commit-messages-on-github/1427/9 "2018-11-19T21:35:16Z")
> [@matt.mccormick](#):
>
> it is already difficult enough to hit the 78 character limit, and 72 is too short.
Honestly I also find it hard to always keep the first line \<= 72 chars. So maybe it would be too harsh to reject any commit message that has first line \> 72.
Maybe instead, what about just having a gentle suggestion for contributors, just to _try_ to keep that first line \<= 72 chars…? Maybe as a “loose” (not a strict) style guideline?
---
### Author:  [@brad.king](https://discourse.itk.org/u/brad.king)
#### Post date: [November 19, 2018, 9:38pm UTC](https://discourse.itk.org/t/new-convention-for-commit-messages-on-github/1427/10 "2018-11-19T21:38:48Z")
> what about just having a gentle suggestion for contributors
Does GitHub’s “…” truncation already provide that?
---
### Author:  [@Niels\_Dekker](https://discourse.itk.org/u/Niels_Dekker)
#### Post date: [November 19, 2018, 9:49pm UTC](https://discourse.itk.org/t/new-convention-for-commit-messages-on-github/1427/11 "2018-11-19T21:49:37Z")
> [@brad.king](#):
>
> Does GitHub’s “…” truncation already provide that?
Once GitHub has truncated the line, it’s too late already! It took me a while to figure out that it always happens when the line \> 72 chars, and never when \<= 72 chars. So I think it could be helpful that contributors get informed that exceeding 72 chars will lead to truncation at GitHub.
---
### Author:  [@matt.mccormick](https://discourse.itk.org/u/matt.mccormick)
#### Post date: [November 19, 2018, 9:53pm UTC](https://discourse.itk.org/t/new-convention-for-commit-messages-on-github/1427/12 "2018-11-19T21:53:11Z")
How about suggesting that commit message subjects should be less than 72 characters, if possible, in the [`prepare-commit-msg` hook](https://github.com/InsightSoftwareConsortium/ITK/blob/master/Utilities/Hooks/prepare-commit-msg)?
---
### Author:  [@brad.king](https://discourse.itk.org/u/brad.king)
#### Post date: [November 20, 2018, 1:47pm UTC](https://discourse.itk.org/t/new-convention-for-commit-messages-on-github/1427/13 "2018-11-20T13:47:43Z")
Suggesting it in `prepare-commit-msg` sounds good.
How useful have the `BUG:`, `ENH:`, etc. prefixes been in practice? They take up 5-6 characters making the limit harder to meet.
---
### Author:  [@matt.mccormick](https://discourse.itk.org/u/matt.mccormick)
#### Post date: [November 20, 2018, 2:15pm UTC](https://discourse.itk.org/t/new-convention-for-commit-messages-on-github/1427/14 "2018-11-20T14:15:40Z")
> [@brad.king](#):
>
> How useful have the `BUG:` , `ENH:` , etc. prefixes been in practice? They take up 5-6 characters making the limit harder to meet.
These are very useful for scanning the commit history.
---
### Author:  [@brad.king](https://discourse.itk.org/u/brad.king)
#### Post date: [November 20, 2018, 2:22pm UTC](https://discourse.itk.org/t/new-convention-for-commit-messages-on-github/1427/15 "2018-11-20T14:22:10Z")
> [@matt.mccormick](#):
>
> These are very useful for scanning the commit history.
What workflow/use-case involves scanning history in a way that such prefixes are useful?
---
### Author:  [@matt.mccormick](https://discourse.itk.org/u/matt.mccormick)
#### Post date: [November 20, 2018, 2:45pm UTC](https://discourse.itk.org/t/new-convention-for-commit-messages-on-github/1427/16 "2018-11-20T14:45:27Z")
> [@brad.king](#):
>
> > These are very useful for scanning the commit history.
>
> What workflow/use-case involves scanning history in a way that such prefixes are useful?
Any time you are browsing the history and looking for changes of a given type, or want to understand what is the nature of changes without needing to fulling read and process the commit message. I use it all the time.
---
### Author:  [@Niels\_Dekker](https://discourse.itk.org/u/Niels_Dekker)
#### Post date: [November 20, 2018, 7:40pm UTC](https://discourse.itk.org/t/new-convention-for-commit-messages-on-github/1427/17 "2018-11-20T19:40:25Z")
The `BUG`/`ENH`/`STYLE/...` prefix requirement also helps me as I’m trying to follow the principle of [“One Commit One Change”](https://medium.com/@fagnerbrack/one-commit-one-change-3d10b10cebbf), when possible. Specifically I think it’s a good practice to have separate commits for a bug fix, an enhancement and a style improvement. The required prefix supports this practice, in my opinion.
My 2 cents, Niels
---
### Author:  [@matt.mccormick](https://discourse.itk.org/u/matt.mccormick)
#### Post date: [November 20, 2018, 8:03pm UTC](https://discourse.itk.org/t/new-convention-for-commit-messages-on-github/1427/18 "2018-11-20T20:03:58Z")
A pull request to suggest a summary of 72 characters or less is here:
>
---
### Author:  [@dzenanz](https://discourse.itk.org/u/dzenanz)
#### Post date: [November 20, 2018, 8:09pm UTC](https://discourse.itk.org/t/new-convention-for-commit-messages-on-github/1427/19 "2018-11-20T20:09:16Z")
If GitHub cannot be adjusted to not truncate commit summaries of lengths 73 to 78 characters, I am in favor of imposing the limit of 72. I am afraid that just suggesting 72 will not accomplish much.
---
### Author:  [@matt.mccormick](https://discourse.itk.org/u/matt.mccormick)
#### Post date: [November 20, 2018, 9:39pm UTC](https://discourse.itk.org/t/new-convention-for-commit-messages-on-github/1427/20 "2018-11-20T21:39:26Z")
If the summary is longer that 72 characters, the remainder of the message shows up as _…_ in the commit summary, which is not a show-stopper.
[Next page](https://discourse.itk.org/t/new-convention-for-commit-messages-on-github/1427.md?page=2)