4 ms·
That is actually not the case. Say a git server is in the middle of a write to refs/heads/master . You atomically snapshot the FS and then a power outage kills
by jamesmiller5 10y ago
That is actually not the case.
Say a git server is in the middle of a write to refs/heads/master . You atomically snapshot the FS and then a power outage kills the server. The repository state will have a small chance of lock files that are never removed. Depending on the lock, future writes to a ref or to the repository can fail.
Not the worst situation as data lose won't occur but definitely not a stable state. If you treat git repositories as a service that needs a recovery step it would be fine, unfortunately most don't.
(edit) source: http://joeyh.name/blog/entry/difficulties_in_backing_up_live_git_repositories/ http://joeyh.name/blog/entry/difficulties_in_backing_up_live...
- kentonv 10y agoOK, from your link, it looks like the only problem affecting atomic snapshots is that `.git/index.lock` could be left in existence which will block git from doing any operations until it is deleted. For some reason git will instruct the user to delete this file but will not do it automatically, even though it could actually check if any live processes have the file locked, and assume that, if not, it is stale. Seems like a bug in git IMO, but still reasonably easy to recover from.