Updating the guix package triggers a full Git clone of guix.git

  • Open
  • quality assurance status badge
Details
3 participants
  • Leo Famulari
  • Ludovic Courtès
  • Maxim Cournoyer
Owner
unassigned
Submitted by
Leo Famulari
Severity
normal
L
L
Leo Famulari wrote on 2 Nov 2020 01:50
(address . bug-guix@gnu.org)
20201102005049.GA3248@jasmine.lan
While building the package of Guix itself [0], I noticed that Savannah
can't serve cheap "shallow clones" of the commits that these packages
are based on, so users will end up doing full clones (260M on
disk):

------
building /gnu/store/ma04vkl42jyr9p2nw5yzlzw61r5s2h3p-guix-1.1.0-31.1c6d985-checkout.drv...
guile: warning: failed to install locale
environment variable `PATH' set to `/gnu/store/378zjf2kgajcfd7mfr98jn5xyc5wa3qv-gzip-1.10/bin:/gnu/store/sf3rbvb6iqcphgm1afbplcs72hsywg25-tar-1.32/bin'
Initialized empty Git repository in /gnu/store/nwf2579gigc9xhnd7i82lpmja854l9fb-guix-1.1.0-31.1c6d985-checkout/.git/
error: Server does not allow request for unadvertised object 1c6d98533153bc8e0e36236e7fbcf1eb5e178d26
Failed to do a shallow fetch; retrying a full fetch...
------

I'm reaching out to the Savannah admins to ask them about this, and if
it has any unduly negative affects on the Savannah infrastructure.

Maybe these commits should be tagged?

[0]
That is, while building (@@ (gnu packages package-management) guix)
L
L
Leo Famulari wrote on 2 Nov 2020 02:39
(address . 44382@debbugs.gnu.org)
20201102013936.GA12663@jasmine.lan
I poked around a bit and found that Savannah can serve shallow clones of
random commits, but does not allow shallow *fetching*, except for
special things such as Git tags. We fetch instead of clone.
L
L
Ludovic Courtès wrote on 3 Nov 2020 22:48
Re: bug#44382: Updating the guix package triggers a full Git clone of guix.git
(name . Leo Famulari)(address . leo@famulari.name)(address . 44382@debbugs.gnu.org)
87tuu6az86.fsf@gnu.org
Hi,

Leo Famulari <leo@famulari.name> skribis:

Toggle quote (4 lines)
> I poked around a bit and found that Savannah can serve shallow clones of
> random commits, but does not allow shallow *fetching*, except for
> special things such as Git tags. We fetch instead of clone.

Weird, what’s the difference between fetch and clone technically? I
believe commit 329dabe13bf98b899b907b45565434c5140804f5 moved to “fetch”
precisely so we could do shallow clones.

Ludo’.
L
L
Leo Famulari wrote on 5 Nov 2020 18:11
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 44382@debbugs.gnu.org)
20201105171106.GA9818@jasmine.lan
On Tue, Nov 03, 2020 at 10:48:25PM +0100, Ludovic Courtès wrote:
Toggle quote (4 lines)
> Weird, what’s the difference between fetch and clone technically? I
> believe commit 329dabe13bf98b899b907b45565434c5140804f5 moved to “fetch”
> precisely so we could do shallow clones.

I don't know. It's definitely weird.
M
M
Maxim Cournoyer wrote on 30 Nov 2020 04:24
(name . Leo Famulari)(address . leo@famulari.name)
87sg8rmsrh.fsf@gmail.com
Hello,

Leo Famulari <leo@famulari.name> writes:

Toggle quote (7 lines)
> On Tue, Nov 03, 2020 at 10:48:25PM +0100, Ludovic Courtès wrote:
>> Weird, what’s the difference between fetch and clone technically? I
>> believe commit 329dabe13bf98b899b907b45565434c5140804f5 moved to “fetch”
>> precisely so we could do shallow clones.
>
> I don't know. It's definitely weird.

I had researched this before and the option the git server is missing is
uploadpack.allowAnySHA1InWant [0]. Unfortunately last I check in
#savannah their machine (vcs0) is using an older Trisquel stuck with git
v2.11.0, one patch version before when the above feature was introduced
(v2.11.1)! If I understood correctly, they have a new VM vcs2 but it
needs to be completely setup before they can switch.

Maxim

L
L
Leo Famulari wrote on 29 Dec 2021 23:45
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)
Yczk/260iDWR62SW@jasmine.lan
On Sun, Nov 29, 2020 at 10:24:18PM -0500, Maxim Cournoyer wrote:
Toggle quote (7 lines)
> I had researched this before and the option the git server is missing is
> uploadpack.allowAnySHA1InWant [0]. Unfortunately last I check in
> #savannah their machine (vcs0) is using an older Trisquel stuck with git
> v2.11.0, one patch version before when the above feature was introduced
> (v2.11.1)! If I understood correctly, they have a new VM vcs2 but it
> needs to be completely setup before they can switch.

Savannah is now using Git version 2.17.1. I wonder if we can have this
option enabled now? I checked and the problem described by this bug
still exists.
M
M
Maxim Cournoyer wrote on 2 Jan 2022 05:59
(name . Leo Famulari)(address . leo@famulari.name)
87lezyvikx.fsf@gmail.com
Hi Leo,

Leo Famulari <leo@famulari.name> writes:

Toggle quote (12 lines)
> On Sun, Nov 29, 2020 at 10:24:18PM -0500, Maxim Cournoyer wrote:
>> I had researched this before and the option the git server is missing is
>> uploadpack.allowAnySHA1InWant [0]. Unfortunately last I check in
>> #savannah their machine (vcs0) is using an older Trisquel stuck with git
>> v2.11.0, one patch version before when the above feature was introduced
>> (v2.11.1)! If I understood correctly, they have a new VM vcs2 but it
>> needs to be completely setup before they can switch.
>
> Savannah is now using Git version 2.17.1. I wonder if we can have this
> option enabled now? I checked and the problem described by this bug
> still exists.

You'd want to check in #savannah, I think. It'd help reduce bandwidth
and hasten 'guix pull' a bit if it were now possible, I think.

Thanks!

Maxim
?