Can a git repository be corrupted if a command modifying it crashes or is aborted?

Question

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.

Answer 1

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.