1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
|
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]]
|
