Please describe the problem.
I have a git-annex repo as a submodule. When adding a file using git-annex, I get the error message:
warning: unable to convert submodule to form that will work with git-annex
This I seem to get for every file, i.e. thousands of error messages sometimes. But the repo in the submodule seems to work fine, the .git symlink is there.
I am not able to spot the problem in Annex/Fixup.hs, maybe you have an idea what could go wrong?
What steps will reproduce the problem?
mike@leguin experiments % date > test2
mike@leguin experiments % git annex add test2
add test2 (non-large file; adding content to git repository) ok
(recording state in git...)
warning: unable to convert submodule to form that will work with git-annex
mike@leguin experiments % ls -l ../.git
lrwxrwxrwx. 1 mike mike 53 Nov 16 17:31 ../.git -> ../../../.git/modules/experiments/ocr-evaluation/data
What version of git-annex are you using? On what operating system?
git-annex version: 8.20201127 Fedora 32
Also the same on CentOS 7, I was just able to reproduce it on my F32 workstation. ext4 filesystem.
Please provide any additional information below.
# If you can, paste a complete transcript of the problem occurring here.
# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
# End of transcript or log.
Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
Besides this problem, I am super happy with git-annex and use it at work and at home daily 
fixed although w/o a way to reproduce it I can't be 100% sure --Joey
In the submodule:
If I understand needsSubmoduleFixup correctly, this should not need fixing anymore, is that correct?
Hmm, that happens if it somehow gets an exception while fixing up the .git file and unsetting core.worktree in the git config. I've modified the code so it now will display the exception as part of that message.
If by "get for every file" you mean the same run of git-annex is displaying it repeatedly, that would be weird -- it's run in early startup not later.
One way I can see this failing is if core.worktree is not actually set. Then unsetting it would fail and it would display this message. But it would not even try to unset core.worktree unless something tells git-annex that the git directory is located under the parent repo's .git/modules/ Despite the
git rev-parseyou show, something is making git-annex still think that is the case. Likely because .git is not a symlink.I'll try to compile from source and get the exact exception then! I'll also check if I can come up with a minimal repo that reproduces the problem.
I do get thousands of those error messages and on the occasion that I noticed this problem I was checking in thousands of files, and I also get the message once(!) when I
git annex adda single test file, so this only my suspicion.See above, it's a symlink to the directory under the parent repo's ./git/modules. Is this how it is intended?
For some reason, I couldn't reproduce it easily using
git annex addon my F32 workstation, but I got it on agit annex get:Thanks Mike, that confirms it's failing to unset the config that's not set.
The .git symlink is what git-annex is supposed to set up, so it should not need to do anything else and the question is, why does it still think it needs to change something?
I was able to reproduce the warning, just run
git submodule add foo /path/to/annexrepoand then in foo,git-annex initand then it happens part-way through. Due to two different git-annex processes both trying to do the same conversion, with the second one failing. I've fixed that.My fix will also fix your problem. But, I don't actually understand how to reproduce your problem. I was only able to make it happen when running
git-annex init(or letting it auto-init), not running other git-annex commands in a repo it's already initialized.Maybe you have
GIT_DIRset to "../../../.git/modules/..."?git annex addruns agit ls-fileswhich in turn runsgit-annex smudgefor every file, which probably each outputs the error message.Makes sense that
git-annex smudgebeing called repeatedly would output the message like that. And unfortunately, yes, when a file is unlocked and gets modified, git ls-files --modified does need to smudge it. Thanks for clearing that part up.