Git：在交互式变基期间显示提交列表

Question

我正处于交互式 rebase 的中间。是否有一个命令可以显示我开始 rebase 时最初选择的提交列表？

Answer 1

在交互式 rebase 期间，git 更新子目录 rebase-merge 下 .git 目录中的文件（我记得，不同版本的 git 中的确切路径已更改；我正在查看 git 2.0.x现在的行为）。

该目录中有文件done 和git-rebase-todo。这些不是您所要求的：它们是已完成的部分和尚未完成的部分，而不是最初呈现给您的“选择”命令，也不一定是您已经使用的命令（如果您跳过一些）。还有一个git-rebase-todo.backup，它包含编辑后“待办事项”列表中的内容。我不确定您是想要完整的转速列表还是退出编辑器时选择的列表，但如果是后者，备份文件是正确的。

还有一个名为 ORIG_HEAD 的引用指向正在变基的（原始）分支的尖端，.git/rebase-merge/head-name 包含分支的名称（并且在变基之前不会移动分支完全的）。您可以使用此文件以及其他一些文件来重建最初提供的“选择”列表。

Answer 2

请注意，Git 2.3.0（2015 年 2 月）将在交互式变基期间显示“待办事项”的数量。

见commit 97f05f4Onno Kortmann (onnokort)

显示交互式 rebase 的 TODO 项目数

在“rebase -i”期间，长变基会话中的一次错误编辑可能会无意中删除提交/项目。
此更改显示了 cmets 中 TODO 项的总数 列表。
执行变基编辑后，可以比较总项目数以确保编辑中没有丢失任何更改。

git-rebase--interactive.sh 现在包括（使用git stripspace）：

todocount=$(git stripspace --strip-comments <"$todo" | wc -l)
cat >>"$todo" <<EOF
$comment_char Rebase $shortrevisions onto $shortonto ($todocount TODO item(s))

---

请注意，使用 Git 2.16（2018 年第一季度），交互式变基将能够生成带有单字母命令名称的待办事项列表（如果设置了配置变量 rebase.abbreviateCommands）。

请参阅commit 1795993、commit d8ae6c8、commit 0cce4a2、commit 313a48e、commit d80fc29、commit 8dccc7a（2017 年 12 月 5 日）和commit 7dcbb3c、commit 7dcbb3c、commit 946a9f2（12 月 3 日） by Liam Beguin (Liambeguin).
^{（由 Junio C Hamano -- gitster -- 在 commit 0da2ba4 中合并，2017 年 12 月 27 日）}

rebase -i: 学会缩写命令名

git rebase -i 已经知道如何解释单字母命令 名字。
教它生成具有这些相同缩写的待办事项列表 名字。

git rebase config man page 将显示为：

rebase.abbreviateCommands::

如果设置为 true，git rebase 将在待办事项列表中使用缩写命令名称，结果如下：

-------------------------------------------
    p deadbee The oneline of the commit
    p fa1afe1 The oneline of the next commit
    ...
-------------------------------------------

代替：

-------------------------------------------
    pick deadbee The oneline of the commit
    pick fa1afe1 The oneline of the next commit
    ...
-------------------------------------------

默认为false。

---

请注意，Git 2.21（2019 年第一季度）使“git stripspace”在 git 存储库外部可用，即使在 "-s" or "-c" mode 中也是如此。

stripspace: 允许 -s/-c 在 git 仓库

v2.11.0-rc3~3^2~1（stripspace：尊重存储库配置，2016-11-21，Git v2.11.0-rc3）通过教他们阅读存储库配置改进了stripspace --strip-comments/--commentlines，但它也有点过far：在任何存储库之外运行stripspace 时，结果为

$ git stripspace --strip-comments <test-input
 fatal: not a git repository (or any parent up to mount point /tmp)

这使得尝试使用 stripspace 命令变得不必要地繁琐。
按照一直以来的预期，通过轻轻地发现git 目录来修复它。

---

使用 Git 2.26（2020 年第一季度），允许 rebase.missingCommitsCheck 配置在“rebase --edit-todo”和“rebase --continue”重新启动程序时启动。

见commit 5a5445d、commit 1da5874（2020 年 1 月 28 日）Alban Gruin (``)。
^{（由 Junio C Hamano -- gitster -- 合并到 commit 4dbeecb，2020 年 2 月 14 日）}

rebase-interactive：如果提交被丢弃，则发出警告rebase --edit-todo

^{签字人：Alban Gruin}

当设置为“警告”或“错误”时，rebase.missingCommitsCheck 将在用户从todo 列表中删除提交时发出rebase -i 警告以防止错误。

很遗憾，rebase --edit-todo 和 rebase --continue 没有考虑到这一点。

这增加了rebase --edit-todo 和 `rebase --continue' 检查提交是否被用户删除的能力。

由于edit_todo_list() 和complete_action() 都解析todo 列表并检查丢弃的提交，因此删除了后者中这样做的代码以减少重复。 edit_todo_list_advice 已从 sequencer.c 中删除，因为它不再在那里使用。

当备份todo 列表时，这会发生变化。

到目前为止，它只保存了一次，在初始编辑之前。

现在，如果原始待办事项列表没有错误或没有丢弃的提交，也会进行此操作。

因此，备份应该没有错误。

没有这个，sequencer_continue() (rebase --continue) 只能将当前的todo 列表与原始的、未经编辑的列表进行比较。

在此更改之前，此文件仅由 edit_todo_list() 和 rebase -p 用于在初始编辑之前创建备份，而 check_todo_list_from_file() 仅由 rebase -p 用于在其自己的初始编辑后检查丢弃的提交.

如果编辑后的列表有错误，则会创建一个文件 dropped 来报告问题。

否则将被删除。

通常，编辑后的列表会与编辑前的列表进行比较，但如果此文件存在，则会与备份进行比较。

此外，如果文件存在，sequencer_continue() 会检查列表中的已删除提交。

如果每次都执行检查，则在解决冲突后恢复 rebase 时会失败，因为备份将包含已​​选择的提交，但它们不会在新列表中。

如果dropped 不存在，则忽略此检查是安全的，因为这意味着在上一版中没有发现任何错误，因此这里所有丢失的提交都已经被选中。

t3404 增加了五项测试。

rebase.missingCommitsCheck = warn' andrebase.missingCommitsCheck = error' 的测试具有类似的结构。

• 首先，我们在第一行使用不正确的命令启动 rebase。

• 然后，我们编辑todo 列表，删除第一行和最后一行。
  这表明--edit-todo 注意到放弃的提交，但在命令不正确时不会。

• 然后，我们恢复原来的todo列表，并对其进行编辑以删除最后一行。
  这表明如果我们在初始编辑后添加提交，然后将其删除，--edit-todo 会注意到它已被删除。

• 然后，实际的变基发生。

• 在第三个测试中，还检查了--continue 如果提交被丢弃，将拒绝恢复 rebase。

• 第四个测试检查在解决冲突后恢复 rebase 时没有引发错误，

• 第五个检查在暂停 rebase 后编辑 todo 列表时没有引发错误。