Please describe the problem.
original question raised by John which lead me to the goose chase.
Following reproducer
#!/bin/bash
cd "$(mktemp -d ${TMPDIR:-/tmp}/dl-XXXXXXX)"
set -eux
git init --bare remote
( cd remote; git annex init; cat config )
rpath=$PWD/remote
git init repo
cd repo
git annex init
echo 'This is test text.' > file.txt
git add file.txt
git commit -m Init file.txt
git remote add --fetch remote-git $rpath
# without this -- there is no annex-uuid for remote -- git-annex branch is not getting merged
git annex info
cat .git/config
# but this still fails
git annex initremote testremote type=git location=$rpath autoenable=true
ends with
[remote "remote-git"]
url = /home/yoh/.tmp/dl-VjO0aSF/remote
fetch = +refs/heads/*:refs/remotes/remote-git/*
annex-uuid = afdc6d54-cd6d-4a20-b639-a639f9c7ef09
+ git annex initremote testremote type=git location=/home/yoh/.tmp/dl-VjO0aSF/remote autoenable=true
initremote testremote
git-annex: could not find existing git remote with specified location
failed
initremote: 1 failed
so
- error "could not find existing git remote with specified location" seems not descriptive of the underlying problem since location matches the url. Underlying issue is still not clear why we can't initremote
- as you could see in the script - need
annex info
to have annex-uuid populated and looking at code comment -- it requires UUID to be known. If not known -- ideally should be a dedicated error message ("remote blah found but lacks uuid, check if remote is annex") - IMHO should not need manual
annex info
to merge git-annex branch
What steps will reproduce the problem?
above
What version of git-annex are you using? On what operating system?
10.20220504
Hmm, I think this only works for ssh:// urls currently.
Even the ssh url form host:/path does not work, because it gets normalized to a ssh:// url.
The implementation does not support non-url's at all; the provided location is treated as an url (
Git.Url location
). And even if it were treated as a path, the path gets normalized to a relative path and an absolute path (or differently relavatized path) would not work.Using paths with this is rather problematic too, because if the repo is cloned to another machine, it would not find the repo at the recorded path. Similarly, relative paths are also problimatic. But it may as well support them to the extent it can.
I think this needs changes to the core Git data structure, to store the original, unmodified git.remote.path. Or a different interface than the current, one that accepts any repo location and probes it to find the uuid. The latter idea seems better because it simplifies the UI rather than complicating the internal representation.
Wouldn't it be possible to support (absolute) file:// urls, eg. something similar to
file:///home/jkniiv/test-VEfBrTZ/remote2
? In my mind they feel like a reasonable approximation of ssh:// urls and could be useful for getting a feel for git special remotes before setting up a bare git-repo/annex on an ssh-server. I know they are not the same thing implementation wise but I feel that being able to try this feature out on a least-effort basis would be useful from a pedagogical standpoint.Implemented probing of the uuid of the repo location. Which may change how you use this feature. Although the old roundabout method of having an existing git remote and running initremote with the same location will work too, it's not neccessary to do that anymore.
Re file:// urls, it does now work to use them in location=. I don't know if I'd consider using them any better than absolute paths though. YMMV.