diff options
author | 2014-07-09 13:39:02 -0400 | |
---|---|---|
committer | 2014-07-09 13:39:02 -0400 | |
commit | a0401dcf5431c407477ce0a6547fd701f793636c (patch) | |
tree | 825ed899f4a1da394ed919b439ee26b1a5534f54 | |
parent | 8b60d3933984efda2702ca06eb3d470c676aafd1 (diff) |
bug
-rw-r--r-- | doc/bugs/bad_merge_commit_deleting_all_files.mdwn | 46 |
1 files changed, 46 insertions, 0 deletions
diff --git a/doc/bugs/bad_merge_commit_deleting_all_files.mdwn b/doc/bugs/bad_merge_commit_deleting_all_files.mdwn new file mode 100644 index 000000000..df860c355 --- /dev/null +++ b/doc/bugs/bad_merge_commit_deleting_all_files.mdwn @@ -0,0 +1,46 @@ +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 +work than normal. But, I don't think that bug is fully responsible for the +problem. + + |