如果修改 git 存储库的命令崩溃或中止，它是否会损坏？
在使用 git 时，我有时会尝试一些东西，然后中止需要太长时间的命令（例如，一些在网络问题期间挂起的 git svn 命令）。这让我思考：
强制中止命令（Ctrl-C 或 kill）总是安全的吗？如果命令崩溃（内存不足、错误、网络/FS 问题）怎么办？存储库更改是否是“事务性的”，因为不完整的更改会被“回滚”（就像在版本控制文件系统中一样）？或者在这种情况下我是否会面临存储库损坏的风险？
我确信从事 git 工作的聪明人一定已经考虑到了这一点，但我在 git 手册或网上找不到任何信息。
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:
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?
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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
存储库是完全事务性的，是的。
工作树几乎是事务性的，但有一个难以处理的特殊情况。 Checkout 会执行所有必要的检查并将新内容写入临时文件，在此期间，如果您中断它，则不会修改任何内容。但随后它会将文件一一重命名到树中，最后更新 HEAD 引用，并且在该阶段中断可能会让您对树进行部分更改。没有批量重命名允许原子地执行此操作。
The repository is fully transactional, yes.
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.