bug-gnulib
[Top][All Lists]
Advanced

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

Re: Gnulib for non C programs.


From: Mathieu Lirzin
Subject: Re: Gnulib for non C programs.
Date: Fri, 15 Jan 2016 00:30:58 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

Mike Frysinger <address@hidden> writes:

> On 14 Jan 2016 00:59, Mathieu Lirzin wrote:
>> However in the case of GNU packages which don't use C, It is a bit
>> overkill to clone a full repository only for some maintenance scripts
>> and a robust bootstrap script which fetches .po files.
>> [....]
>> What do people think?
>
> is it really that big of a problem to fetch 10MiB of data ?
> $ git clone --depth=1 git://git.sv.gnu.org/gnulib.git
> Cloning into 'gnulib'...
> remote: Counting objects: 9369, done.
> remote: Compressing objects: 100% (8310/8310), done.
> remote: Total 9369 (delta 5065), reused 2198 (delta 1038)
> Receiving objects: 100% (9369/9369), 7.56 MiB | 1.94 MiB/s, done.
> Resolving deltas: 100% (5065/5065), done.
> Checking connectivity... done.
> $ cd gnulib
> $ du -s -h .git
> 8.8M    .git
> $ du -s -h .
> 69M

I didn't know about the --depth option.  Thanks for making me learn
something.  :)

I have just realized that using a Git sub-module for Gnulib is much more
heavy weight than letting bootstrap automatically clone the latest
version of Gnulib with '--depth=2'.  My experience with Gnulib was more
like that:

--8<---------------cut here---------------start------------->8---
./bootstrap: getting gnulib files...
Submodule 'gnulib' (git://git.sv.gnu.org/gnulib.git) registered for path 
'gnulib'
Cloning into 'gnulib'...
remote: Counting objects: 166232, done.        
remote: Compressing objects: 100% (24259/24259), done.        
remote: Total 166232 (delta 141984), reused 166129 (delta 141915)        
Receiving objects: 100% (166232/166232), 31.47 MiB | 767.00 KiB/s, done.
Resolving deltas: 100% (141984/141984), done.
Checking connectivity... done.
Submodule path '.gnulib': checked out '9a7c87c5a5ccb1ab2d5b67bc9b3b8d7ae0fa4377'
--8<---------------cut here---------------end--------------->8---

So I agree with you that the current behavior (without sub-modules) is
adapted for the use case I have described.

--
Mathieu Lirzin



reply via email to

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