mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

close a bug report redundant with an existing todo

Browse source 
copied over the dandi tag

updated the todo, as now that sameas is done it's unblocked
This commit is contained in:
Joey Hess 2019-10-21 15:22:19 -04:00
parent 76c050de92
commit 913ac80d33
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
3 changed files with 38 additions and 18 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
doc/bugs/git-lfs_remote_URL_is_not_recorded__63__.mdwn
View file

@ -115,3 +115,5 @@ Shouldn't that URL be recorded in remote.log? (similarly to `type=git` remotes)
[[!meta author=yoh]]
[[!tag projects/dandi]]
> [[done]; see my comment --[[Joey]]

24
doc/bugs/git-lfs_remote_URL_is_not_recorded__63__/comment_1_e2bcd52490fc04850738b72255692e32._comment Normal file
View file

@ -0,0 +1,24 @@
[[!comment format=mdwn
username="joey"
subject="""comment 1"""
date="2019-10-21T19:07:42Z"
content="""
That is intentional, because a git-lfs remote can have multiple urls that
can access it, and different users of the remote might want to use
different urls.
It's also documented to work that way, the same as the directory
special remote documents that you have to provide directory= each time it's
enabled.
But, now that git-annex supports sameas remotes, it would be possible to
have one special remote for each different url to a given git-lfs remote,
and have git-annex know they're the same repository. The user can then
enableremote whichever one they want.
See [[todo/git-lfs_special_remote_simpler_setup]] for where I hope this
will lead.
Closing this bug report as redundant with that todo item, and not actually a
bug since it is documented to behave the way it currently behaves.
"""]]

30
doc/todo/git-lfs_special_remote_simpler_setup.mdwn
View file

@ -5,25 +5,19 @@ 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.
adding a new remote. That might need changes to the Remote setup method,
not sure.
That might need changes to the Remote setup method, not sure.
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.
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.
Many urls could be used to clone the same LFS repo. http(s) and ssh are the
obvious two or three. Now that `initremote --sameas` is available,
special remotes can be initialized for all the urls. The user would need to
do that themselves probably.
> 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.
[[!tag projects/dandi]]
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.