问题标签 [commit-message]

git log 命令仅显示原始提交消息的一部分（不超过初始字符的特定限制）。但我想在控制台上显示整个长日志消息。怎么做？

如果我想更改过去的提交消息，我知道我可以做到

或者

但是有什么方法可以在不存储当前工作的情况下做到这一点（或者，--amend确保没有进行任何更改）？

这是针对尚未推送（或已推送到尚未合并的功能分支）的提交。

我知道这种事情经常被问到（例如这里），但是（也许正因为如此）我无法找到我正在寻找的东西。

我知道我可以通过与其提交消息匹配的模式来指定提交，而不是通过其哈希值，如下所示：

这向我显示了最近的提交，其消息以给定的模式开头，而我不必先搜索它的哈希。

我的问题是：

1. 此功能的名称是什么，它记录在哪里？（谷歌搜索:/是徒劳的）

2. 如何获得该提交的父级？这不起作用：

   /li>

我总是努力为除了更新子模块所在的提交之外什么都不做的提交编写好的 git 提交消息。我真正想写的是“只需阅读该死的子模块提交消息！”

也许一个更好的解决方案是，是否存在进入子模块并将自上次提交以来的所有消息以某种不错的方式连接并自动生成消息的东西？

我想使用 git 来跟踪一些高度易变、非关键的个人数据。我是唯一一个访问 repo 的人，而且我不太关心 git 的大部分功能——它主要是一种快速简单的（本地和远程）备份以及很少使用的恢复文件的选项。

目前，git 和 Sourcetree 要求我提供提交消息 - 在团队中工作或处理源代码时我对此没有任何问题，但在这个特定的用例中，它只是不需要并成为一个巨大的障碍。
它实际上让我选择了 SVN 而不是我讨厌的 git。

如果可能的话，对于特定的存储库，我希望能够禁用 Sourcetree 中提交消息的任何提示。提交应该尽可能少的点击。相比之下，它与直接在 repo 目录中使用 TortoiseSVN 一样快。

我正在编写 git hook 客户端commit-msg脚本，我需要将消息从

进入一些脚本以进一步检查我的模式。

我发现如何使用推送的提交来做到这一点

但是我没有找到如何在推送之前捕获我的消息。

在我的工作流程中，我想对文件进行一些更改并将它们保存在我的本地机器中。为此，我编写了一个pre-commit挂钩来在任何提交之前重置这些文件。

问题是默认消息：

有一个将被提交的文件列表。出于某种原因，它总是包含我已经在我的钩子中重置的文件的名称。这不是一个大问题，但如果可能的话，我希望它能够得到解决。我也不想自己写prepare-commit-msg钩子来写完整的消息。

我使用 mercurial，并使用长（ish）、多行的提交评论。

最近，我将我的项目放在 BitBucket.org 上，并注意到当我的提交评论附加到问题页面时（有关如何/何时发生这种情况的信息，请参阅这个 SO 问题），换行符被替换为空格，而双-newlines 保持双换行符。

我应该如何在提交消息中标记单个换行符，以便 BitBucket 确认它们？当我从命令行正常阅读评论时，我想以最不显眼的方式执行此操作。

There is some variation in the exact numbers but in general there are recommended lengths or maximum lengths for the first and subsequent line lengths of commit messages. The common one seems to be at most 72 characters for a message body with a further suggested limit of 50.

What are the reasons for these or other commonly encountered git commit line limits?

I have heard that the 72 character limit is related to the recommended email width limit of 76 as defined in RFC 2045:

(5) (Soft Line Breaks) The Quoted-Printable encoding REQUIRES that encoded lines be no more than 76 characters long.

There is something about a git function adding 4 characters to the commit message when generating an email, which would require the commit line to be shorter than the email limit. In turn I am aware that the email character limit is related to the ~80 character limit of old terminal systems.

If that does explain the 72 character limit, where does the 50 character one come from? Subject: is only 9 characters so adding that before 50 would only give 59. Maybe we then add the commonly used 7 character abbreviated commit hash ID and a space which gives us 67, still 5 spare characters to go.

是否可以进行 git commit 并且当编辑器打开时它已经填充了要编辑的消息？

例子：

git commit "some string"

将使用可以编辑的“一些字符串”打开文本编辑器。

用例：我有一个 git 别名来提交正在进行的工作（例如一天结束）git commit -m ":construction: WIP"（是的，我在一些提交消息上使用表情符号），但有时我想添加一些额外的细节。

对于git 文档，有：

• 标志但--message不打开编辑器
• 但--template=<file>它使用文件中的消息模板

有什么解决办法吗？