logo标签列表

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

gitrebase
8
我正在进行互动式变基。有没有一条命令可以显示最初在我启动变基时选择的提交列表？
2个回答
10
在交互式变基期间，git会在名为rebase-merge的子目录下更新位于.git目录中的文件（据我回忆，不同版本的git的确切路径有所改变；我现在正在查看git 2.0.x的行为）。
在该目录中有done和git-rebase-todo文件。它们并不完全是您要求的内容：它们是已完成部分和未完成部分，并非最初呈现给您的“pick”命令，也不一定是您选择的命令（如果您跳过了某些命令）。还有一个名为git-rebase-todo.backup的目录，其中包含您编辑后“todo”列表中的内容。如果您想要修补列表的完整列表或您在退出编辑器时选择的列表，我不确定，但如果是后者，则备份文件是正确的。
还有一个名为ORIG_HEAD的引用，它指向正在进行变基的（原始）分支的顶端，以及.git/rebase-merge/head-name，其中包含分支的名称（分支在重新基础完成之前不会移动）。您可以使用此功能以及其他一些文件来重建最初提供的“pick”列表。
3
注意，Git 2.3.0（2015年2月）将在交互式变基期间显示“待办事项”的数量。
请参见提交97f05f4由Onno Kortmann (onnokort)。

显示交互式变基中TODO项目的数量

在'rebase -i'期间，长时间的变基会导致一个错误的编辑不经意间丢失提交/项目。
此更改在列表后的注释中显示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，交互式变基将能够使用单个字母命令名称生成待办事项列表。

请参见 提交 1795993, 提交 d8ae6c8, 提交 0cce4a2, 提交 313a48e, 提交 d80fc29, 提交 8dccc7a (2017年12月05日)，以及 提交 7dcbb3c, 提交 f3b633d, 提交 946a9f2 (2017年12月03日)，作者为 Liam Beguin (Liambeguin)。
(本文已于 2017年12月27日 合并至 提交 0da2ba4，由 Junio C Hamano -- gitster -- 完成)

rebase -i: 学会缩写命令名称

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

git rebase 配置手册 将会阅读：

rebase.abbreviateCommands::

If set to true, git rebase will use abbreviated command names in the todo list resulting in something like this:

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

instead of:

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

Defaults to false.

请注意，Git 2.21（2019年第一季度）使得"git stripspace"在"-s"或"-c"模式下可以在Git存储库之外使用。

stripspace: allow -s/-c outside git repository

v2.11.0-rc3~3^2~1 (stripspace: respect repository config, 2016-11-21, Git v2.11.0-rc3) improved stripspace --strip-comments / --commentlines by teaching them to read repository config, but it went a little too far: when running stripspace outside any repository, the result is

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

That makes experimenting with the stripspace command unnecessarily fussy.
Fix it by discovering the git directory gently, as intended all along.

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

查看 提交 5a5445d, 提交 1da5874 (2020年1月28日) 由Alban Gruin(``)完成。
(由Junio C Hamano -- gitster --合并于提交 4dbeecb, 2020年2月14日)

rebase-interactive：如果使用rebase --edit-todo删除提交，则发出警告

由Alban Gruin签署

当设置为“warn”或“error”时，rebase.missingCommitsCheck会使rebase -i发出警告，以防止用户从todo列表中删除提交而导致错误。

不幸的是，rebase --edit-todo和rebase --continue没有考虑这一点。

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

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

这会更改备份todo列表的时间。

迄今为止，仅在初始编辑之前保存一次备份。

现在，如果原始todo列表没有错误或未删除提交，则还会进行备份。

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

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

在此更改之前，此文件仅由edit_todo_list()和rebase -p用于在初始编辑之前创建备份，并且仅由check_todo_list_from_file()使用，后者仅用于rebase -p检查其自己的初始编辑后是否删除提交。

如果编辑后的列表存在错误，则会创建一个名为dropped的文件以报告问题。

否则，它将被删除。

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

此外，如果文件存在，则sequencer_continue()将检查列表以查找删除的提交。

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

如果不存在dropped，则安全地忽略此检查，因为这意味着上次编辑时未发现任何错误，因此这里缺少的任何提交已经被选择。

在t3404中添加了五个测试。

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

  • 首先，在第一行上使用不正确的命令开始重演。
  • 然后，我们编辑todo列表，删除第一行和最后一行。
    这证明了--edit-todo注意到了删除的提交，但不会在命令不正确时注意到。
  • 然后，我们恢复原始todo列表，并将其编辑以删除最后一行。
    这证明了如果我们在初始编辑之后添加了提交，然后将其删除，--edit-todo将注意到它
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接