[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