Re: hard dependency on Git? (was bug#65866: [PATCH 0/8] Add built-in builder for Git checkouts)

[Simon Tournier]

Hi Ludo,

On Mon, 18 Sept 2023 at 15:56, Ludovic Courtès <ludo@gnu.org> wrote:

> Anyhow, how about this plan:
>
>   1. Merge <https://issues.guix.gnu.org/65866> with the hard Git
>      dependency.

Is #65866 fixing bug#63331 (Guile-GnuTLS/Git circular dependency) [1]?

Does the merge of #65866 lead to close #63331?  Because you wrote,

    This patch series is a first step towards getting Git out of
    derivation graphs when it’s only used to fetch source code
    (origins with ‘git-fetch’), with the goal of fixing:

so...

>   2. When libgit2 1.7 with shallow clones is available in Guix, work on
>      a patch to use Guile-Git for clones and evaluate it.

...we could also suggest to continue and have a complete fix of #63331
before merging #65866.  It avoids to introduce a hard dependency which
will be difficult to remove and let the time for this evaluation of
libgit-2.1.7, no?

For what my opinion is worth, I have nothing for introducing a hard
dependency to Git but we have to be clear that 1. once introduced it
will hard to remove, 2. we will merge patches using faster Git
plumbing equivalent implementation and so 3. it will push out
Guile-Git.


> As I wrote, as an example, I don’t think that there could be a practical
> implementation of (guix git-authenticate) shelling out to ‘git’.

[...]

> PS: I don’t buy the “libgit2 will disappear from Guix” argument because
>     it’s not a natural phenomenon that we’re observing but a willful
>     construction.

As I wrote elsewhere, Git-Annex (or Magit) are shelling out to 'git',
IIRC.  Well, personally I do not consider that Git-Annex is slow or
that Git-Annex does not implement features as complex as (guix
git-authenticate).

After reading [2],

     I cannot imagine a viable implementation of things like ‘commit-closure’
     and ‘commit-relation’ from (guix git) done by shelling out to ‘git’.
     I’m quite confident this would be slow and brittle.

wolf came 3 days later [3] with a first rough implementation for
'commit-relation' using Git plumbing which is much more faster than
the one implemented with Guile-Git.  Even, speaking specifically about
'commit-relation', I challenge whoever to beat "git merge-base
--is-ancestor"; life is risky: I bet my round of beers in Brussels in
the next Guix Days. :-)  Reading the C implementation of
"merge-base.c" [4] and following the various procedures, it appears to
me impossible to beat it; bah using Guile-Git cumulates various
penalties from talking to libgit2 to the Garbage Collector of Guile.

The question does not appear to me if you buy it or not. :-)  The
question is instead: do we merge code that uses Git plumbing shelling
out that is faster than the current implementation using Guile-Git?

Cheers,
simon

1: https://issues.guix.gnu.org/issue/63331

2: bug#65720: Guile-Git-managed checkouts grow way too much
Ludovic Courtès <ludo@gnu.org>
Fri, 08 Sep 2023 19:08:05 +0200
id:87pm2s385m.fsf@gnu.org
https://issues.guix.gnu.org//65720
https://issues.guix.gnu.org/msgid/87pm2s385m.fsf@gnu.org
https://yhetil.org/guix/87pm2s385m.fsf@gnu.org

3: bug#65720: Guile-Git-managed checkouts grow way too much
wolf <wolf@wolfsden.cz>
Mon, 11 Sep 2023 16:42:59 +0200
id:ZP8nc1m8rN_34XV-@ws
https://issues.guix.gnu.org//65720
https://issues.guix.gnu.org/msgid/ZP8nc1m8rN_34XV-@ws
https://yhetil.org/guix/ZP8nc1m8rN_34XV-@ws

4: 
https://github.com/git/git/blob/bda494f4043963b9ec9a1ecd4b19b7d1cd9a0518/builtin/merge-base.c#L103-L115