Hi,
Maxim Cournoyer skribis:
> While attempting to bisect against the Linux kernel tree, the
> performance of libgit2 quickly became problematic, to the point where
> simply cloning the repo became a multiple hours affair, using upward to
> 3 GiB of RAM for the clone and indexing of the objects
Hi,
Phil skribis:
> In particular we were forced to make this change to our local guix build
> to ensure that guix behaved inline with git:
> https://github.com/guix-mirror/guix/commit/473954dd92bbb84693b6fa3f007752eb53c804db
>
> An explanation of why, was raised with libgit2:
> https://github.c
Hi,
On Tue, 22 Nov 2022 at 21:15, Phil wrote:
> Just to add mine too - libgit2 behaves differently to command-line git
> in ways which can make guix do unexpected things when caching clones in
> certain cases. This has resulted in some hard to diagnose issues with
> using guix to build PRs for
Hi,
Wojtek Kosior via Development of GNU Guix and the GNU System distribution.
writes:
> Hi,
>
> I just want to add my 2 cents :)
Just to add mine too - libgit2 behaves differently to command-line git
in ways which can make guix do unexpected things when caching clones in
certain cases. This h
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 pr
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
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 an
Hi,
While attempting to bisect against the Linux kernel tree, the
performance of libgit2 quickly became problematic, to the point where
simply cloning the repo became a multiple hours affair, using upward to
3 GiB of RAM for the clone and indexing of the objects (!)
Given that:
* the git CLI doe
