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

[Stephen Leake]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Stephen Leake <stephen_leake@stephe-leake.org>
>> Cc: phillip.lord@russet.org.uk,  emacs-devel@gnu.org
>> Date: Sun, 24 Jan 2021 12:10:02 -0800
>> 
>> Do you agree that having one full copy of the ELPA repository in your
>> local emacs .git repository is acceptable?
>
> IMO, people who are interested only in packages bundled with Emacs
> should not need to have ELPA on their local machines.  Not even one
> checkout of ELPA should be needed.  They should just need to clone the
> Emacs Git repository (modulo the submodules-related options), and
> that's all.  Exactly like they do today: there's no need to clone ELPA
> to have a fully functional clone of the Emacs Git repository.

That is exactly what using submodules accomplishes.

But I'm not sure you've answered my question. Let me phrase it
differently:

Doing 'git clone <membername>@git.savannah.gnu.org:/srv/git/emacs.git'
results in disk space usage of around 300 MB in emacs/.git, and does not
populate emacs/elpa.

Doing 'git clone <membername>@git.savannah.gnu.org:/srv/git/emacs.git
--recurse-submodules' results in disk space usage of around 500 MB in
emacs/.git, and populates emacs/elpa.

If we implemented the suggestion to split the ELPA repository into one
repository per bundled package, that extra 200 MB would be smaller.

Is 200 MB acceptable?

>> For developers who also have elpa.git cloned separately, that's a
>> duplicate copy.
>
> Which it shouldn't be.

I agree it would be nice, but that's up to the git maintainers. Or we
could look for another CM tool ...

I can see some reasons for the current git design; _all_ of the info needed
to update the code for project foo is in foo/.git. Worktrees stretch
that; allowing submodules to be worktree-like references to yet another
repository somewhere else would probably break many things in git.

-- 
-- Stephe