Straight.el: Fatal error when remote does not support shallow cloning

Created on 3 Jun 2021  Â·  6Comments  Â·  Source: raxod502/straight.el

What's wrong

When performing a shallow clone of paredit (from the repo in its MELPA recipe: https://mumble.net/~campbell/git/paredit.git), I get this error:

$ git clone --origin origin --no-checkout https\://mumble.net/\~campbell/git/paredit.git /home/hlissner/.emacs.d/straight/repos/paredit/ --depth 1 --no-single-branch --no-tags

Cloning into '/home/hlissner/.emacs.d/straight/repos/paredit'...
fatal: dumb http transport does not support shallow capabilities

[Return code: 128]

The remote server does not support shallow cloning, it seems, which causes straight to abort with a fatal error.

Judging from straight-vc-git--clone-internal's docstring:

If DEPTH is an integer, pass it to the --depth option of git-clone to perform a shallow clone. If this fails, try again to clone without the option --depth and --branch, as a fallback.

It seems this should gracefully degrade to a full clone.

Directions to reproduce

Either:

  1. git clone --depth=1 https://mumble.net/~campbell/git/paredit.git

Or:

(setq straight-repository-branch "develop")
(defvar bootstrap-version)
(let ((bootstrap-file
       (expand-file-name "straight/repos/straight.el/bootstrap.el" user-emacs-directory))
      (bootstrap-version 5))
  (unless (file-exists-p bootstrap-file)
    (with-current-buffer
        (url-retrieve-synchronously
         "https://raw.githubusercontent.com/raxod502/straight.el/develop/install.el"
         'silent 'inhibit-cookies)
      (goto-char (point-max))
      (eval-print-last-sexp)))
  (load bootstrap-file nil 'nomessage))
(setq straight-vc-git-default-clone-depth 1)
(straight-use-package 'paredit)

Version information

  • Emacs version: 28.0.50
  • Operating system: NixOS 21.11
bug doom emacs git shallow clone vc

Most helpful comment

Can confirm this works perfectly now! Thank you for your work on straight and quick response!

All 6 comments

Thanks, Henrik.
Confimed with the following test case:

Test Case

(straight-bug-report
  :user-dir "paredit.straight"
  :post-bootstrap 
  (setq straight-vc-git-default-clone-depth 1)
  (straight-use-package 'paredit)
  (let
      ((default-directory
         (straight--repos-dir "paredit")))
    (message "paredit repo depth: %s"
             (straight--process-output "git" "rev-list" "HEAD" "--count"))))

  • Test run at: 2021-06-02 21:21:48
  • system-type: gnu/linux
  • straight-version: prerelease (HEAD -> fix/vc-git-clone-internal-recurse, fork/fix/vc-git-clone-internal-recurse) 00be648 2021-06-02
  • emacs-version: GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo version 1.17.4, Xaw3d scroll bars) of 2021-05-25

Output

Test run with version: prerelease (HEAD -> develop, origin/develop) 7ca94a7 2021-06-01
Cloning paredit...

Error: (error "Failed to run \"git\"; see buffer *straight-process*")

I've got a patch that seems to take care of it here:

Test Case

(straight-bug-report
  :user-dir "paredit.straight"
  :pre-bootstrap 
  (setq straight-repository-branch "fix/vc-git-clone-internal-recurse" straight-repository-user "progfolio")
  :post-bootstrap 
  (setq straight-vc-git-default-clone-depth 1)
  (straight-use-package 'paredit)
  (let
      ((default-directory
         (straight--repos-dir "paredit")))
    (message "paredit repo depth: %s"
             (straight--process-output "git" "rev-list" "HEAD" "--count"))))

  • Test run at: 2021-06-02 21:25:18
  • system-type: gnu/linux
  • straight-version: prerelease (HEAD -> fix/vc-git-clone-internal-recurse, fork/fix/vc-git-clone-internal-recurse) 00be648 2021-06-02
  • emacs-version: GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo version 1.17.4, Xaw3d scroll bars) of 2021-05-25

Output

Bootstrapping straight.el...
Bootstrapping straight.el...done
Rebuilding all packages due to build cache schema change
Looking for gnu-elpa-mirror recipe → Cloning melpa...
Looking for gnu-elpa-mirror recipe → Cloning melpa...done
Looking for emacsmirror-mirror recipe → Cloning gnu-elpa-mirror...
Looking for emacsmirror-mirror recipe → Cloning gnu-elpa-mirror...done
Looking for emacsmirror-mirror recipe → Cloning el-get...
Looking for emacsmirror-mirror recipe → Cloning el-get...done
Looking for straight recipe → Cloning emacsmirror-mirror...
Looking for straight recipe → Cloning emacsmirror-mirror...done
Building straight...
Building straight...done

Test run with version: prerelease (HEAD -> fix/vc-git-clone-internal-recurse, origin/fix/vc-git-clone-internal-recurse) 00be648 2021-06-02
Cloning paredit...
Cloning paredit...done
Building paredit...
Building paredit...done

paredit repo depth: 224
Packages:
"org-elpa"                n/a                  n/a
"melpa"                   n/a                  master 45a02d8e 2021-06-03
"gnu-elpa-mirror"         n/a                  master 6417888 2021-05-29
"el-get"                  melpa                master d76ac84a 2021-04-28
"emacsmirror-mirror"      n/a                  master a3cf645 2021-05-29
"straight"                n/a                  fix/vc-git-clone-internal-recurse 00be648 2021-06-02
"paredit"                 melpa                master 8330a41 2020-05-29


Should be fixed on latest "develop". Testing appreciated.

https://github.com/raxod502/straight.el/blob/e4349291d8b9e9d888bc384b68339456b18b59f3/straight.el#L2481

This line throws (wrong-type-argument . listp) since apply expects its final argument to be a list.

Same issue with nov - had to manually perform a non-shallow clone.

This line throws (wrong-type-argument . listp) since apply expects its final argument to be a list.

Oops. Should've caught that in #776. Thank you. Merged #779, which should fix this.

Can confirm this works perfectly now! Thank you for your work on straight and quick response!

Was this page helpful?
0 / 5 - 0 ratings

Related issues

eflanigan00 picture eflanigan00  Â·  4Comments

yqrashawn picture yqrashawn  Â·  3Comments

raxod502 picture raxod502  Â·  3Comments

Fuco1 picture Fuco1  Â·  3Comments

raxod502 picture raxod502  Â·  3Comments