1 files changed, 51 insertions, 0 deletions
diff --git a/doc/bugs/fsck_reports_unsolvable_problem/comment_1_2beb21b685cea7402ffbf84d247c30b2._comment b/doc/bugs/fsck_reports_unsolvable_problem/comment_1_2beb21b685cea7402ffbf84d247c30b2._comment
new file mode 100644
index 000000000..e43ed96f5
--- /dev/null
+++ b/doc/bugs/fsck_reports_unsolvable_problem/comment_1_2beb21b685cea7402ffbf84d247c30b2._comment
@@ -0,0 +1,51 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-04-14T16:57:15Z"
+ content="""
+case 1
+
+1. git annex add file
+2. git annex drop --force file
+3. git rm file
+4. git commit -m nochange
+
+case 2
+
+1. git annex add file
+2. git commit -m added
+3. git annex drop --force file
+4. git rm file
+5. git commit -m removed
+
+fsck --all, or fsck in a bare repo, will repport the same problem in either
+case; the only difference being that in the latter case you can see that
+the master branch's history (or some user branch) did once include the lost
+file. In the former case, only the git-annex branch ever had a commit made
+about the lost file.
+
+The only way to remove this message would be either remove the log file
+from the git-annex branch, or teach fsck to ignore it. 
+
+Due to union merge it's not as simple as deleting the log file. A `git
+annex forget` type transition is needed to avoid merging the log file back in
+from elsewhere. It's certianly doable using the transition infrastructure.
+
+Or, fsck could have its own blacklist of known problems to not warn about.
+in some ways that's more complex; in others it's perhaps simpler since it
+avoids the complexity needed to handle transitions. (forced pushing, branch
+rewriting on merge, etc)
+
+Either way, I think the question is what UI to use to identify these keys.
+Seems like the user would have to examine their repos's history and
+understand whether they've hit case 1, or case 2, vs when a file they
+really wanted to have available in the history has actually been lost.
+Fsck could give some guidance, but not a whole lot. Note that if the user
+goofs up, they coud end up in a situation that's rather more a mess than
+this one!
+
+(I've seen maybe half a dozen people reporting this problem before. I think
+most or all of them were using fsck in a bare repository. It might be that,
+if fsck in a bare repository didn't behave as fsck --all, nobody would
+care.)
+"""]]