[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Andy Moreton
Subject: Re: [SPAM UNSURE] Re: policy discussion on bundling ELPA packages in the emacs tarball
Date: Tue, 26 Jan 2021 01:04:56 +0000
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (windows-nt)

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:


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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]