diff options
-rw-r--r-- | doc/bugs/fsck_reports_unsolvable_problem/comment_1_2beb21b685cea7402ffbf84d247c30b2._comment | 51 |
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.) +"""]] |