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

comment

Browse source
This commit is contained in:
Joey Hess 2022-09-21 13:42:20 -04:00
parent 2f16ff8cdc
commit d330c83e2c
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
1 changed files with 41 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

41
doc/forum/HTTP_uploads/comment_1_e22213816c53e6e3555532c452eceb49._comment Normal file
View file

@ -0,0 +1,41 @@
[[!comment format=mdwn
username="joey"
subject="""comment 1"""
date="2022-09-21T17:17:48Z"
content="""
To upload over HTTP, there needs to be some HTTP endpoint accepting the
upload. There is no "one true way" to upload a file to a HTTP server. There
are several HTTP-based protocols that can be used for uploads
that git-annex supports, including common standards like
[[special_remotes/webdav]] and
[[special_remotes/S3]], and less common standards like
[[special_remotes/git-lfs]].
git-lfs is notable in that it can be used with a regular git remote, that
happens to implement the git-lfs endpoint. No special remote needed.
You can use git-annex to upload to a git-lfs remote. One way to serve
such a remote would be using gitlab.
I don't want to add some additional git-annex specific HTTP-based protocol. I
could see possibly adding support for uploading to git remotes using webdav,
much the same as uploading to git-lfs remotes is handled now. But it does not
seem common to have a webdav server that accepts uploads to the url of your git
repository. Not like it's very common for git-lfs to be supported in a git
repo, when using github or gitlab. It might be more common for a git repo to be
hosted on S3, so maybe uploads to http remotes via S3 would make sense. But
that still seems like a niche configuration.
The reason you see HEADs is that before sending content to a remote,
git-annex checks if the remote already contains it. It knows how to do that
check for a HTTP remote, which it needs to be able to do for other reasons.
So it gets that far before failing. (Doing the check also means that if the
content had been copied to the HTTP remote in the meantime,
`git-annex copy --to` would actually succeed. So it's not entirely useless.)
Note that, with the current version of git-annex, you get a different, and
much better error message:
copy foo (to origin...)
copying to non-ssh repo not supported
failed
"""]]