2014-07-09 17:39:02 +00:00
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
Another user has reported apparently the same problem.
|
|
|
|
|
--[[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. (Although
|
|
|
|
|
it's possible that some repositories may have pruned the deleted
|
|
|
|
|
files as unused.)
|
|
|
|
|
|
|
|
|
|
[[!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
|
2014-07-09 17:43:22 +00:00
|
|
|
work than normal.
|
2014-07-09 17:39:02 +00:00
|
|
|
|
2014-07-09 17:43:22 +00:00
|
|
|
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.)
|
2014-07-09 17:39:02 +00:00
|
|
|
|
2014-07-09 17:43:22 +00:00
|
|
|
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.
|
