summaryrefslogtreecommitdiff
path: root/doc/bugs/bad_merge_commit_deleting_all_files.mdwn
diff options
context:
space:
mode:
authorGravatar Joey Hess <joeyh@joeyh.name>2016-04-19 13:46:11 -0400
committerGravatar Joey Hess <joeyh@joeyh.name>2016-04-19 13:55:29 -0400
commitdbfc00e2a6ad99200da35f75f889174cd7bfd195 (patch)
tree9d8a9d1353ab10376183c1bda881fface04b6fcb /doc/bugs/bad_merge_commit_deleting_all_files.mdwn
parent41b7950285ef1e91b80c441c2be68a1ef4d0d27c (diff)
remove old closed bugs and todo items to speed up wiki updates and reduce size
Remove closed bugs and todos that were last edited or commented before Q3 2015. Command line used: for f in $(grep -l '\[\[done\]\]' -- *.mdwn); do d="$(echo "$f" | sed 's/.mdwn$//')"; if [ -z "$(git log --since=09-09-2015 --pretty=oneline -- "$f")" -a -z "$(git log --since=09-09-2015 --pretty=oneline -- "$d")" ]; then git rm -- "$f"; git rm -rf "$d"; fi; done for f in $(grep -l '|done\]\]' -- *.mdwn); do d="$(echo "$f" | sed 's/.mdwn$//')"; if [ -z "$(git log --since=09-09-2015 --pretty=oneline -- "$f")" -a -z "$(git log --since=09-09-2015 --pretty=oneline -- "$d")" ]; then git rm -- "$f"; git rm -rf "$d"; fi; done
Diffstat (limited to 'doc/bugs/bad_merge_commit_deleting_all_files.mdwn')
-rw-r--r--doc/bugs/bad_merge_commit_deleting_all_files.mdwn78
1 files changed, 0 insertions, 78 deletions
diff --git a/doc/bugs/bad_merge_commit_deleting_all_files.mdwn b/doc/bugs/bad_merge_commit_deleting_all_files.mdwn
deleted file mode 100644
index affabdb02..000000000
--- a/doc/bugs/bad_merge_commit_deleting_all_files.mdwn
+++ /dev/null
@@ -1,78 +0,0 @@
-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.