Hi,
Thanks for the answers and comments.
> Yes, I agree that it probably would be much better to go back to use
> dulwich both for protocol serving and for providing data for the web
> frontend, instead of forking out to git. Disclaimer: I don't know has
> fast dulwich is these days. It could
Hi
The code in this area has worked surprisingly well since Kallithea
inherited it, even though it has popped up regularly needing tricky
maintenance. I agree it would be nice to refactor / reimplement this
area. It is just that nobody invested time or sponsorship in doing it. I
guess it
Digging a bit deeper:
- The changeset that you linked
(https://kallithea-scm.org/repos/kallithea/changeset/034e4fe1ebb2#rhodecodelibsubprocessiopy_n127)
actually shows that historically it went the other way round, that is at first
dulwich's server was used but then considered "buggy",
Hi Mads,
I can try that, but I'm a bit worried that it is monkey-patching and
half-solving at best. And the fact that this area is considered "obscure code"
is even worse.
Trying to get a broader picture: There are comments like `TODO: This function
now uses os underlying 'git' command which
Hi
I haven't seen that problem and can't reproduce it.
The wait for 10 seconds in some pretty obscure code came from a comment
in
https://kallithea-scm.org/repos/kallithea/changeset/034e4fe1ebb2#rhodecodelibsubprocessiopy_n127
before The Big Fork. The comment became reality in
Hi,
When cloning a medium-sized repo (not extremely large but with a couple heavy
media files), I consistently get a timeout preventing the cloning from
completing.
Client:
> $ git clone https://user@domain/main_website
> Cloning into 'main_website'...
> Password for 'https://user@domain':
>
