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

Merge branch 'master' of ssh://git-annex.branchable.com

Browse source
This commit is contained in:
Joey Hess 2024-10-12 10:57:52 -04:00
commit 9574e3a8bb
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
15 changed files with 383 additions and 2 deletions
Download patch file Download diff file Expand all files Collapse all files

3
doc/todo/p2phttp__58___listen_on_unix_domain_sockets.mdwn Normal file
View file

@ -0,0 +1,3 @@
For p2phttp support in forgejo-aneksajo I decided to just spawn a `git annex p2phttp --wideopen` server, do authentication on the Forgejo side, and then proxy requests to p2phttp. Since p2phttp only supports serving one repository at the moment this means that I have to allocate one free port per repository. Actually finding a free port adds complexity and a race condition, as there also seems to be no way to set `--port 0` for p2phttp and then figure out which port it bound to.
This would be simplified if p2phttp could listen on unix domain sockets instead.

6
doc/todo/p2phttp__58___regularly_re-check_for_annex.url_config.mdwn Normal file
View file

@ -0,0 +1,6 @@
From my experimentation it seems to be that git-annex does not discover the `annex.url` config after the initial clone of a repository. There are at least two situations in which this would be useful though:
1. If the server-side supports p2phttp, but the repository is cloned with an older version of git-annex that doesn't, the annexurl won't be picked up even if the client-side git-annex is later updated to a version that does support p2phttp.
2. Likewise, if the server-side initially didn't support p2phttp and didn't set `annex.url` when the repository was cloned, but is later updated to support it, git-annex doesn't automatically pick up this change.
This automatic discovery would be nice for p2phttp support in forgejo-aneksajo, as existing clones could automatically start making use of it as soon as the instance is updated to support it on the server-side and the git-annex version is updated to be recent enough on the client-side.

13
doc/todo/p2phttp__58___reuse_credentials_for_repos_on_one_host.mdwn Normal file
View file

@ -0,0 +1,13 @@
Plain git tries the same credentials for multiple different repositories on the same host. I.e. with multiple different repositories on <https://atris.fz-juelich.de/>, if I push to one and supply my credentials, these will be saved omitting the actual repository path on the host and will be reused for any other repository that is also located on ATRIS.
Git-annex with p2phttp behaves differently. It saves the full URL to the p2phttp endpoint including the repository path, which means that two repositories using p2phttp will both ask for credentials and save them separate from each other.
This difference in behavior seems to stem from a difference in how `git credential` handles schemes: if you ask it for credentials for `http(s)` it will silently omit any supplied path and only match on scheme and host, while asking for `annex+http(s)` matches on the full scheme, host and path.
There might be some situations in which one would want to associate the credentials with the full path, but in my case for forgejo-aneksajo all authentication is handled by Forgejo and users are global on that instance so per-repository credentials don't make much sense.
I see some ways to address this:
1. Remove the path from the request to `git credential` on git-annex' side
2. Allow `remote.<name>.annexurl` to be set to `http(s)://` URLs in addition to `annex+http(s)://`, exploiting the difference in the `git credential` behavior
3. Perhaps most elegantly: make p2phttp support serving multiple repositories, so that repositories could share the same annexurl and therefore share credentials