使用空提交消息重新发布git历史记录

Question

使用空提交消息重新发布git历史记录

我最近转换了一个svn存储库git svn.不幸的是,svn历史记录有许多空提交消息.当我在没有提交消息的最近提交之前重新定义和编辑/重新提交提交时,这是一个问题.

$ git rebase -i d01
[detached HEAD ff9839c] asdf
 2 files changed, 9 insertions(+), 0 deletions(-)
Aborting commit due to empty commit message.
Could not apply 054e890... 

$ git branch
* (no branch)
  master

$ git commit --amend
fatal: You are in the middle of a cherry-pick -- cannot amend.

Run Code Online (Sandbox Code Playgroud)

在这个例子中,我为第二次最近的提交做了一个提交消息,提交了一个空提交消息,并且在最近一次提交时使用空提交消息停止了.

我想一次编辑所有提交空消息的提交.有没有办法可以做到这一点？也许我可以使用空提交消息更改所有提交以使提交消息首先"空"？

Answer 1

man*_*lds 13

要使用某个模板替换空提交消息,您可以执行以下操作:

git filter-branch -f --msg-filter '
read msg
if [ -n "$msg" ] ; then
    echo "$msg"
else
    echo "The commit message was empty"
fi'

Run Code Online (Sandbox Code Playgroud)

如果您的提交消息包含换行符,那么这会完全消除它们.很难找到这个. (9认同)

Answer 2

luc*_*smo 10

正如我之前评论的那样,如果您碰巧在其中添加换行符,则会完全破坏评论.这是一个perl脚本,它可以做到这一点,而不是破坏性的:

#!/usr/bin/perl

my $data = "";    
while(<STDIN>) {
    $data .= $_;
}

if($data =~ /^\s*$/) { $data="[Empty message]\n"; }
print "$data";

Run Code Online (Sandbox Code Playgroud)

然后,只是 git filter-branch -f --msg-filter /path/to/perlfilter.pl

Answer 3

Von*_*onC 5

\n
由于提交消息为空而中止提交。
\n

\n

使用 Git 2.17（2018 年第 1 季度）不会出现此问题，因为“ git rebase”学会了采用新选项：“ --allow-empty-message”。（这是Git 2.19 中的默认值，见下文）

\n

请参阅Genki Sky (``)提交的 a6c612b（2018 年 2 月 4 日）。\n ^（由^{Junio C Hamano 合并 --}^--^在^{提交 2f6128d}^{中，2018 年 2 月 21 日）}
^gitster

\n

\n
rebase: 添加--allow-empty-message选项
\n

\n

\n
git-commit此选项允许使用空提交消息的提交重新设置基准，\n匹配和中的相同选项git-cherry-pick。
\n虽然空日志消息不受欢迎，但有时人们会在较旧的\n存储库中发现它们（例如从另一个版本控制系统翻译而来），或者有其他\n原因需要它们。\n该选项在和
中可用，因此很自然地可以让其他 git 工具与它们很好地配合。\n将此选项添加为默认值是“给用户一个修复的机会”，同时不会中断用户的工作流程。git-commitgit-cherry-pick
\n

\n

注意：“空消息中止”部分在 Git 2.33 中被删除（见下文末尾）

\n

Elan Ruusam\xc3\xa4e 在评论中确认：

\n

\n
奇迹般有效。应用上述提交构建。+
\n

\n

git rebase --root HEAD --allow-empty-message \n Successfully rebased and updated detached HEAD. \n\ngit checkout -B master \n

Run Code Online (Sandbox Code Playgroud)\n

\n

对于 Git 2.19（2018 年第 3 季度），--allow-empty-message是默认选项：

\n

参见提案B00BF1C，提交1634688，提交0661E49，提交4D34DFF，COMPL 983F464，COMMIT C840EE1A，COMPL 9929430（2018年6月27日）和提案D4E8062，commit commit 5dacd4a（25 nary 2018）（25 nary 2018）（Elijah newren by Elijah newren newren）。
\n ^{（由Junio C Hamano 合并 -- gitster--提交0ce5a69，2018 年 7 月 24 日）}

\n

\n
git-rebase: 设为--allow-empty-message默认值
\n

\n

\n
rebase目前，后端对空提交消息的行为有所不同，\n这很大程度上是它们所基于的不同底层命令的副作用。\n
基于\nam的变基应用带有空提交消息的提交，而不停止或要求用户指定额外的标志。
\n（有趣的是，am基于 - 的变基是默认的变基\n类型，并且没有人曾经请求过一个--no-allow-empty-message标志来\n更改此行为。）
\nm基于合并和基于交互的变基（最终基于git commit），当前将停止任何此类提交，并要求用户手动指定如何处理提交并继续。
\n
造成行为差异的一个可能的原因是，基于“”的变基的目的am仅仅是移植现有历史，而“交互式”变基的目的是在发布一系列之前对其进行润色。
\n因此，在后一种情况下，停止并要求确认可能存在的问题更为合适。
\n
然而，这个理由有两个问题：
\n
\n
\n
\n
基于合并的变基也是非交互式的，并且有多种类型的变基使用交互式机制，但不是显式交互式的（例如，当指定或--rebase-merges时没有--keep-empty指定）。\n这些变基也仅用于移植现有历史记录，因此也应默认为. --interactive
--allow-empty-message
\n
\n
\n
\n
\n
这个基本原理只是说用户在显式交互式变基的情况下更愿意停止，而不是因为这个特定原因而停止实际上是有意义的。
\n探索是否有意义，需要备份和分析底层命令...
\n
\n
\n
\n
如果git-commit默认情况下没有在空提交上出错，则意外\n创建具有空消息的提交将是很常见的情况\n（此检查已让我多次发现）。
\n此外，几乎所有此类空提交消息都将被视为意外错误（跨版本控制系统的大量文档以及解释提交消息的重要性的各种博客文章都证明了这一点）。
\n对常见错误进行简单检查非常有意义，并git-commit获得了--allow-empty-message特殊情况覆盖的标志。
\n这使得空消息的提交非常罕见。
\n
有两个用于 rebase（和cherry-pick）的带有空消息的提交来源：
\n
\n
(a) 在 git 中创建的提交，其中用户之前\n指定了--allow-empty-messagegit-commit，并且
\n
(b) 提交从其他版本控制系统导入到 git 中。
\n
\n
在情况（a）中，用户已经明确指定此提交有一些特殊之处，这使得他们不想指定提交消息；强迫他们在每次挑选或重新设定基础时重新指定似乎更可能令人恼火而不是有帮助。
\n
在情况 (b) 中，提交极不可能是由导入历史记录并进行变基或择优挑选的人编写的，因此该用户不太可能是为其编写提交消息的合适人选它。
\n在继续之前停止并期望用户修改提交似乎会适得其反。
\n
此外，请注意，虽然空提交消息是\n 需要git-commit处理的常见错误情况，但对于 rebase（或cherry-pick）来说，这是一种罕见的情况。
\n这种情况很少见的事实提出了一个问题：为什么在这种特定情况下而不是其他情况下值得检查和停止。
\n
例如，如果提交消息的第一行有 2000 列长，或者第一行后面缺少一个空白行，或者每行缩进五个空格，或者，为什么交互式变基不会自动停止\n还有其他无数问题吗？
\n
最后，请注意，如果进行交互式变基的用户确实拥有为任何此类提交添加消息的必要知识并且想要这样做，那么他们可以很简单地从\n\'pick\ 更改相应的行。 ' 来“改写”。
\n用户编辑的待办事项列表中的主题为空这一事实甚至应该作为通知他们的一种方式。
\n
据我所知，基于合并和基于交互的重定基在具有空提交消息的提交上停止的事实仅仅是基于git-commit.
\n正是因为这种情况很少见，所以很长一段时间没有通知。这种情况很少见，因此很难推理，因此当人们最终注意到这种行为时，他们认为它的存在是有充分理由的，只是添加了一个--allow-empty-message标志。
\n我认为，在任何这些情况下，即使是（明确的）交互式情况，停止此类消息都是不可取的。
\n

\n
\n
注意：git rebase当编辑结果给出空\n提交日志消息时，Git 2.19 中的“ ”等无法中止，这一问题已在 Git 2.20（2018 年第 4 季度）中得到纠正。
\n
\n
sequencer：修正--allow-empty-message行为，使其更聪明
\n
\n
\n
在提交 b00bf1c (" git-rebase: make --allow-empty-messagethe\ndefault", 2018-06-27, Git v2.19.0-rc0) 中，给出了几个参数用于移植空提交，而无需停止并要求用户对每个提交进行确认。
\n
这些论点是不完整的，因为逻辑清楚地假设正在考虑的唯一情况是移植具有空消息的提交（请参阅有关“具有空消息的提交有两个来源”的评论）。
\n
它没有讨论甚至没有考虑改写、压缩等，其中明确要求用户提供新的提交消息并提供空的消息。
\n（我的错，我当时完全应该考虑到这一点，但只是没有。）
\n
不过，正如 SZEDER 所描述的那样，重写和压缩有显着不同：
\n
\n
假设您启动交互式变基，选择提交到\nsquash，保存说明表，变基启动编辑器，\n然后您注意到您错误地选择了错误的提交到\nsquash。你会做什么，如何中止？
\n
在[该提交]之前，您可以清除提交消息，退出编辑器，然后 rebase 会说“由于空提交消息而中止提交。”，然后您可以运行 \' git rebase --abort\'，然后重新开始。
\n
但是[自从提交后，...]按原样保存提交消息将使变基继续并创建一堆不必要的对象，然后您必须使用引用日志返回到变基前的状态。
\n
\n
此外，他还指出：
\n
\n
提交消息模板中的说明（也针对 \' reword\' 和 \' squash\' 显示）仍然显示...
\n
# Please enter the commit message for your changes. Lines starting\n# with \'#\' will be ignored, and an empty message aborts the commit.\n
Run Code Online (Sandbox Code Playgroud)\n
\n
这些是合理的论据，在定序器操作期间编辑提交消息时，如果提交消息为空，则操作应停止并要求用户更正。
\n当使用空提交消息移植以前创建的提交时，提交 b00bf1c （上面引用的）中的参数仍然适用，因此定序器不应因这些而停止。
\n
此外，到目前为止，所有原理同样适用于cherry-pick 和rebase。
\n
因此，编写代码：
\n
\n
--allow-empty-message移植现有提交时默认为
\n
当要求用户编辑提交消息并提供空消息时，默认停止——对于 rebase 和cherry-pick 都是如此。
\n
\n
\n
\n
请注意，处理空提交时，请确保使用 Git 2.25+（2020 年第 2 季度）。
\n请参阅“如何填写空的提交消息？ ”（最后一节）。
\n
\n
使用 Git 2.26（2020 年第一季度），更新了文档
\n
请参阅提交 10cdb9f、提交 2ac0d62、提交 8295ed6、提交 76340c8、提交980b482、提交 c2417d3、提交6d04ce7、提交 52eb738 、提交 8af14f0 、提交be50c93、提交 befb89c、提交 9a70f3d、提交93122c9，提交 55d2b6d，提交 8a997ed，提交 7db00f0，提交e98c426，提交 d48e5e2（2020 年 2 月 15 日），并提交 a9ae8fd，提交 22a69fd（2020 年 1 月 16 日），作者：Elijah Newren ( )。\n ^（由^{Junio C Hamano 合并 --}^--^在^{提交 8c22bd9}^{中，2020 年 3 月 2 日）}newren
^gitster
\n
\n
git-rebase.txt: 更新 --allow-empty-message 的描述
\n
^{签署人：伊利亚·纽伦}
\n
\n
\n
提交b00bf1c9a8dd (" git-rebase: make --allow-empty-message the default", 2018-06-27, Git v2.19.0-rc0 -- merge returned in batch #4 ) 使 --allow-empty-message 成为默认值，因此将 --allow-empty-message 变为无操作，但没有更新文档以反映这一点。
\n
现在更新文档，并从正常的 -h 输出中隐藏该选项，因为它没有用。
\n
\n
git rebase 手册页现在包括：
\n
\n
--allow-empty-message：
\n
无操作。
\n使用空消息的提交重新定基通常会失败，此选项将覆盖该行为，从而允许使用空消息的提交重新定基。
\n现在使用空消息提交不会导致变基停止。
\n
\n
\n
在 Git 2.26（2020 年第一季度）中，“ ”已经学会了默认git rebase使用合并后端（即驱动“ ”的机器），同时允许rebase -i"--apply），同时允许“ 选项使用“ apply”后端（例如道德上等同于“ format-patch piped to am”）。
\ n（rebase.backend配置变量可以设置自定义。）
\n
它可以更好地管理空提交：
\n
请参阅提交 10cdb9f、提交 2ac0d62、提交 8295ed6、提交 76340c8、提交980b482、提交 c2417d3、提交6d04ce7、提交 52eb738 、提交 8af14f0 、提交be50c93、提交 befb89c、提交 9a70f3d、提交93122c9，提交 55d2b6d，提交 8a997ed，提交 7db00f0，提交e98c426，提交 d48e5e2（2020 年 2 月 15 日），并提交 a9ae8fd，提交 22a69fd（2020 年 1 月 16 日），作者：Elijah Newren ( )。\n ^（由^{Junio C Hamano 合并 --}^--^在^{提交 8c22bd9}^{中，2020 年 3 月 2 日）}newren
^gitster
\n
\n
rebase (interactive-backend)：修复空提交的处理
\n
^{签署人：伊利亚·纽伦}
\n
\n
\n
正如之前的提交和提交 b00bf1c9a8dd (" git-rebase: make --allow-empty-message the default", 2018-06-27, Git v2.19.0-rc0 -- merge在批处理 #4中列出的那样 ) 中所建立的，rebase 的行为在各种边缘或角落情况下使用不同的后端通常比设计更偶然。
\n
\n
\n
此提交解决了另一个这样的极端情况：“变空”的提交。
\n
细心的读者可能会注意到，有两种类型的提交会因变基而变空：
\n
\n
[clean cherry-pick]提交是上游提交的干净挑选，由确定git log --cherry-mark ...。
\n重新应用这些提交将导致一组空的更改和重复的提交消息；即这些是上游“已经应用”的提交。
\n
[become empty]开始时不为空的提交，不是上游提交的干净挑选，但在重新设置基础后仍然会变为空。
\n例如，当提交的更改

归档时间：	13 年，10 月前
查看次数：	5281 次
最近记录：	7 年，1 月前

使用空提交消息重新发布git历史记录

`rebase`: 添加`--allow-empty-message`选项

`git-rebase`: 设为`--allow-empty-message`默认值

`sequencer`：修正`--allow-empty-message`行为，使其更聪明

`git-rebase.txt`: 更新 --allow-empty-message 的描述

`--allow-empty-message`：

`rebase (interactive-backend)`：修复空提交的处理

使用空提交消息重新发布git历史记录

rebase: 添加--allow-empty-message选项

git-rebase: 设为--allow-empty-message默认值

sequencer：修正--allow-empty-message行为，使其更聪明

git-rebase.txt: 更新 --allow-empty-message 的描述

--allow-empty-message：

rebase (interactive-backend)：修复空提交的处理

`rebase`: 添加`--allow-empty-message`选项

`git-rebase`: 设为`--allow-empty-message`默认值

`sequencer`：修正`--allow-empty-message`行为，使其更聪明

`git-rebase.txt`: 更新 --allow-empty-message 的描述

`--allow-empty-message`：

`rebase (interactive-backend)`：修复空提交的处理