From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <e@yhbt.net>
X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net
X-Spam-Level: 
X-Spam-Status: No, score=-4.0 required=3.0 tests=ALL_TRUSTED,BAYES_00
	shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2
Received: from localhost (dcvr.yhbt.net [127.0.0.1])
	by dcvr.yhbt.net (Postfix) with ESMTP id 226AB1F5AE;
	Tue, 16 Jun 2020 21:40:51 +0000 (UTC)
Date: Tue, 16 Jun 2020 21:40:51 +0000
From: Eric Wong <e@yhbt.net>
To: meta@public-inbox.org
Subject: thoughts on Git::Raw / libgit2?
Message-ID: <20200616214050.GA15110@dcvr>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
List-Id: <meta.public-inbox.org>

Hey all,

First off, I have no intention of making Git::Raw (Perl libgit2
wrapper) or libgit2 a hard dependency.  It'll be an option if
available, like most of our dependencies.

Git::Raw is not packaged with CentOS 7.x; but cpan/cpanm is an
option.  It is in Debian 10.x as libgit-raw-perl, so I can
report bugs via Debian's BTS[*].

I only intend to use Git::Raw for blob retrievals as a separate
AF_UNIX SOCK_STREAM daemon similar to how we use
`git cat-file --batch/--batch-check'.

The socket/pipe interface works well for unpredictable seek
times on HDDs.  Using Git::Raw from an AF_UNIX SOCK_STREAM
daemon would allow us to save pipe buffers, and PIDs when
there's tens/hundreds of thousands of git repos involved.


[*] I have no intention of ever using a proprietary service for
    free software development.  Even if GitHub were free software,
    their terms-of-service is unacceptable to me.