[Support]: Shallow cloning remotes

karthink commented 6 months ago

Confirmation

[X] I have checked the documentation (README, Wiki, docstrings, etc)
[ ] I am checking these without reading them.
[X] I have searched previous issues to see if my question is a duplicate.

Elpaca Version

Elpaca 3c1699a grafted, HEAD -> master, origin/master, origin/HEAD
installer:      0.7
emacs-version:  GNU Emacs 29.1 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo version 1.18.0, Xaw3d scroll bars)
git --version:  git version 2.42.0

Operating System

Linux, Emacs 29.2

Description

Hi @progfolio,

Does the :depth argument not apply to :remote specifications?

I tried the following to run a clean test in an Org branch:

;; -*- lexical-binding: t; -*-
(elpaca-test
  :name "org-9.7"
  :interactive t
  :early-init (setq elpaca-menu-functions nil)
  :init
  (elpaca (org
           :source "org"
           :protocol https
           :inherit t
           :depth 1
           :local-repo "org"
           :repo "https://git.savannah.gnu.org/git/emacs/org-mode.git"
           :pre-build (progn (require 'elpaca-menu-org) (elpaca-menu-org--build))
           :autoloads "org-loaddefs.el"
           :remotes ("tecosaur"
                     :repo "https://git.tecosaur.net/tec/org-mode.git"
                     :branch "dev"
                     :depth 1)          ; <---- SET DEPTH 1
           :files (:defaults "etc")
           :build (:not elpaca--generate-autoloads-async)
           :pin nil))
  (elpaca-wait))

This works fine, except that the value of :depth for the :remote specification is not being recognized. The original source is shallow cloned, but I get a full clone of the remote. Any idea what I'm doing wrong, or how to get a shallow clone of the remote as well?

progfolio commented 6 months ago

Hi @progfolio,

Hi! Thank you for the thorough test case.

Does the :depth argument not apply to :remotes specifications?

Currently it does not. elpaca--configure-remotes defers to elpaca--fetch when remotes are added. In turn, elpaca--fetch runs git fetch --all -v, which is where the rest of the history is being pulled in.

I had a note about making this more flexible in 154665145, but it seems I accidentally dropped during a refactoring. Long term, I'd like to think of a way to make all of the build commands more flexible, but I'm still experimenting with possible designs.

Any idea [...] how to get a shallow clone of the remote as well?

I've added a separate function to take the :remotes configuration into account during the initial fetch. Does the output of the following test case align with the behavior your had in mind?

Test Case

[How to run this test?](https://github.com/progfolio/elpaca/wiki/Troubleshooting#the-elpaca-test-macro) ```emacs-lisp (elpaca-test :name "org-9.7" :ref "fix/init-remotes" :early-init (setq elpaca-menu-functions nil) :init (elpaca (org :source "org" :protocol https :inherit t :depth 1 :local-repo "org" :repo "https://git.savannah.gnu.org/git/emacs/org-mode.git" :pre-build (progn (require 'elpaca-menu-org) (elpaca-menu-org--build)) :autoloads "org-loaddefs.el" :remotes ("tecosaur" :repo "https://git.tecosaur.net/tec/org-mode.git" :branch "dev" :depth 1) :files (:defaults "etc") :build (:not elpaca--generate-autoloads-async) :pin nil)) (elpaca-wait) (elpaca-with-dir 'org repo (message "%S" (elpaca-process-output "git" "log")) (message "%S" (elpaca-process-output "git" "log" "origin/main")))) ```

Host Env

elpaca	4f862ba HEAD -> fix/init-remotes, origin/fix/init-remotes
installer	0.7
emacs	GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.41, cairo version 1.18.0) of 2024-04-05
git	git version 2.44.0

Output

```emacs-lisp Elpaca menu item cache discarded due to version change. INFO Scraping files for loaddefs... INFO Scraping files for loaddefs...done GEN ../elpaca-autoloads.el Cloning into '/tmp/elpaca.8DvUQr/elpaca/repos/elpaca'... Switched to a new branch 'fix/init-remotes' branch 'fix/init-remotes' set up to track 'origin/fix/init-remotes'. Checking /tmp/elpaca.8DvUQr/elpaca/repos/elpaca... Compiling /tmp/elpaca.8DvUQr/elpaca/repos/elpaca/elpaca-info.el... Compiling /tmp/elpaca.8DvUQr/elpaca/repos/elpaca/elpaca-log.el... Compiling /tmp/elpaca.8DvUQr/elpaca/repos/elpaca/elpaca-manager.el... Compiling /tmp/elpaca.8DvUQr/elpaca/repos/elpaca/elpaca-menu-elpa.el... Compiling /tmp/elpaca.8DvUQr/elpaca/repos/elpaca/elpaca-menu-melpa.el... Compiling /tmp/elpaca.8DvUQr/elpaca/repos/elpaca/elpaca-menu-org.el... Compiling /tmp/elpaca.8DvUQr/elpaca/repos/elpaca/elpaca-process.el... Compiling /tmp/elpaca.8DvUQr/elpaca/repos/elpaca/elpaca-test.el... Compiling /tmp/elpaca.8DvUQr/elpaca/repos/elpaca/elpaca-ui.el... Compiling /tmp/elpaca.8DvUQr/elpaca/repos/elpaca/elpaca.el... Checking /tmp/elpaca.8DvUQr/elpaca/repos/elpaca/doc... Compiling /tmp/elpaca.8DvUQr/elpaca/repos/elpaca/doc/early-init.el... Compiling /tmp/elpaca.8DvUQr/elpaca/repos/elpaca/doc/init.el... Checking /tmp/elpaca.8DvUQr/elpaca/repos/elpaca/extensions... Compiling /tmp/elpaca.8DvUQr/elpaca/repos/elpaca/extensions/elpaca-use-package.el... Checking /tmp/elpaca.8DvUQr/elpaca/repos/elpaca/images... Checking /tmp/elpaca.8DvUQr/elpaca/repos/elpaca/test... Compiling /tmp/elpaca.8DvUQr/elpaca/repos/elpaca/test/elpaca-test.el... Compiling /tmp/elpaca.8DvUQr/elpaca/repos/elpaca/test/elpaca-tests.el... Done (Total of 11 files compiled, 4 skipped in 4 directories) "commit 8f1d75ae1b2f3a3134f3ecdd6562d97fdd70fb77 Author: TEC Date: Sun Jan 7 19:03:04 2024 +0800 ---END PERSONAL NOPUSH DIVIDER--- -- 2.42.0 " "commit 1ae978f940c0f88473f2232177c63a0de7fb7a1c Author: Ihor Radchenko Date: Mon Apr 15 14:19:50 2024 +0300 Merge branch 'bugfix' " Test Env Elpaca 4f862ba grafted, HEAD -> fix/init-remotes, origin/fix/init-remotes installer: 0.7 emacs-version: GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.41, cairo version 1.18.0) of 2024-04-05 git --version: git version 2.44.0 ```

karthink commented 6 months ago

Yup! This works perfectly. (The :ref fix/init-remotes part really threw me off until I realized that's the version of elpaca being fetched, and it has nothing to do with the recipe.)

progfolio commented 6 months ago

Yup! This works perfectly.

Glad to hear it. Merged into master.

The :ref fix/init-remotes part really threw me off until I realized that's the version of elpaca being fetched, and it has nothing to do with the recipe.

It's a good way to hack on Elpaca itself :) There's also :ref local to bypass the network and install your local version in a temp environment.

karthink commented 1 month ago

Yup! This works perfectly. (The :ref fix/init-remotes part really threw me off until I realized that's the version of elpaca being fetched, and it has nothing to do with the recipe.)

@progfolio this keeps tripping me up, since I forget this between uses of elpaca-test. Do you think you could change the documentation of elpaca-test from

  :ref git ref to check out or ‘local’ to use local copy in current repo state

  :depth number of Elpaca repository commits to clone

to

  :ref git ref of Elpaca repository to check out or ‘local’ to use local copy in current repo state

  :depth number of Elpaca repository commits to clone

progfolio commented 1 month ago

Yup! This works perfectly. (The :ref fix/init-remotes part really threw me off until I realized that's the version of elpaca being fetched, and it has nothing to do with the recipe.)

@progfolio this keeps tripping me up, since I forget this between uses of elpaca-test. Do you think you could change the documentation of elpaca-test from
  :ref git ref to check out or ‘local’ to use local copy in current repo state

  :depth number of Elpaca repository commits to clone
to
  :ref git ref of Elpaca repository to check out or ‘local’ to use local copy in current repo state

  :depth number of Elpaca repository commits to clone

Done on master. Thank you

progfolio / elpaca