1 files changed, 0 insertions, 45 deletions
diff --git a/doc/bugs/git-annex_branch_push_race.mdwn b/doc/bugs/git-annex_branch_push_race.mdwn
deleted file mode 100644
index 013ff70dd..000000000
--- a/doc/bugs/git-annex_branch_push_race.mdwn
+++ /dev/null
@@ -1,45 +0,0 @@
-The fix for the [[git-annex_branch_corruption]] bug is subject to a race.
-With that fix, git-annex does this when committing a change to the branch:
-
-1. lock the journal file (this avoids git-annex racing itself, FWIW)
-2. check what the head of the branch points to, to see if a newer branch
-   has appeared
-3. if so, updates the index file from the branch
-4. stages changes in the index
-5. commits to the branch using the index file
-
-If a push to the branch comes in during 2-5, then
-[[git-annex_branch_corruption]] could still occur.
-
----
-
-## approach 1, using locking
-
-Add an update hook and a post-update hook. The update hook
-will use locking to ensure that no git-annex is currently running
-a commit, and block any git-annex's from starting one. It
-will background itself, and remain running during the push.
-The post-update hook will signal it to exit.
-
-I don't like this approach much, since it involves a daemon, two hooks,
-and lots of things to go wrong. And it blocks using git-annex during a
-push. This approach should be a last resort.
-
-## approach 2, lockless method
-
-After a commit is made to the branch, check to see if the parent of
-the commit is the same ref that the index file was last updated to. If it's
-not, then the race occurred.
-
-How to recover from the race? Well, just union merging the parent of the
-commit into the index file and re-committing should work, I think. When
-the race occurs, the commit reverts its parent's changes, and this will
-redo them. 
-
-(Of course, this re-commit will also be subject to the race, and
-will need the same check for the race as the other commits. It won't loop
-forever, I hope.)
-
-> [[done]] and tested.
-
---[[Joey]]