From 149f8ced6b40edf83163229cd673718e762b9fd2 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Mon, 15 Jun 2015 14:12:31 -0400 Subject: [PATCH] comment --- ..._4_5a26a33c34594ec6eb50bd675d68801a._comment | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) create mode 100644 doc/bugs/Corrupted_.git__47__annex__47__index_when_running_assistant/comment_4_5a26a33c34594ec6eb50bd675d68801a._comment diff --git a/doc/bugs/Corrupted_.git__47__annex__47__index_when_running_assistant/comment_4_5a26a33c34594ec6eb50bd675d68801a._comment b/doc/bugs/Corrupted_.git__47__annex__47__index_when_running_assistant/comment_4_5a26a33c34594ec6eb50bd675d68801a._comment new file mode 100644 index 0000000000..4b41d988d5 --- /dev/null +++ b/doc/bugs/Corrupted_.git__47__annex__47__index_when_running_assistant/comment_4_5a26a33c34594ec6eb50bd675d68801a._comment @@ -0,0 +1,17 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 4""" + date="2015-06-15T18:05:38Z" + content=""" +git does update the index file atomically (via `rename(2)`) but +that doesn't necessarily mean that the filesystem writes all +the data to disk before there is a problem. + +That's a good point about `git gc` and the index; it does look +at the regular git index. But, `git gc` seems unlikely to cause any problem, +even if .git/annex/index pointed to a newer object that the git-annex branch +hadn't yet been updated to refer to; since `git gc` defaults to only +pruning objects that are 2 weeks old. The time that an object would +normally be in .git/annex/index without getting flushed in a commit +is normally measured in seconds to minutes. +"""]]