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

Added a comment: Indeed git annex fsck can take into account objects manually placed into .git/annex/objects

Browse source
This commit is contained in:
https://launchpad.net/~stephane-gourichon-lpad 2017-07-28 05:03:30 +00:00 committed by admin
parent 48c98fbe93
commit 14b40c79c7
1 changed files with 84 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

84
doc/forum/Rebuild_a_set_of_repos_from_checked-out_trees_and_.git__47__annex__47__objects__63__/comment_2_410f329fb47f13afc59b5b37b88a8c3a._comment Normal file
View file

@ -0,0 +1,84 @@
[[!comment format=mdwn
username="https://launchpad.net/~stephane-gourichon-lpad"
nickname="stephane-gourichon-lpad"
avatar="http://cdn.libravatar.org/avatar/02d4a0af59175f9123720b4481d55a769ba954e20f6dd9b2792217d9fa0c6089"
subject="Indeed git annex fsck can take into account objects manually placed into .git/annex/objects"
date="2017-07-28T05:03:30Z"
content="""
Thanks @CandyAngel. This is similar to wat I'm doing and somehow validates.
I'm trying to repair on the same filesystem without long recopy.
I don't understand why your solution is specific to v5 indirect mode.
# Indeed git annex `fsck` can take into account objects manually placed into `.git/annex/objects`.
Let's create a repo:
mkdir repo1
cd repo1/
ls -al
git init
git annex init repo1
ls -a
ls -al
echo 1 > 1
git annex add 1
git annex sync
git annex fsck
git annex repair --verbose
Everything is fine.
Let's say this repo has its git structures broken and we rebuild it from checked-out tree and `.git/annex/objects`. We'll lose tree history and location tracking history but recover content.
cd ..
mkdir repo2
cd repo2
git init
git annex init repo2
Ok we have an empty repo. Let's import tree.
cp -al ../repo1/* .
ls -al
git annex add .
git annex repair --verbose
Running git fsck ...
No problems found.
ok
Notice that `git annex repair` does not care about annexed objects, only history data.
git annex fsck
But `fsck` notices about missing objects.
fsck 1
** No known copies exist of 1
failed
(recording state in git...)
git-annex: fsck: 1 failed
So, in a sense, `git annex fsck` and `git annex repair` operate on nearly independent things.
Let's get annexed objects back.
ls -al # red shows symlink is broken
cp -al ../repo1/.git/annex/objects/ .git/annex/
find .git/annex/objects/
ls -al # grey shows symlink is okay
git annex fsck
Hooray, `fsck` notices that objects are back.
fsck 1 (fixing location log) (checksum...) ok
(recording state in git...)
# Conclusion
I can use approach (1). Extra benefit: it will notice if some files got corrupted on the filesystem.
Approach (2) would mean, if any file was corrupted on the filesystem, it would have been considered the correct content, and I'd prefer to avoid that.
"""]]