75 lines
2.9 KiB
Markdown
75 lines
2.9 KiB
Markdown
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.
|
|
|
|
[[!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.
|