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

[Eli Zaretskii]

> From: Stephen Leake <stephen_leake@stephe-leake.org>
> Cc: phillip.lord@russet.org.uk,  emacs-devel@gnu.org
> Date: Mon, 25 Jan 2021 11:30:47 -0800
> 
> 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.

Where did emacs/elpa come from? I don't think we ever discussed such a
beast, and I don't understand what it is and what it will contain.

> 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?

That's a the question I can answer, because I have no clear idea what
is included in those 200MB, and in particular how much of that is
ballast we don't need for the purposes of maintaining Emacs and
building its development versions.  Maybe if you explained why
splitting ELPA into several repositories would save some of that disk
space, I could then try answering the question.

> 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.

I think we should first find a way to have a single worktree with all
the bundled packages that come from ELPA.  How to have several
worktrees from that is something we should consider later.