Hi, I just want to add my 2 cents :) Another issue with libgit2 is that is gives a very misleading error report when trying to http-clone a repo that only support the old "dumb" git protocol (as opposed to the newer "smart" one). More details here[1]. Missing support for that dumb protocol is probably not that big issue in practice. The misleading error Guix presents to the users trying to access some poor git repo is :/ Wojtek [1] https://issues.guix.gnu.org/58555 -- (sig_start) website: https://koszko.org/koszko.html PGP: https://koszko.org/key.gpg fingerprint: E972 7060 E3C5 637C 8A4F 4B42 4BC5 221C 5A79 FD1A Meet Kraków saints! #18: blessed Józef Kowalski Poznaj świętych krakowskich! #18: błogosławiony Józef Kowalski https://pl.wikipedia.org/wiki/Józef_Kowalski_(duchowny) -- (sig_end) On Tue, 22 Nov 2022 11:49:26 -0500 "Philip McGrath" wrote: > Hi, > > On Tue, Nov 22, 2022, at 10:39 AM, zimoun wrote: > > Hi, > > > > On Mon, 21 Nov 2022 at 21:21, Maxim Cournoyer wrote: > > > >> Given that: > >> > >> * the git CLI doesn't suffer from such poor performance; > >> * This kind of performance problem has been known for years in libgit2 > >> [0] with no fix in sight; > >> * other projects such as Cargo support using the git CLI and that > >> projects are using it for that reason [1]; > > > > And I would add the lack of «Support for shallow repositories» [1]. > > > > 1: > > > > > > > PS: For the record, Software Heritage, which ingests *a lot* of Git > > repositories, relies on Dulwhich [2] (pure Python implementation), IIUC. > > > > 2: > > Along those lines, there’s an implementation of clone/checkout in pure Racket (for the package manager) that could probably be ported to Guile relatively easily. I’d expect libgit2 to be faster for the things that it supports, but the Racket implementation does support shallow checkout, so it might pay off if that skips a lot of work. > > Code: https://github.com/racket/racket/blob/master/racket/collects/net/git-checkout.rkt > Docs: https://docs.racket-lang.org/net/git-checkout.html > > (More broadly, I haven’t investigated performance issues, but my basic inclination would be toward improving libgit2 over running the git executable.) > > -Philip >