Please describe the problem.
When cloning a repository via SSH that is shared on the remote system (e.g. belongs to a different account), git-annex produces a wrong/misleading error message.
What steps will reproduce the problem?
- Create a shared git repository with one account
- With another account, ensure that git refuses to do anything with the repository:
git annex info
should lead to a "git-annex: Git refuses to operate in this repository" error - Clone the repository via ssh with that other account
- Run
git annex init
in that clone - Notice a misleading error message:
$ git annex init
init
Unable to parse git config from origin
Remote origin does not have git-annex installed; setting annex-ignore
This could be a problem with the git-annex installation on the remote. Please make sure that git-annex-shell is available in PATH when you ssh into the remote. Once you have fixed the git-annex installation, run: git annex enableremote origin
ok
(recording state in git...)
The error will go away once the safe.directory config is set for the repository:
git config --global --add safe.directory <path>
This command is correctly suggested in the output of git annex info
from the above step 2, but since one doesn't always run that first and instead just tries to clone, the misleading error message can cause a bit of wasted time trying to figure out why git-annex wouldn't be available in the PATH when in reality it is.
What version of git-annex are you using? On what operating system?
git-annex version: 10.20240430
build flags: Assistant Webapp Pairing Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite S3 WebDAV
dependency versions: aws-0.24.1 bloomfilter-2.0.1.2 crypton-0.34 DAV-1.3.4 feed-1.3.2.1 ghc-9.6.5 http-client-0.7.17 persistent-sqlite-2.13.3.0 torrent-10000.1.3 uuid-1.3.15 yesod-1.6.2.1
key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL VURL X*
remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg rclone hook external
operating system: linux x86_64
supported repository versions: 8 9 10
upgrade supported from repository versions: 0 1 2 3 4 5 6 7 8 9 10
local repository version: 10
on Ubuntu installed from nixpkgs.
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)
Seems to be fixed by current git and/or git-annex. done --Joey
possibly related:
As a sidenote, I have been having nothing but pain and suffering with sharing git repos between users. The only viable way for me was to always access a git repo with the same user, otherwise it's been permission hell.
Thanks for the hints. Seeing that https://git-annex.branchable.com/bugs/enableremote_fails_with___34__wrong_reason__34___stated/ is marked as fixed prompted me to check again and it turns out that I reported the wrong git-annex version above: while that is the local version, the remote system has 10.20230626-g8594d49 (the latest one available from conda-forge, unfortunately that is rather old now), and it makes sense that the relevant version in this case is the one running on the remote system.
So I guess this is fixed already, my git-annex is just too old (although I haven't double checked, I don't see a convenient way right now to get a more recent git-annex version onto that remote system -- HPC, no root).
Here is what I get while cloning:
This is with git 2.45.2, and since current git prevents cloning a repository in this situation, git-annex doesn't need to do anything.
I also tested what happens if the repository ownership allows cloning, but after clonging and before git-annex init, the repository owner changes. In that case, with current git-annex,
git-annex-shell configlist
is able to get the uuid from the remote repository despite the ownership snafu. Which is ok.