Hi Ludovic, Ludovic Courtès <l...@gnu.org> writes:
> Hi! > > Maxim Cournoyer <maxim.courno...@gmail.com> skribis: > >> So given there's no technical reasons not to use libgit2, I'd use that >> and keep the closure size down. > > For the record, that’s a 6% increase: > > $ guix size guix | tail -1 > total: 633.0 MiB > $ guix size guix git-minimal | tail -1 > total: 675.7 MiB > > (Of course it all adds up; I’m not saying we can dismiss it.) As Simon pointed out, it'd be more after wrapping 'git' with coreutils and possible util-linux on its PATH. > In the context of <https://issues.guix.gnu.org/65866> plus the lack of > GC in libgit2 discussed in <https://issues.guix.gnu.org/65720>, my > inclination is to include that hard dependency on Git. > > That’s not a happy choice for me, but it has the advantage of solving > two immediate problems. > > I would revisit it as soon as libgit2 supports shallow clones (which is > coming, as you write) This isn't "coming", it's already been released :-). > and GC (or a workaround to that effect). SHA256 may also soon be a > requirement: we’ll need to be able to clone repos that use it. > > How does that sound? Yeah, 'git gc' is lacking from libgit2. I'm not against adding dependency on the real 'git' CLI, but at that point, as Simon mentioned, I see little reason to keep libgit2 around for much longer, given it performs worst than git CLI in every aspect. I doubt forking processes on GNU/Linux would cause a performance hit compared to using libgit2, especially given how optimized git appears to be (at least compared to libgit2). So, I think we need to agree on the future of libgit2 in the big picture and decide to invest in it or let it in favor of just using git. -- Thanks, Maxim
