[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: policy discussion on bundling ELPA packages in the emacs tarball

From: Stephen Leake
Subject: Re: policy discussion on bundling ELPA packages in the emacs tarball
Date: Sat, 23 Jan 2021 01:27:15 -0800
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (windows-nt)

Stephen Leake <stephen_leake@stephe-leake.org> writes:

> I'll have to test some stuff. If the submodules cannot be worktrees,
> then I think we have to abandon this approach. Although maybe using
> --depth=1 (or some small number) would be acceptable.

I've played with 'git submodules' on Windows mingw64. You can pass a
local ELPA repository to 'git submodules add', but it copies the whole
thing into the emacs repository:

$git submodule add /c/Projects/elpa/.git packages/ada-mode
Cloning into 

(I should have left out the 'packages/')

The copied repostory is in
and is 237 MB (all of ELPA).

There is not a way to specify the branch in the 'git submodule add'
command, but we can do a 'git checkout external/packages/ada-mode' in
the submodule root to get the right files.

However, this will copy all of elpa.git for _each_ bundled package;
clearly not acceptable.

An alternative is to use worktrees from a local elpa.git. This is what
ELPA does now for packages/*. There is elisp code to manage the
worktrees in elpa/admin/elpa-admin.el - see elpaa--worktree-sync for
example. We could reuse that code; we just have to add an arg for the
root directory name (emacs/elpa instead of elpa/packages).

With worktrees, we don't have git commands that operate on all the
bundled packages at once, as 'git submodules ...' does. However, we'll
be using an emacs front-end for edit/push/pull anyway. We may want to
customize our favorite front-end to do them all at once; at least report
changes in those directories so we know to visit them. At the very
least, we'll want a shell script that runs 'git status' in each bundled

-- Stephe

reply via email to

[Prev in Thread] Current Thread [Next in Thread]