Git提交消息:50/72格式

关于“summary”行(公式中的 50 ),请 Linux内核文档中有这个要说的

cd/path/to/repo
git shortlog grep-e'^'sed's/[:space:]\+\(.*\)$/\1/'awk'打印长度($0)
< /代码> 

或者基于文本的柱状图:

cd/path/to/repo
git shortlog grep-e'^'sed's/[:space:]\+\(.*\)$/\1/'awk'len s[长度($0)]+;end for(len in len s)print len,len s[长度]'sort-n
< /代码> 
:


For these reasons, the "summary" must be no more than 70-75
characters, and it must describe both what the patch changes, as well
as why the patch might be necessary.  It is challenging to be both
succinct and descriptive, but that is what a well-written summary
should do.


也就是说,看起来内核维护人员确实试图将事情保持在50左右。下面是内核Git日志中摘要行长度的柱状图:

(view full-sized)

有一小部分提交的摘要行比此绘图所能容纳的时间长(有些更长),而不会使有趣的部分看起来像一行。(这里可能有一些奇特的统计技术来合并这些数据,但是哦,好吧……:))。

如果要查看原始长度:

cd /path/to/repo
git shortlog  | grep -e '^      ' | sed 's/[[:space:]]\+\(.*\)$/\1/' | awk '{print length($0)}'


或基于文本的柱状图:

cd /path/to/repo
git shortlog  | grep -e '^      ' | sed 's/[[:space:]]\+\(.*\)$/\1/' | awk '{lens[length($0)]++;} END {for (len in lens) print len, lens[len] }' | sort -n

关于“思想领袖”: Linus 着重提倡对完整提交消息进行行包装:

我们使用72个字符的列进行换行,除了引用 具有特定行格式的材料

异常主要指的是“非散文”文本,也就是说,提交时不是由人键入的文本,例如编译器错误消息。

表示和数据的分离在这里驱动提交消息。

您的提交消息不应该硬包装在 任何 字符计数和换行符应用于分隔思想、段落等,作为数据的一部分,而不是表示。在这种情况下,“数据”是您试图传递的信息,“表示”是用户看到的信息。

我在顶部使用一个摘要行,并尽量保持简短,但我不局限于任意数字。如果Git真的提供了一种将摘要消息作为独立实体存储在消息中的方法,那就更好了,但是由于它不需要进行黑客攻击,所以我必须使用第一个换行符作为分隔符(幸运的是,许多工具都支持这种分离数据的方法)。

对于消息本身,换行表示数据中有意义的内容。单个换行符表示列表中的开始/中断,双换行符表示新的思想/想法。

This is a summary line, try to keep it short and end with a line break.
This is a thought, perhaps an explanation of what I have done in human readable format.  It may be complex and long consisting of several sentences that describe my work in essay format.  It is not up to me to decide now (at author time) how the user is going to consume this data.

Two line breaks separate these two thoughts.  The user may be reading this on a phone or a wide screen monitor.  Have you ever tried to read 72 character wrapped text on a device that only displays 60 characters across?  It is a truly painful experience.  Also, the opening sentence of this paragraph (assuming essay style format) should be an intro into the paragraph so if a tool chooses it may want to not auto-wrap and let you just see the start of each paragraph.  Again, it is up to the presentation tool not me (a random author at some point in history) to try to force my particular formatting down everyone else's throat.

Just as an example, here is a list of points:
* Point 1.
* Point 2.
* Point 3.

以下是在软包装文本的查看器中的外观。

这是一个摘要行,请尽量保持简短,并以换行符结尾。

这是一个想法,也许是对我以人类可读格式所做工作的解释。它可能很复杂,很长,由几个句子组成,用论文的形式描述我的作品。现在(在作者时)我不能决定用户将如何使用这些数据。

两行分隔符将这两个想法分开。用户可能在电话或宽屏显示器上阅读。你有没有尝试过在一个只有60个字符的设备上读取72个字符的包装文本?这真是一次痛苦的经历。此外,本段的开头句(假设文章风格格式)应该是对段落的介绍,因此,如果工具选择了它,可能不希望自动换行,让您只看到每个段落的开头。同样,这取决于演示工具,而不是我(历史上某个时刻的随机作者),试图迫使我的特定格式被其他人扼杀。

举个例子,这里是一个点列表:

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=bca476139d2ded86be146dae09b06e22548b67f3

git diff git log --pretty=format:'%T %cN %ce' git log