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

[Stephen Leake <stephen_leake@stephe-leake.org>]

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

emacs/elpa is the directory in the emacs directory tree where bundled
elpa packages are kept.

I agree this is confusing; I need to write up a new baseline description.

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

Some of it is ballast, yes; all of the ELPA packages that are not
bundled with emacs.

> Maybe if you explained why splitting ELPA into several repositories
> would save some of that disk space, I could then try answering the
> question.

Gnu ELPA is currently a single repository with lots of branches, one
branch per package.

git submodule downloads the entire repository, even if you only want one
branch.

So one way to eliminate the ballast is to split Gnu ELPA into one
repository per package; then git submodule will only download the
repository for that package.

Stefan's suggestion eliminates the ballast in a different way; by keeping
the release branches of bundled packages in emacs.git, there is no
ballast in the local emacs repository.

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

I don't think we can leave it until later; if we choose a design that
explicitly prohibits worktrees, there is nothing that can be done later.

-- 
-- Stephe