3 ms·
That's one interpretation. Another is you're looking at git log and it's all historical. The best practice bit seems to boil down to "because Linus said so."
by nirvdrum 12y ago
That's one interpretation. Another is you're looking at git log and it's all historical. The best practice bit seems to boil down to "because Linus said so." The rest of the git commit best practices seem to fall into a similar boat.
I'm of the mindset a team can be mature enough to pick what works best for them. If the idea of a commit message is to convey useful info, imposing hard rules like 72 chars or tense seems a bit draconian. The worst change GitHub has made IMHO is truncating messages (particularly because the truncated message often ends up longer).
- jamesn 12y agoThe reason for the 72 character limit is so that shortlog messages on an 80 character terminal which are indented by one tab aren't truncated, as I understand it.
- nirvdrum 12y agoI get that. And in certain scenarios where even pagers aren't available require that. But I'd expect that team to handle it, not for it to be a general purpose rule. In contrast, a Nokia postage stamp feature phone can display a message more than twice as long (SMS - 160 chars). Limiting to 72 chars across the board seems to be more dogmatic than anything else from my POV.
- giovannibajo1 12y agoI think that the boat already sailed, there are many tools that assume that shortlogs are 72, and can be displayed on a single line, and format accordingly, including GitHub for instance. Besides, whether it's 72 or 100, it makes sense to force people to have a concise summary.
- nirvdrum 12y agoGitHub's approach is one reason I've started using BitBucket more. GitHub didn't always used to do this. I've assumed they started so they could have fixed height commit displays in their commit list. It seems weird to force this on people otherwise.