we created Baobáxia, with a python layer on top of g-a that implement something like that:

https://git-annex.branchable.com/design/requests_routing/

I suppose this wouldn't have to communicate over unix sockets either, it could also use stdin/stdout like git annex shell p2pstdio, but without skipping authentication, instead using the git annex p2p pairing process. Something like socat could then be used to connect those stdin/stdout's to a unix socket, tcp port, or whatever else.

FWIW, I do like separation into a dedicated annexInsteadOf and its alignment to annexUrl <-> pushUrl! I will try it up soonish. Thank you!

Looking at the network inspector, it seems more likely a given click stalls when there are multiple long polling requests ongoing at the same time (which show as "pending").

So on a hunch, I disabled javascript in chromium. No more hangs.

I suppose maybe chromium has a small pool of connections to the web server, and if all of those get blocked up doing long polling, and if it doesn't cancel those when navigating away from the page that made the long polling request, it could block?

But why wouldn't it cancel them? The requests were made by the page it's navigating away from. Maybe it cancels them only once it's loaded the new page.

I do think that's it though. When I open 2 tabs both to the webapp, a request in one tab can be stalled, and pressing escape in the other tab, when it cancels the long polling requests, will unstall it.

Amazingly, chromium is limited to 6 concurrent connections per server, with no way to configure it! And the front page of the webapp opens several long polling connections.

In firefox, by comparison, the network inspector shows the long polling connections apparently disappear when navigating to a new page. But, there is a similar problem, when opening 2 tabs to the webapp, one can stall, due to the long polling connections open by the other tab.

So, I think the solution to this will either need to involve some change to the long polling javascript, if there is some way to make chromium cancel the request when navigating away... Or it would need to replace the long polling with something else entirely.

Tried in chromium, also seeing it block sometimes, though not always, on page loads.

This seems rather similar to this old bug involving the same software: https://github.com/yesodweb/wai/issues/146 But not I think quite the same, because that was caused by a long delay between clicks, and this happens when clicking immediately.

The browser's network console shows a few ms for all resources to load, except the page itself which for some reason takes a log time.

tcpdump shows that chromium does not send a request for that page until many seconds after the click. The response to the request is immediate.

Before that point there is only some SYN/ACK traffic. Which looked a bit weird maybe.

Maybe what's really missing is url.<base>.annexInsteadOf corresponding to url.<base>.pushInsteadOf.

The same way remote.<name>.annexUrl corresponds to remote.<name>.pushUrl.

You would need to set 2 configs, but the separation is clear. And you could set it once in your global git config for whatever servers you commonly use.

Another benefit to is that the new git-annex p2phttp server needs annexUrl to be configured to a different url than the git url when using it. annexInsteadOf would let that be configured a single time for all urls on a given git server.

Update: Implemented that. Let me know if you think it solves your problem well enough.

If git-annex used pushInsteadOf for sending content to a remote, should it also use it for dropping content from the remote? Dropping is quite far from pushing. Does it make sense to expect the user to generalize "push" to "arbitrary write access" when it comes to git-annex's interpretation of configuration settings that were designed for git?

Granted, git-annex push can drop content from the remote when preferred content is configured to.

git-annex does not currently use pushurl, and making it start to use it would be the same kind of potentially breaking change as making it start to use pushinsteadof.

I get where you're coming from but just because a lot of people use pushinstead of that way does not mean that other people don't use it to redirect pushes to an entirely different clone of the repository.

Here Junio calls using pushurl that way a "common mistake", so I guess he is seeing people do that. He does have a good point that with such a configuration refs/remotes/origin won't (usually) reflect the state of both repos.

Just tested more: - Brave - slow - Chrome - slow - Firefox - works like a dream

It seems it's something wrong with Chromium-family browser support. There are no JavaScript and network errors in developer console. I also tried to start git annex webapp with --vebose and --debug flags - nothing there as well.

What browser?