mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

comment

Browse source
This commit is contained in:
Joey Hess 2015-04-14 13:11:17 -04:00
parent efd6a8e3aa
commit a906f75699
1 changed files with 51 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

51
doc/bugs/fsck_reports_unsolvable_problem/comment_1_2beb21b685cea7402ffbf84d247c30b2._comment Normal file
View file

@ -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.)
"""]]