Re: [SPAM UNSURE] Re: policy discussion on bundling ELPA packages in the emacs tarball

[Andy Moreton]

On Mon 25 Jan 2021, Stefan Monnier wrote:

> I don't have a strong opinion over using worktrees or submodules or
> what, but I think we should first clarify whether we intend to bundle
> *all* GNU ELPA packages or only some of them.
>
> And then whether we want to keep the code (for those GNU ELPA packages
> we want to bundle) exclusively in elpa.git.
>
> I think we'll only want to bundle a few specific packages, and I think
> it might be simpler to keep a copy of those specific packages in
> emacs.git (in the form of branches, of course: we want to be able to
> easily sync those copies with the ones in elpa.git).

I agree that only keeping copies of packages that are actually bundled
with emacs is preferable.

> One advantage is that cloning emacs.git would get us all the data we
> need (no need to refer to some other Git repository).
> Another is that this will only get the subset of GNU ELPA which we
> intend to bundle, so its size won't grow quite like that of `elpa.git`.
> Also it naturally gives us separate release branches that can evolve
> at a slightly different rate than the code in elpa.git, without having
> to touch elpa.git itself.

Another possibility is git subtrees:

https://github.com/git/git/blob/master/contrib/subtree/git-subtree.txt

This keeps a copy of the files from a project plus enough metadata to
allow normal commits in the subtree and merging changes back into their
upstream origin.

However a downside I have observed with a repo using git subtree is that
'git log' is not yet clever enough to follow the history of files in the
subtree properly (although 'git blame' works).

    AndyM