18

  • Which signals are safe, which are not?

  • For those signals which are not safe, which damage could be caused when killing a Git process? Might the working tree be left in an undefined state? Might .git/index or even the .git/objects-database get corrupted?

  • Are files written in some kind of "atomic" operation by Git? (Working tree files, .git/index, configurations files, and so on ...)

Update: more precise question about signals

mstrap
  • 16,808
  • 10
  • 56
  • 86
  • You could be more precise. Which signal exactly would you send the git process to stop it? I'm sure a SIGINT is okay (just like ^C on the command line), but maybe not a SIGKILL or SIGSEGV. – Artefact2 May 07 '12 at 18:47
  • @Artefact2: Thanks, I've formulated question more precise regarding signals. – mstrap May 07 '12 at 18:55
  • (Almost) a duplicate of: http://stackoverflow.com/questions/8384101/can-a-git-repository-be-corrupted-if-a-command-modifying-it-crashes-or-is-aborte – sleske Jan 21 '14 at 14:28

2 Answers2

5

Actually, git tries quite hard to be fully transactional - i.e. it tries to never leave the repository in an inconsistent state, no matter when or how an operation is interrupted - see this question: Can a git repository be corrupted if a command modifying it crashes or is aborted?

So it should not matter how you terminate the git process, if using SIGTERM, SIGKILL or the red power button. The exception, as noted in the answer above, is that the files in the working directory may be a mix of files from different branches, because the files cannot be replaced all at once.

That said, transaction safety is hard to test (as there are many corner cases), so I would not rely 100% on git being safe in this situation. You should normally be ok, but you might hit a bug from time to time and mess up the repository.

Community
  • 1
  • 1
sleske
  • 81,358
  • 34
  • 189
  • 227
  • So what you are saying is that Git is designed in a way that the repository if fully transactional and the working tree almost (except of the mentioned exception), assuming that the implementation is free of bugs? – mstrap Jan 22 '14 at 15:45
  • @mstrap: Yes (actually, it's not me who is saying it but Jan Hudec, who wrote the linked answer). – sleske Jan 22 '14 at 21:08
2

That depends on what GIT is doing when you try to kill it.

If you kill it during a clone, sure it will be left in some partially incomplete state, but it's easy to recover from that: delete the messy partial clone and clone again.

In my experience, GIT doesn't slaughter the files it's managing when it fails. I've killed it in the middle of pushes before without much damage to the files I changed. Granted, the message log can get a little screwy.

Without much more detail than what you've provided, it's hard to say.

kevin628
  • 3,458
  • 3
  • 30
  • 44
  • @mstrap When are you killing GIT? During commits, pushes, pulls, rebases? Or are you just wondering in general what might happen? – kevin628 May 07 '12 at 18:58
  • @kevin268 I plan to kill Git during any operation, from within a user interface, on user request (e.g. when closing a window). Should I allow to do that? – mstrap May 07 '12 at 19:00
  • @mstrap Killing any application should be a last resort. If I were you, I'd try to design my application so that a force-kill of an application is not required. Usually there's a more graceful way to end an application, either through the application's own API or the service manager for the operating system. – kevin628 May 07 '12 at 19:04
  • @kevin268 Thanks Kevin, I'm aware of that. Still for my situation it's desirable to kill Git instead of leaving it running in the background, doing something the user might not be aware of. Of course, this only holds true, if it's safe to kill. – mstrap May 07 '12 at 19:09
  • @kevin628 Graceful shutdowns aren't always the way to go. Compare https://lwn.net/Articles/191059/ – Matthias Dec 02 '20 at 08:38