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

[Stephen Leake]

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 
'/c/Projects/emacs/feature/core-elpa-by-copy/elpa/packages/ada-mode'...
done.

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

The copied repostory is in
/c/Projects/emacs/master/.git/worktrees/core-elpa-by-copy/modules/elpa/packages/ada-mode
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
package.

-- 
-- Stephe