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

[Eli Zaretskii <eliz@gnu.org>]

> From: Stephen Leake <stephen_leake@stephe-leake.org>
> Cc: phillip.lord@russet.org.uk,  emacs-devel@gnu.org
> Date: Wed, 27 Jan 2021 06:31:13 -0800
> 
> > 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.

Since Stefan says this is a non-starter, we can forget about this
alternative.

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

This could work, but we will have to arrange for some periodic job to
update the copies of the bundled packages frequently enough.

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

It will mean that people who use worktrees will have to find some way
of doing that, or give up worktrees.  But IMO the convenience of
bundling a package and handling such a bundled package trumps the
convenience of people who use worktrees a lot.