Menu
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.
463
Git has a command to manually check integrity of the repository: git fsck . Running it lists all the errors. Luckily in my case the list was quite short so I went ahead and deleted all the objects that were listed as corrupted.
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.
122
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
