如果修改它的命令崩溃或中止

如果修改它的命令崩溃或中止

本文介绍了如果修改它的命令崩溃或中止,git 存储库是否会损坏?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

在玩 git 时,我有时会尝试一些东西,然后中止花费太长时间的命令(例如,某些 git svn 命令在网络问题期间挂起).这让我想到:

When playing around with git, I sometimes try out things, then abort commands which take too long (e.g. some git svn commands that hang during network problems). This got me thinking:

强制中止命令(Ctrl-C 或 kill)总是安全的吗?如果命令崩溃(内存不足、错误、网络/FS 问题)怎么办?从不完整的更改被回滚"(如在版本控制文件系统中)的意义上说,存储库更改是否是事务性的"?或者,在这种情况下,我是否有存储库损坏的风险?

Is it always safe to forcefully abort a command (Ctrl-C or kill)? What if a command crasheds (out of memory, bug, network/FS problem)? Are repository changes "transactional" in the sense that incomplete changes are "rolled back" (like in a versioning filesystem)? Or do I risk repository corruption in that case?

我相信在 git 上工作的聪明人一定已经考虑到了这一点,但我在 git 手册或网上找不到任何信息.

I'm sure the smart people working on git must have taken this into account, yet I could not find any information in the git manual or online.

推荐答案

存储库是完全事务性的,是的.

The repository is fully transactional, yes.

工作树几乎是事务性的,但有一个难以处理的极端情况.Checkout 执行所有必要的检查并将新内容写入临时文件,在此期间,如果您中断它,则不会修改任何内容.但是随后它会一个一个地将文件重命名为树,最后更新 HEAD 引用,并且在该阶段中断可能会使您对树进行部分更改.没有批量重命名来允许以原子方式执行此操作.

The work tree is almost transactional, but there is a corner case that can't easily be dealt with. Checkout does all necessary checks and writes the new content to temporary files and during the time, nothing is modified if you interrupt it. But then it's renaming the files to the tree one by one and finally updates the HEAD ref and interrupting in that phase can leave you with partial changes made to the tree. There is no mass-rename to allow doing that atomically.

这篇关于如果修改它的命令崩溃或中止,git 存储库是否会损坏?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!

08-04 07:06