bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GNULIB_REVISION


From: Paul Eggert
Subject: Re: GNULIB_REVISION
Date: Thu, 25 Apr 2024 10:00:01 -0700
User-agent: Mozilla Thunderbird

You raise several good points. A couple of quick reaction:

On 2024-04-25 09:26, Simon Josefsson via Gnulib discussion list wrote:

- the gnulib git submodule is huge.  Not rarely I get out of memory
   errors during 'git clone' in CI/CD jobs.

First I've heard of this problem (other than with Git LFS, which Gnulib doesn't use). What part of the clone operation fails? Is this server-side RAM, or client-side RAM, or something else? How much memory does 'git clone' require now for Gnulib?

Is there some way to cajole 'git clone' into using less memory, with a '--depth 1' or similar options? Cloning shallowly would clone Gnulib a lot faster, if you're cloning from a remote repository.


- we don't offer any way for people receiving tarballs to learn which
   gnulib git commit was used

Isn't the real problem that we don't put (for example) gzip's own commit ID into the coreutils tarball? If we did that, Gnulib's commit ID would come for free, since it can be derived from gzip's commit ID.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]