bug#33100: [libssh] fatal: dumb http transport does not support shallow capabilities

bug#33100: [libssh] fatal: dumb http transport does not support shallow capabilities

[Maxim Cournoyer]

Hello,

Today I stumbled upon libssh that wouldn't build, due to the following
git error:

--8<---------------cut here---------------start------------->8---
fatal: dumb http transport does not support shallow capabilities"
--8<---------------cut here---------------end--------------->8---

There are now substitutes served from Berlin, so it's a bit more
difficult to reproduce, but the following worked for Ludovic and myself:

guix build --check /gnu/store/f0i7bdcg1lksr9dhz0cidi3ym8r8a5wl-libssh-0.7.6-checkout.drv

The output looks like:

--8<---------------cut here---------------start------------->8---
guix build --check /gnu/store/f0i7bdcg1lksr9dhz0cidi3ym8r8a5wl-libssh-0.7.6-checkout.drv
building /gnu/store/f0i7bdcg1lksr9dhz0cidi3ym8r8a5wl-libssh-0.7.6-checkout.drv...
Initialized empty Git repository in /gnu/store/gqyjgpvzqy55dzibm59530fsx21dpiz4-libssh-0.7.6-checkout/.git/
fatal: dumb http transport does not support shallow capabilities
--8<---------------cut here---------------end--------------->8---

Leo, would you have an idea?

Thanks,

Maxim

bug#33100: [libssh] fatal: dumb http transport does not support shallow capabilities

[Ludovic Courtès]

Hello!

Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:

> guix build --check /gnu/store/f0i7bdcg1lksr9dhz0cidi3ym8r8a5wl-libssh-0.7.6-checkout.drv
> building /gnu/store/f0i7bdcg1lksr9dhz0cidi3ym8r8a5wl-libssh-0.7.6-checkout.drv...
> Initialized empty Git repository in /gnu/store/gqyjgpvzqy55dzibm59530fsx21dpiz4-libssh-0.7.6-checkout/.git/
> fatal: dumb http transport does not support shallow capabilities

On closer inspection, it seems that there’s nothing “fatal” here: if you
let it run for a while (1 or 2 minutes), it ends up silently cloning the
whole repo and the derivation build eventually succeeds.

Could you check if that’s the case for you?

berlin.guixsd.org has a substitute for this checkout, which suggests it
went fine there.

Thanks,
Ludo’.

bug#33100: [libssh] fatal: dumb http transport does not support shallow capabilities

[Maxim Cournoyer]

Hi,

ludo@gnu.org (Ludovic Courtès) writes:

> Hello!
>
> Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:
>
>> guix build --check /gnu/store/f0i7bdcg1lksr9dhz0cidi3ym8r8a5wl-libssh-0.7.6-checkout.drv
>> building /gnu/store/f0i7bdcg1lksr9dhz0cidi3ym8r8a5wl-libssh-0.7.6-checkout.drv...
>> Initialized empty Git repository in /gnu/store/gqyjgpvzqy55dzibm59530fsx21dpiz4-libssh-0.7.6-checkout/.git/
>> fatal: dumb http transport does not support shallow capabilities
>
> On closer inspection, it seems that there’s nothing “fatal” here: if you
> let it run for a while (1 or 2 minutes), it ends up silently cloning the
> whole repo and the derivation build eventually succeeds.

It did end up working fine, although it took a large amout of time for
doing what seems to be a checkout (4 min 46 s). I did some experiments
and this is really the time it took to do a full clone of the libssh
project.

--8<---------------cut here---------------start------------->8---
time git clone git://git.libssh.org/projects/libssh.git libssh
Cloning into 'libssh'...
remote: Enumerating objects: 28264, done.
remote: Counting objects: 100% (28264/28264), done.
remote: Compressing objects: 100% (11718/11718), done.
remote: Total 28264 (delta 20985), reused 21830 (delta 16350)s    
Receiving objects: 100% (28264/28264), 5.21 MiB | 263.00 KiB/s, done.
Resolving deltas: 100% (20985/20985), done.

real    4m19.419s
user    0m3.272s
sys     0m0.540s
--8<---------------cut here---------------end--------------->8---

It's a bit of a shame, given that the shallow clone takes about 2
seconds (!):

--8<---------------cut here---------------start------------->8---
time git clone --depth 1 git://git.libssh.org/projects/libssh.git libssh
Cloning into 'libssh'...
remote: Enumerating objects: 367, done.
remote: Counting objects: 100% (367/367), done.
remote: Compressing objects: 100% (358/358), done.
remote: Total 367 (delta 39), reused 53 (delta 1)
Receiving objects: 100% (367/367), 704.23 KiB | 728.00 KiB/s, done.
Resolving deltas: 100% (39/39), done.

real    0m2.028s
user    0m0.160s
sys     0m0.071s
--8<---------------cut here---------------end--------------->8---

Based on the discussion here:
https://github.com/CocoaPods/CocoaPods/issues/6270, it would seem this
means that the libssh git server doesn't support the newer "smart HTTP
transport" and the git client bails out (IIUC). At least in our case the
guile-ssh library seems to already correctly fallback to doing a full
clone.

Perhaps just clearer messages would have helped here also ('Failed to do
a shallow git clone due to ~error message~, falling back to a full clone').

Such a change would need to be made in guile-git IIUC.

I'll close this bug now; thank you!

Maxim

bug#33100: [libssh] fatal: dumb http transport does not support shallow capabilities

[Leo Famulari]

[-- Attachment #1: Type: text/plain, Size: 1089 bytes --]

On Sat, Oct 20, 2018 at 11:24:24PM -0400, Maxim Cournoyer wrote:
> ludo@gnu.org (Ludovic Courtès) writes:
> > On closer inspection, it seems that there’s nothing “fatal” here: if you
> > let it run for a while (1 or 2 minutes), it ends up silently cloning the
> > whole repo and the derivation build eventually succeeds.
> 
> It did end up working fine, although it took a large amout of time for
> doing what seems to be a checkout (4 min 46 s). I did some experiments
> and this is really the time it took to do a full clone of the libssh
> project.

Great, you figured it out :)

More explanation:

Git has a few different server protocols: git, dumb HTTP, smart HTTP,
and SSH:

https://git-scm.com/book/en/v2/Git-on-the-Server-The-Protocols

The dumb HTTP protocol is slow and does not show any progress status or
other informative message while it works, but if you monitor your
network traffic you can see it working.

For obvious reasons, it's rare to see the dumb HTTP protocol deployed
nowadays, but you may still find it on legacy installations.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

bug#33100: [libssh] fatal: dumb http transport does not support shallow capabilities

[Maxim Cournoyer]

Hello Leo,

Leo Famulari <leo@famulari.name> writes:

> On Sat, Oct 20, 2018 at 11:24:24PM -0400, Maxim Cournoyer wrote:
>> ludo@gnu.org (Ludovic Courtès) writes:
>> > On closer inspection, it seems that there’s nothing “fatal” here: if you
>> > let it run for a while (1 or 2 minutes), it ends up silently cloning the
>> > whole repo and the derivation build eventually succeeds.
>> 
>> It did end up working fine, although it took a large amout of time for
>> doing what seems to be a checkout (4 min 46 s). I did some experiments
>> and this is really the time it took to do a full clone of the libssh
>> project.
>
> Great, you figured it out :)
>
> More explanation:
>
> Git has a few different server protocols: git, dumb HTTP, smart HTTP,
> and SSH:
>
> https://git-scm.com/book/en/v2/Git-on-the-Server-The-Protocols
>
> The dumb HTTP protocol is slow and does not show any progress status or
> other informative message while it works, but if you monitor your
> network traffic you can see it working.
>
> For obvious reasons, it's rare to see the dumb HTTP protocol deployed
> nowadays, but you may still find it on legacy installations.

Thanks for the extra bits of information :)

Cheers,

Maxim

bug#33100: [libssh] fatal: dumb http transport does not support shallow capabilities

[Ludovic Courtès]

Hello,

Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:
> It did end up working fine, although it took a large amout of time for
> doing what seems to be a checkout (4 min 46 s). I did some experiments
> and this is really the time it took to do a full clone of the libssh
> project.
>
> time git clone git://git.libssh.org/projects/libssh.git libssh
> Cloning into 'libssh'...
> remote: Enumerating objects: 28264, done.
> remote: Counting objects: 100% (28264/28264), done.
> remote: Compressing objects: 100% (11718/11718), done.
> remote: Total 28264 (delta 20985), reused 21830 (delta 16350)s    
> Receiving objects: 100% (28264/28264), 5.21 MiB | 263.00 KiB/s, done.
> Resolving deltas: 100% (20985/20985), done.
>
> real    4m19.419s
> user    0m3.272s
> sys     0m0.540s
>
>
> It's a bit of a shame, given that the shallow clone takes about 2
> seconds (!):
>
> time git clone --depth 1 git://git.libssh.org/projects/libssh.git libssh
> Cloning into 'libssh'...
> remote: Enumerating objects: 367, done.
> remote: Counting objects: 100% (367/367), done.
> remote: Compressing objects: 100% (358/358), done.
> remote: Total 367 (delta 39), reused 53 (delta 1)
> Receiving objects: 100% (367/367), 704.23 KiB | 728.00 KiB/s, done.
> Resolving deltas: 100% (39/39), done.
>
> real    0m2.028s
> user    0m0.160s
> sys     0m0.071s
>
> Based on the discussion here:
> https://github.com/CocoaPods/CocoaPods/issues/6270, it would seem this
> means that the libssh git server doesn't support the newer "smart HTTP
> transport" and the git client bails out (IIUC). At least in our case the
> guile-ssh library seems to already correctly fallback to doing a full
> clone.

Switching to the git:// transport would seem like a reasonable
workaround—we’d lose encryption and authentication, but the latter is
covered by the content hash in the ‘origin’ anyway.

WDYT, Leo?

> Perhaps just clearer messages would have helped here also ('Failed to do
> a shallow git clone due to ~error message~, falling back to a full clone').

I agree, and that’s something to suggest to the Git folks.  :-)

Thanks,
Ludo’.

bug#33100: [libssh] fatal: dumb http transport does not support shallow capabilities

[Leo Famulari]

[-- Attachment #1.1: Type: text/plain, Size: 1198 bytes --]

On Mon, Oct 22, 2018 at 11:55:26AM +0200, Ludovic Courtès wrote:
> Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:
> > It did end up working fine, although it took a large amout of time for
> > doing what seems to be a checkout (4 min 46 s). I did some experiments
> > and this is really the time it took to do a full clone of the libssh
> > project.

[...]

> > It's a bit of a shame, given that the shallow clone takes about 2
> > seconds (!):

Yeah, it's incredibly slow. The repo is not even 10 MB. At first, I too
thought the HTTPS clone had stalled.

Protocol	duration
------------------------
https:// 	217 sec
git://		10 sec
git:// shallow 	1.5 sec

And of course, the shallow clone is 3.6 MB instead of 10 MB.

> Switching to the git:// transport would seem like a reasonable
> workaround—we’d lose encryption and authentication, but the latter is
> covered by the content hash in the ‘origin’ anyway.
> 
> WDYT, Leo?

Overall, I think the slowness doesn't matter too much, since we offer
substitutes for the patched source code. However, here is a patch.
Please feel free to apply it!

I'll ask the libssh team to support "smart" HTTP Git.

[-- Attachment #1.2: 0001-gnu-libssh-Fetch-the-source-code-more-efficiently.patch --]
[-- Type: text/plain, Size: 1524 bytes --]

From 683713dd8f5d67e3f077d5d13c23e5556d8ad779 Mon Sep 17 00:00:00 2001
From: Leo Famulari <leo@famulari.name>
Date: Mon, 22 Oct 2018 13:00:55 -0400
Subject: [PATCH] gnu: libssh: Fetch the source code more efficiently.

* gnu/packages/ssh.scm (libssh)[source]: Use the git:// protocol.
---
 gnu/packages/ssh.scm | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/gnu/packages/ssh.scm b/gnu/packages/ssh.scm
index e806fc80f..b93cb03a1 100644
--- a/gnu/packages/ssh.scm
+++ b/gnu/packages/ssh.scm
@@ -71,8 +71,14 @@
     (source (origin
               (method git-fetch)
               (uri (git-reference
-                    (url "https://git.libssh.org/projects/libssh.git")
-                    (commit (string-append "libssh-" version))))
+                     ;; git.libssh.org does not support the fast "smart" HTTP
+                     ;; Git protocol. The "dumb" HTTP Git protocol is extremely
+                     ;; slow, and does not support shallow clones, so we use the
+                     ;; plain Git protocol despite its flaws. This offers an
+                     ;; incredible speedup and reduces the size of the the
+                     ;; source by more than half.
+                     (url "git://git.libssh.org/projects/libssh.git")
+                     (commit (string-append "libssh-" version))))
               (patches (search-patches "libssh-hostname-parser-bug.patch"))
               (sha256
                (base32
-- 
2.19.1


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

bug#33100: [libssh] fatal: dumb http transport does not support shallow capabilities

[Maxim Cournoyer]

[-- Attachment #1: Type: text/plain, Size: 512 bytes --]

Hi Ludovic,

ludo@gnu.org (Ludovic Courtès) writes:

[...]

>> Perhaps just clearer messages would have helped here also ('Failed to do
>> a shallow git clone due to ~error message~, falling back to a full clone').
>
> I agree, and that’s something to suggest to the Git folks.  :-)

Upon further inspection, we can do better on our side, specifically by
printing a message of the fallback occurring when calling git-fetch. The
patch below implements this simple change.

What do you think?


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-build-git-fetch-Print-message-when-falling-back-to-a.patch --]
[-- Type: text/x-patch, Size: 1130 bytes --]

From 06ba66d1949ba59573518f471ad3cbacefea6ea2 Mon Sep 17 00:00:00 2001
From: Maxim Cournoyer <maxim.cournoyer@gmail.com>
Date: Wed, 24 Oct 2018 08:49:50 -0400
Subject: [PATCH] build: git-fetch: Print message when falling back to a full
 checkout.

Otherwise the user might believe that git-fetch stalled, observing the lack of
output following a 'fatal' git error message (see:
https://debbugs.gnu.org/33100).

* guix/build/git.scm (git-fetch): Print message when falling back to a full
checkout.
---
 guix/build/git.scm | 1 +
 1 file changed, 1 insertion(+)

diff --git a/guix/build/git.scm b/guix/build/git.scm
index 14d415a6f..df8f1548b 100644
--- a/guix/build/git.scm
+++ b/guix/build/git.scm
@@ -45,6 +45,7 @@ recursively.  Return #t on success, #f otherwise."
     (if (zero? (system* git-command "fetch" "--depth" "1" "origin" commit))
         (invoke git-command "checkout" "FETCH_HEAD")
         (begin
+          (format #t "Failed to do a shallow fetch; retrying a full fetch...~%")
           (invoke git-command "fetch" "origin")
           (invoke git-command "checkout" commit)))
     (when recursive?
-- 
2.19.0


[-- Attachment #3: Type: text/plain, Size: 7 bytes --]


Maxim

bug#33100: [libssh] fatal: dumb http transport does not support shallow capabilities

[Ludovic Courtès]

Hi,

Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:

> Upon further inspection, we can do better on our side, specifically by
> printing a message of the fallback occurring when calling git-fetch. The
> patch below implements this simple change.
>
> What do you think?
>
> From 06ba66d1949ba59573518f471ad3cbacefea6ea2 Mon Sep 17 00:00:00 2001
> From: Maxim Cournoyer <maxim.cournoyer@gmail.com>
> Date: Wed, 24 Oct 2018 08:49:50 -0400
> Subject: [PATCH] build: git-fetch: Print message when falling back to a full
>  checkout.
>
> Otherwise the user might believe that git-fetch stalled, observing the lack of
> output following a 'fatal' git error message (see:
> https://debbugs.gnu.org/33100).
>
> * guix/build/git.scm (git-fetch): Print message when falling back to a full
> checkout.

Oh indeed, I had overlooked that.

Go for it!

Thanks,
Ludo’.

bug#33100: [libssh] fatal: dumb http transport does not support shallow capabilities

[Leo Famulari]

[-- Attachment #1: Type: text/plain, Size: 755 bytes --]

On Wed, Oct 24, 2018 at 09:01:07AM -0400, Maxim Cournoyer wrote:
> From 06ba66d1949ba59573518f471ad3cbacefea6ea2 Mon Sep 17 00:00:00 2001
> From: Maxim Cournoyer <maxim.cournoyer@gmail.com>
> Date: Wed, 24 Oct 2018 08:49:50 -0400
> Subject: [PATCH] build: git-fetch: Print message when falling back to a full
>  checkout.
> 
> Otherwise the user might believe that git-fetch stalled, observing the lack of
> output following a 'fatal' git error message (see:
> https://debbugs.gnu.org/33100).
> 
> * guix/build/git.scm (git-fetch): Print message when falling back to a full
> checkout.

I like it, but it doesn't seem to actually print anything for me when I
trigger the failing case, for example by fetching the libssh source over
HTTP.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

bug#33100: [libssh] fatal: dumb http transport does not support shallow capabilities

[Ludovic Courtès]

Leo Famulari <leo@famulari.name> skribis:

> On Wed, Oct 24, 2018 at 09:01:07AM -0400, Maxim Cournoyer wrote:
>> From 06ba66d1949ba59573518f471ad3cbacefea6ea2 Mon Sep 17 00:00:00 2001
>> From: Maxim Cournoyer <maxim.cournoyer@gmail.com>
>> Date: Wed, 24 Oct 2018 08:49:50 -0400
>> Subject: [PATCH] build: git-fetch: Print message when falling back to a full
>>  checkout.
>> 
>> Otherwise the user might believe that git-fetch stalled, observing the lack of
>> output following a 'fatal' git error message (see:
>> https://debbugs.gnu.org/33100).
>> 
>> * guix/build/git.scm (git-fetch): Print message when falling back to a full
>> checkout.
>
> I like it, but it doesn't seem to actually print anything for me when I
> trigger the failing case, for example by fetching the libssh source over
> HTTP.

If might be that current-output-port is fully buffered.  What if you
add:

  (setvbuf (current-output-port) 'line)

before the ‘format’ call?

Thanks,
Ludo’, who is found guilty of not actually running the code.

bug#33100: [libssh] fatal: dumb http transport does not support shallow capabilities

[Leo Famulari]

On Wed, Oct 24, 2018 at 11:33:03PM +0200, Ludovic Courtès wrote:
> If might be that current-output-port is fully buffered.  What if you
> add:
> 
>   (setvbuf (current-output-port) 'line)
> 
> before the ‘format’ call?

Yeah, this lets' the message through.

bug#33100: [libssh] fatal: dumb http transport does not support shallow capabilities

[Maxim Cournoyer]

ludo@gnu.org (Ludovic Courtès) writes:

> Leo Famulari <leo@famulari.name> skribis:
>
>> On Wed, Oct 24, 2018 at 09:01:07AM -0400, Maxim Cournoyer wrote:
>>> From 06ba66d1949ba59573518f471ad3cbacefea6ea2 Mon Sep 17 00:00:00 2001
>>> From: Maxim Cournoyer <maxim.cournoyer@gmail.com>
>>> Date: Wed, 24 Oct 2018 08:49:50 -0400
>>> Subject: [PATCH] build: git-fetch: Print message when falling back to a full
>>>  checkout.
>>> 
>>> Otherwise the user might believe that git-fetch stalled, observing the lack of
>>> output following a 'fatal' git error message (see:
>>> https://debbugs.gnu.org/33100).
>>> 
>>> * guix/build/git.scm (git-fetch): Print message when falling back to a full
>>> checkout.
>>
>> I like it, but it doesn't seem to actually print anything for me when I
>> trigger the failing case, for example by fetching the libssh source over
>> HTTP.
>
> If might be that current-output-port is fully buffered.  What if you
> add:
>
>   (setvbuf (current-output-port) 'line)
>
> before the ‘format’ call?
>
> Thanks,
> Ludo’, who is found guilty of not actually running the code.

What is preferable, between your solution or using (force-output)?

I'll send a revised patch accordingly.

Thank you,

Maxim

bug#33100: [libssh] fatal: dumb http transport does not support shallow capabilities

[Ludovic Courtès]

Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:

> ludo@gnu.org (Ludovic Courtès) writes:
>
>> Leo Famulari <leo@famulari.name> skribis:
>>
>>> On Wed, Oct 24, 2018 at 09:01:07AM -0400, Maxim Cournoyer wrote:
>>>> From 06ba66d1949ba59573518f471ad3cbacefea6ea2 Mon Sep 17 00:00:00 2001
>>>> From: Maxim Cournoyer <maxim.cournoyer@gmail.com>
>>>> Date: Wed, 24 Oct 2018 08:49:50 -0400
>>>> Subject: [PATCH] build: git-fetch: Print message when falling back to a full
>>>>  checkout.
>>>> 
>>>> Otherwise the user might believe that git-fetch stalled, observing the lack of
>>>> output following a 'fatal' git error message (see:
>>>> https://debbugs.gnu.org/33100).
>>>> 
>>>> * guix/build/git.scm (git-fetch): Print message when falling back to a full
>>>> checkout.
>>>
>>> I like it, but it doesn't seem to actually print anything for me when I
>>> trigger the failing case, for example by fetching the libssh source over
>>> HTTP.
>>
>> If might be that current-output-port is fully buffered.  What if you
>> add:
>>
>>   (setvbuf (current-output-port) 'line)
>>
>> before the ‘format’ call?
>>
>> Thanks,
>> Ludo’, who is found guilty of not actually running the code.
>
> What is preferable, between your solution or using (force-output)?

I’d go for line buffering since you only need to do it once for all.

Thanks!
Ludo’.

bug#33100: [libssh] fatal: dumb http transport does not support shallow capabilities

[Maxim Cournoyer]

[-- Attachment #1: Type: text/plain, Size: 823 bytes --]

Hello!

ludo@gnu.org (Ludovic Courtès) writes:

>>>> I like it, but it doesn't seem to actually print anything for me when I
>>>> trigger the failing case, for example by fetching the libssh source over
>>>> HTTP.
>>>
>>> If might be that current-output-port is fully buffered.  What if you
>>> add:
>>>
>>>   (setvbuf (current-output-port) 'line)
>>>
>>> before the ‘format’ call?
>>>
>>> Thanks,
>>> Ludo’, who is found guilty of not actually running the code.
>>
>> What is preferable, between your solution or using (force-output)?
>
> I’d go for line buffering since you only need to do it once for all.

I finally got around to reproducing the problem and testing the fix; it
was costly to build using --no-substitutes.

Is it OK to push this patch into master?

Thanks,

Maxim

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-git-download-Print-a-message-when-falling-back-to-a-.patch --]
[-- Type: text/x-patch, Size: 1173 bytes --]

From 44782db3f63a29cdbd98cddb77eab8a473806765 Mon Sep 17 00:00:00 2001
From: Maxim Cournoyer <maxim.cournoyer@gmail.com>
Date: Wed, 24 Oct 2018 08:49:50 -0400
Subject: [PATCH] git-download: Print a message when falling back to a full
 fetch.

Otherwise the user might believe that git-fetch stalled, observing the lack of
output following a 'fatal' git error message (see:
https://debbugs.gnu.org/33100).

* guix/build/git.scm (git-fetch): Print message when falling back to a full
fetch.
---
 guix/build/git.scm | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/guix/build/git.scm b/guix/build/git.scm
index 14d415a6f..2d1700a9b 100644
--- a/guix/build/git.scm
+++ b/guix/build/git.scm
@@ -45,6 +45,8 @@ recursively.  Return #t on success, #f otherwise."
     (if (zero? (system* git-command "fetch" "--depth" "1" "origin" commit))
         (invoke git-command "checkout" "FETCH_HEAD")
         (begin
+          (setvbuf (current-output-port) 'line)
+          (format #t "Failed to do a shallow fetch; retrying a full fetch...~%")
           (invoke git-command "fetch" "origin")
           (invoke git-command "checkout" commit)))
     (when recursive?
-- 
2.19.0

bug#33100: [libssh] fatal: dumb http transport does not support shallow capabilities

[Ludovic Courtès]

Hi Maxim,

Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:

> ludo@gnu.org (Ludovic Courtès) writes:
>
>>>>> I like it, but it doesn't seem to actually print anything for me when I
>>>>> trigger the failing case, for example by fetching the libssh source over
>>>>> HTTP.
>>>>
>>>> If might be that current-output-port is fully buffered.  What if you
>>>> add:
>>>>
>>>>   (setvbuf (current-output-port) 'line)
>>>>
>>>> before the ‘format’ call?
>>>>
>>>> Thanks,
>>>> Ludo’, who is found guilty of not actually running the code.
>>>
>>> What is preferable, between your solution or using (force-output)?
>>
>> I’d go for line buffering since you only need to do it once for all.
>
> I finally got around to reproducing the problem and testing the fix; it
> was costly to build using --no-substitutes.
>
> Is it OK to push this patch into master?

Definitely, thank you!

Ludo’.

bug#33100: [libssh] fatal: dumb http transport does not support shallow capabilities

[Maxim Cournoyer]

Hello,

ludo@gnu.org (Ludovic Courtès) writes:

[...]

>> Is it OK to push this patch into master?
>
> Definitely, thank you!
>
> Ludo’.

Pushed as commit 2f18b7329! Thank you,

Maxim