uninit fails when I symlink your symlink

$ mkdir annex-test
$ cd annex-test/
$ git init
Initialized empty Git repository in /home/me/annex-test/.git/
$ git annex init
init  (scanning for unlocked files...)
ok
(recording state in git...)
$ cat > .gitignore
*
$ cat > exampyle.txt
hello
$ git annex add --no-check-gitignore
add .gitignore (non-large file; adding content to git repository) ok
add exampyle.txt
ok
(recording state in git...)
$ git commit -m \"added\"
[master (root-commit) 2734615] added
 2 files changed, 2 insertions(+)
 create mode 100644 .gitignore
 create mode 120000 exampyle.txt
$ ln -rs exampyle.txt what.foo
$ git status
On branch master
nothing to commit, working tree clean
$ git annex uninit
git-annex: what.foo points to annexed content, but is not checked into git.
Perhaps this was left behind by an interrupted git annex add?
Not continuing with uninit; either delete or git annex add the file and retry.

What should I do?

Honestly, I'm happy with git-annex so far, I'm just thinking that I need to re-init with annex.tune.objecthashlower=true because my other computer is windows.

Thanks!

I see this was resolved as ok behavior, so done --Joey

RSS Atom

forgot to add the new ignored link + shortcoming of 'ln' command

You forgot to add your (gitignore'd) what.foo to git. Another git annex add --no-check-gitignore;git commit -m "add link" will make the subsequent git annex uninit work properly. This is also what the error message says, btw.

But there's another problem underneath: Why is what.foo an annex-style symlink anyway? It should just point to example.txt, right?

🐟 ❯ ln -nrs example.txt what.foo
yann in yann-desktop-nixos in …/uninit-test on  main 
🐟 ❯ ls -l
lrwxrwxrwx 186 yann users 20 Nov 11:08  example.txt -> .git/annex/objects/mK/4w/SHA256E-s6--5891b5b522d5df086d0ff0b110fbd9d21bb4fc7163af34d08286a2e846f6be03.txt/SHA256E-s6--5891b5b522d5df086d0ff0b110fbd9d21bb4fc7163af34d08286a2e846f6be03.txt
lrwxrwxrwx 186 yann users 20 Nov 11:08  what.foo -> .git/annex/objects/mK/4w/SHA256E-s6--5891b5b522d5df086d0ff0b110fbd9d21bb4fc7163af34d08286a2e846f6be03.txt/SHA256E-s6--5891b5b522d5df086d0ff0b110fbd9d21bb4fc7163af34d08286a2e846f6be03.txt

For some reason ln dereferences example.txt before linking, resulting in what.foo pointing to the same as example.txt -- not just to example.txt -- causing what.foo to look exactly like an annex link. I thought -n could fix this, but it would operate on the target what.foo, not the source example.txt 🤦. I couldn't make ln do this properly, except for renaming/removing example.txt, then ln -rsf example.txt what.foo, then restoring example.txt. Not viable. A better solution is cp -s example.txt what.foo. That will make what.foo point properly to just example.txt and not its target.

BTW you can still just git add things like normal non-annex symlinks like what.foo, no need for git annex add here.

Also, joey prefers to have bug reports/questions and the like in either todo, bugs or forum, because it's clear those are the places to look through for issues. Comments below random manpages are quick to be forgotten about. 🙂

Comment by nobodyinperson — Mon Nov 20 10:25:52 2023

Remove comment

comment 6

Thank you for the illuminating comment!

This is also what the error message says, btw.

Not continuing with uninit; either delete or git annex add the file and retry.

You’re right! I thought I only had a relative symlink pointing to the other symlink and not pointing into .git/annex/objects. It turns out that this is true for most of my symlinks but, just like you pointed out, some of them were pointing into .git/annex and the right thing to do there is to add them.

Also, thank you for pointing me towards todo/bugs/forum!

Comment by NewUser — Mon Nov 20 13:17:03 2023

Remove comment

Add a comment