29 lines
1.4 KiB
Markdown
29 lines
1.4 KiB
Markdown
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
|
|
adding a new remote.
|
|
|
|
That might need changes to the Remote setup method, not sure.
|
|
|
|
Problem: Many urls could be used to clone. http and ssh are the obvious
|
|
two. url=http:// url=ssh:// won't work, only one value will be used.
|
|
url1= url2= is annoying for the user, especially if they later want to add
|
|
another url with enableremote and have to work out the number. Could
|
|
make enableremote with a new url= add that as urlN=.
|
|
[[support_multiple_special_remotes_with_same_uuid]] would solve it, perhaps
|
|
in a cleaner way.
|
|
|
|
> If each url is treated as a separate special remote (which makes a lot of sense
|
|
> by analogy with how regular git remotes work), then
|
|
> [[support_multiple_special_remotes_with_same_uuid]] could be used to
|
|
> solve this.
|
|
|
|
Problem: The user might go in and change the remote's url to point to some
|
|
other server with a different git-lfs backend. In fact, they could already
|
|
do so! Remembering the urls actually would let the special remote detect
|
|
this; it can check if its remote's url is one that it knows about, and
|
|
refuse to use it otherwise.
|