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
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!
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.
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.
@matt.mccormick Is the stuff in 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.
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.
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.
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?
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.
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.
The BUG/ENH/STYLE/... prefix requirement also helps me as I’m trying to follow the principle of “One Commit One Change”, 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.
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.
