2019-09-30 21:32:41 +00:00
|
|
|
It would be nice if a clone from eg, gitlab could autoenable the git-lfs
|
|
|
|
special remote. Currently, autoenable doesn't work for git-lfs special
|
|
|
|
remotes at all, because the url is not stored.
|
|
|
|
|
|
|
|
What if, an url or urls passed to initremote were stored. Then when
|
|
|
|
enableremote/autoenable runs, if it sees a git remote with a known url,
|
|
|
|
it sets that remote up with annex-uuid and annex-git-lfs set, instead of
|
2019-10-21 19:22:19 +00:00
|
|
|
adding a new remote. That might need changes to the Remote setup method,
|
|
|
|
not sure.
|
2019-09-30 21:32:41 +00:00
|
|
|
|
2019-10-21 19:22:19 +00:00
|
|
|
Or, Remote.Git could, when enumerating remotes, call into Remote.GitLFS
|
|
|
|
to check if the url is one it knows about, and if so, autoenable
|
|
|
|
the special remote. Although that would mean reading remote.log when
|
|
|
|
enumerating remotes, which I think is currently avoided, and might be too
|
|
|
|
much overhead to add to git-annex generally for the value of this feature.
|
2019-09-30 21:32:41 +00:00
|
|
|
|
2019-10-21 19:22:19 +00:00
|
|
|
Many urls could be used to clone the same LFS repo. http(s) and ssh are the
|
2019-11-04 15:48:45 +00:00
|
|
|
obvious two or three. Now that `initremote --sameas`
|
|
|
|
[[is available|support_multiple_special_remotes_with_same_uuid]],
|
2019-10-21 19:22:19 +00:00
|
|
|
special remotes can be initialized for all the urls. The user would need to
|
|
|
|
do that themselves probably.
|
2019-09-30 21:35:38 +00:00
|
|
|
|
2019-11-18 20:09:09 +00:00
|
|
|
> [[done]], the url is stored, and when there's a remote that has an url
|
|
|
|
> that's known to be to a git-lfs repo, that remote is automatically
|
|
|
|
> enabled to be used as a git-lfs special remote. --[[Joey]]
|
2019-10-01 16:36:25 +00:00
|
|
|
|
2019-11-18 20:09:09 +00:00
|
|
|
[[!tag projects/dandi]]
|