summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorGravatar CandyAngel <CandyAngel@web>2016-05-10 07:25:09 +0000
committerGravatar admin <admin@branchable.com>2016-05-10 07:25:09 +0000
commitb06375ad85219220a44e6363e18682a79a09dd01 (patch)
treeea64fe4915c3176d8a78419ef59251de15017a8b
parent735de40f6e06639325396c8f93cfb7107c0a79c2 (diff)
-rw-r--r--doc/forum/Making_a_git-annexy_symlink___34__known__34____63__.mdwn7
1 files changed, 7 insertions, 0 deletions
diff --git a/doc/forum/Making_a_git-annexy_symlink___34__known__34____63__.mdwn b/doc/forum/Making_a_git-annexy_symlink___34__known__34____63__.mdwn
new file mode 100644
index 000000000..8d298ae83
--- /dev/null
+++ b/doc/forum/Making_a_git-annexy_symlink___34__known__34____63__.mdwn
@@ -0,0 +1,7 @@
+Currently, if you git-add a symlink copied from another git-annex, git-annex will 'fix' it so it points to where the files would be in its new annex object store, but doesn't create the corresponding file for the key on the git-annex branch, so git-annex doesn't actually "know" about the file.
+
+This means running *git annex reinject --known* won't reinject the content for the symlink (e.g. "Not known content; skipping").
+
+I tried running git-annex-fsck hoping it would create the file (with the information that 0 copies exist) but it doesn't do that..?
+
+Any advice on how to go about resolving this? Preferably a "lightweight" way as this repository has a lot of such transplanted symlinks.. :)