From 5fe0f1e93956e77bc6c817bd678ffdb85b1ad9d4 Mon Sep 17 00:00:00 2001
From: "http://joeyh.name/" <http://joeyh.name/@web>
Date: Wed, 9 Jul 2014 18:31:07 +0000
Subject: [PATCH] Added a comment: theory

---
 ...3_be42de12faf15562265ad6cf8964f5db._comment | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)
 create mode 100644 doc/bugs/bad_merge_commit_deleting_all_files/comment_3_be42de12faf15562265ad6cf8964f5db._comment

diff --git a/doc/bugs/bad_merge_commit_deleting_all_files/comment_3_be42de12faf15562265ad6cf8964f5db._comment b/doc/bugs/bad_merge_commit_deleting_all_files/comment_3_be42de12faf15562265ad6cf8964f5db._comment
new file mode 100644
index 0000000000..d5a09dc219
--- /dev/null
+++ b/doc/bugs/bad_merge_commit_deleting_all_files/comment_3_be42de12faf15562265ad6cf8964f5db._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.55"
+ subject="theory"
+ date="2014-07-09T18:31:07Z"
+ content="""
+Suppose we have 2 mergeDirect's (A and B) running at the same time somehow, with B around 3 seconds behind A, and this sequence of events occurs:
+
+1. A copies index file to index.lock
+2. A stages an empty commit
+3. B copies index file to index.lock
+4. A finishes its commit, and so renames index.lock back to index.
+5. B runs stageMerge
+
+So, B is now running stageMerge with `GIT_INDEX_FILE` pointing to an index.lock that DNE. As noted above, this causes a deletion of all files to get staged by B.
+
+If this is the problem, git-annex could fix it using a real lock file. (The index.lock only prevents other git commands from manipulating the index during the merge.)
+"""]]