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
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
|
In our family repository, we had an event where git-annex committed a bad
merge commit. This had the effect of seeming to delete all the files
in the repository. However, it is completely recoverable with no file loss.
Other users have reported apparently the same problem.
--[[Joey]]
> This appears to be a race, and I have put in a fix for that.
> It will be released in git-annex 5.20140709.
>
> It's a little bit difficult to say for sure that the bug is fixed, since
> I don't have a good way to reproduce it. However, everything I am seeing
> is consistent with my analysis, at least as far as the people who
> reported this happening with versions 5.20140613-5.20140707.
> Calling this [[done]]. --[[Joey]]
## recovery
Look through the git log for the bad commit. It will be the one
that deletes a lot of files. Since the bad commit is a merge commit,
you need to include the -c switch:
git log -c --stat
Once the bad commit sha is found, revert it. Since it's a merge commit,
you will need to pass -m 1 to git revert. If the repository you're working
is uses direct mode, you will first need to switch it to indirect mode.
git annex indirect
git revert -m 1 a36077cf1234eeb755fec8f699d3cbaaee817bac
(It's possible, but I think unlikely that this will pick the wrong
branch of the merge to revert. If it did, "git reset --hard HEAD@{1}" and
redo, passing `-m 2` instead.)
Once the revert is done, all your files should be back. You can switch
the repository back to direct mode if desired (`git annex direct`)
and can `git annex sync` to push the fix out to all other clones.
Everywhere the fix lands should restore the deleted files.
Note that it's possible that some repositories may have pruned the deleted
files as unused. This is most likely to happen in the repository that made
the bad merge commit in the first place.
If you have any problems following these instructions, please contact
<urgent2014@joeyh.name> for support.
[[!tag confirmed urgent]]
## analysis
In the one case I have of this happening, the commit was made by the
git-annex assistant, in direct mode. It was git-annex version 5.20140613.
This version had a bug that caused it to do unncessary merge commits.
That bug has been fixed in 5.20140707.
That is apparently related, in that it caused the assistant to do much more
work than normal.
But, I don't think that bug is fully responsible for the
problem. I think a few users have run into this bug before, although I have
never succeeded in getting a full problem description from anyone who might
have. I think that the unncessary commit bug made it more likely to happen.
(This suggests a race may be involved.)
The bad merge commit looked like this:
<pre>
commit a36077cf1234eeb755fec8f699d3cbaaee817bac
Merge: 52ecff2 9d8bfd4
Author: xxx
Date: Mon Jul 7 19:58:18 2014 -0400
merge refs/heads/synced/master
</pre>
Both parent trees were good and contained all files. In fact, the 2
parent trees contained the same set of files. But the merge commit
"resolved" the merge by deleting all the files.
|
