将SIGKILL发送到'git status'安全吗？

如果运行

Git status

花费的时间太长，我想停止Git，但Git似乎忽略了SIGTERMs：

因此，似乎有一种解决方法是使用SIGKILL，但如果发送SIGKILL，则可能会遇到错误并损坏存储库：

---

git status

纯粹是一个查询，因此发送SIGKILL难道不是非常安全吗？

由于无法捕获并立即终止git，这可能会留下各种奇怪或问题

Git被设计为具有合理的弹性：例如，它不只是写出索引，而是将更新后的索引写入名为

.Git/index.lock

，然后在调用新文件

.git/index

时，使用原子操作系统级进程将旧的

.git/index

文件替换为

.git/index.lock

中的新内容。这个原子操作是一个

rename

系统调用：Git依赖于操作系统将其实现为一个原子操作，它要么完全发生，要么永远不会启动

类似的方案用于更新引用和其他文件，包括松散对象和打包文件。并非每个操作系统上的每个文件系统都遵守这些规则，如果操作系统本身崩溃，您可能会遇到各种麻烦的情况，但总的来说，这工作得很好

如果在其中一个关键部分中使用uncatch-able

SIGKILL

杀死Git，会发生什么情况，锁文件仍然留在后面。未来的Git调用将停止，并告诉您存在一个锁文件，无法继续。然后，您的工作就是检查整个系统，确定这是否是一个过时的锁，从而确定它是否可以被删除。如果是这样，则应恢复删除过时锁并重试该操作

当操作系统本身崩溃时，Git可能会丢失Git无法操作的文件。解决这类问题的最佳方法是在其他地方有另一个存储库，最好是物理距离较远的存储库，这样一个常见事件（例如，建筑物着火，其中的所有计算机都烧毁或被火灾扑灭）就不会损坏另一个Git存储库。对于不太极端的情况，有时存储库是可修复的

---

最常见的故障之一是操作系统完全删除名为

.git/HEAD

的文件，该文件消失后，git不再认为存储库是存储库。重新创建文件（例如，

echo-ref:refs/heads/master>.git/HEAD

），然后存储库返回。如果您的系统遵守POSIX文件原子性规则，那么即使对于

SIGKILL

应该是这样，这种特殊情况也不会发生。

git status

上的

strace

不表示对文件系统的任何写入操作。如果它所做的一切都是只读的，那么即使是未经处理的致命信号也不会损坏任何东西。@PSkocik:

git status

有时会写入索引文件（在某些情况下对其进行更新以使将来的操作更快），但它应该在此处捕获

SIGTERM

。您可以强制

git状态

不使用

git更新索引--无可选锁状态

。如果您正在从后台进程运行

git status

，而该进程可能与其他git操作同时运行，则需要执行此操作。@torek是否存在强制git只读的常规标志？我刚刚意识到我在问题中使用了错误的词。我的意思是SIGKILL，因为出于某种原因，

git status

似乎忽略了SIGTERM:@Camelid:最接近的是

——没有可选锁

，这避免了任何不需要运行的锁。请注意，如果使用具有所需锁的命令，它仍然会获取锁（然后写入）。而且，与其说Git忽略了SIGTERM，不如说它捕捉到了SIGTERM（一旦它注意到它应该停止，它会在自己之后进行清理，这可能需要很长时间，

Git状态

应该在它完成时多检查一次……）。但是SIGKILL不能被捕获。所以，如果我使用

git--no optional locks status

，那么它应该可以吗？或者仍然存在腐败的可能性？好吧，如果另一个Git正在运行，

Git的输出--

无可选锁状态可能在您获得它时过期，但它应该是自一致的。我只是想确保它不会破坏回购协议；我不太担心准确性