comment
This commit is contained in:
parent
61c75eb91e
commit
8e7eeb753d
1 changed files with 20 additions and 0 deletions
|
@ -0,0 +1,20 @@
|
||||||
|
[[!comment format=mdwn
|
||||||
|
username="joey"
|
||||||
|
subject="""comment 4"""
|
||||||
|
date="2020-10-12T19:04:49Z"
|
||||||
|
content="""
|
||||||
|
This is not the kind of problem that `git-annex repair` can fix.
|
||||||
|
The problems it fixes are all where one clone of a repo has gotten some
|
||||||
|
object files corrupted by eg disk problems, but other clones still have
|
||||||
|
good copies of those object files.
|
||||||
|
|
||||||
|
The reason `git-annex repair` reports it failed is because it sees that
|
||||||
|
`git fsck` is reporting a problem and the things it's tried to do didn't
|
||||||
|
fix it.
|
||||||
|
|
||||||
|
Are the "missing files" missing in that their annexed content is not
|
||||||
|
present, or missing in that there is no annex symlink at all? In the former
|
||||||
|
case, you need `git annex fsck` on those files, or `git-annex get`. In the
|
||||||
|
latter case, if `git status` doesn't show a missing file as deleted, that
|
||||||
|
would be a very strange problem with git.
|
||||||
|
"""]]
|
Loading…
Reference in a new issue