14584e7a38
rather than matching path of an existing remote to find the uuid. The main benefit of this is that locations not using ssh:// will work now, including both paths and host:/path The other benefit is that it's a simpler interface, no need to have an existing remote with the same url and some other name. Although that will still work of course. This does rely on tryGitConfigRead working when given a Git.Repo that is not a remote. Luckily, it works fine that way. Also, tryGitConfigRead will auto-init a local repo that has a git-annex branch. I did not enable auto-init of ssh repos though. The uuid discovery actually happens twice; initremote discovers it, and uses it to store the special remote config, but does not set it in the git remote it creates. So the next run of git-annex does uuid discovery again, and caches it that time. This could be improved for a tiny speedup, but I didn't want to complicate things for that in this commit. Sponsored-by: Dartmouth College's DANDI project
18 lines
848 B
Markdown
18 lines
848 B
Markdown
Normally a git repository is not treated as a special remote, but as a git
|
|
remote of the normal kind. Two exceptions to that are [[git-lfs]] and
|
|
[[gcrypt]] special remotes.
|
|
|
|
But it is possible to register a git repository as a special remote.
|
|
git-annex and git will use the remote the same as any normal git remote,
|
|
but its url will be recorded in the repository. One benefit of doing this
|
|
is it allows [[git-annex init|git-annex-init]] to autoenable the remote.
|
|
|
|
To set up such a special remote:
|
|
|
|
git annex initremote myremote type=git location=ssh://... autoenable=true
|
|
|
|
Now `git annex init` in each clone of the repository will autoenable myremote.
|
|
|
|
This only works for git repositories that have a git-annex uuid set,
|
|
because special remotes have to have a uuid. So it cannot be used
|
|
with git repositories that are not git-annex repositories.
|