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
?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 44382@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 44382
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch