Git Bash卡在diff / log上，自发地重复同样的命令

我在Windows 7 / XP上遇到了Git Bash的一个奇怪的问题。 它曾经工作得很好，但最近我发现，在我执行git diff或git log ，Git Bash变得不可用：在diff / log之后，即使在我返回到命令提示符后，Bash仍然突然显然自发地重复命令，自由的，而我正在键入一个后续的命令。

有没有其他人有这个问题？ 任何意见将不胜感激，因为这是真正限制Git Bash的有用性在这一刻。

Answer 1

你必须使用q来退出git的寻呼机。 使用Ctrl-C只会导致在Windows上的问题。

Ctrl-C不应该​​退出寻呼机（而不是在Linux系统上）。 当你在Windows上按Ctrl-C（我猜想是msysgit）时，你会以某种方式“从外部”（即从cmd.exe）杀死进程。 我不知道这种情况发生的确切原因。

正如我以前遇到类似的问题：尝试按顺序重复q和Ctrl-C，如果幸运的话，你会得到一个工作提示;）[我没有更好的解决scheme – 但它为我工作…]

Answer 2

请注意，使用Git 2.12（2017年第一季度，6年以上），在git分页器会话中的Ctrl + C应该performance得更好。

参见Jeff King（ peff ）的 提交46df690 ， 提交246f0ed ， 提交2b296c9 （2017年1月7日） 。
^{（由Junio C gitster合并- gitster -在承诺5918bdc ，2017年1月18日）}

execv_dashed_external ：等待信号死亡的孩子

打字^C pager ，通常不会杀死它，杀死Git并把寻呼机作为一个附带的损害在某些过程树结构。
这已被修复。

你可以使用像git -p stash list这样的命令运行任何虚拟的外部命令，其中命令完成运行，但是寻呼机仍然在运行。

简短的版本是一切应该正常停止（Git和传呼机）

但详细地说：

当git运行一个pager ，重要的是让git进程停下来等待pager完成，尽pipe它没有更多的数据来提供它。
这是因为git会把pager当成孩子，所以git进程就是terminal上的会话负责人。 它死后， pager将完成从terminal（吃一个字符）的当前读取，然后让EIO尝试再次读取。

注意： EIO （错误5）tands为错误I / O，并且是（ 源 ）：

所有方式的意想不到的硬件错误的catchall。 这可能来自一个物理错误，但另外，一个孤立的进程（一个父进程已经死亡）试图从标准input读取将得到这个。 如果您尝试打开一个已经使用的pty设备，BSD系统会返回这个信息。
尝试从已closures的stream中读取将返回EIO，如同读取或写入的磁盘不在设备的物理边界之内。
当进程没有控制tty时打开/dev/tty tty也会吐出EIO 。

所以（回到pager ^C ）：

当你点击^C时，发送SIGINT到git和pager ，这也是类似的情况。
pager忽略它，但git过程需要四处走动，直到寻呼机完成。 我们很久以前就在a3da882（寻呼机：wait_for_pager on signal death，2009-01-22） 。

但是当你有一个外部虚线（或一个别名指向一个内build的，这将内置的重新执行git），混合中有一个额外的过程。
例如，运行：

 $ git -c alias.l=log l 

最终会得到一个进程树，如：

  git (parent) \ git-log (child) \ less (pager) 

如果你击中^C ， SIGINT去所有的人。 传呼机忽略它，子git进程将在wait_for_pager（）结束。
但是，父Git进程将会死亡，而通常的EIO问题会发生。