[Top][All Lists]

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

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

From: Stephen Leake
Subject: Re: policy discussion on bundling ELPA packages in the emacs tarball
Date: Sun, 24 Jan 2021 09:30:35 -0800
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (windows-nt)

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Stephen Leake <stephen_leake@stephe-leake.org>
>> Date: Sat, 23 Jan 2021 01:27:15 -0800
>> Cc: emacs-devel <emacs-devel@gnu.org>
>> Stephen Leake <stephen_leake@stephe-leake.org> writes:
>> > I'll have to test some stuff. If the submodules cannot be worktrees,
>> > then I think we have to abandon this approach. Although maybe using
>> > --depth=1 (or some small number) would be acceptable.
>> I've played with 'git submodules' on Windows mingw64. You can pass a
>> local ELPA repository to 'git submodules add', but it copies the whole
>> thing into the emacs repository:
> It is quite clear that ELPA will need some changes on its side to
> support this integration.  One such change is to have branches that
> roughly correspond to Emacs's 'master' and 'release' branches, because
> we would want to have only the stable branches of the ELPA packages to
> be visible on the Emacs's release branch.


However, I don't see how that affects my point, which was that 'git add
submodule' appears to copy the entire ELPA repository for each bundled

This is on Windows, using mingw64 git.

However, after doing more investigating, it seems git recogizes that the
submodules are from the same repository, and uses hard links to avoid
file duplication. The Windows File Explorer Properties dialog
double-counts hard links, so it reports a bogus size
mingw64 'du' reports the correct size.

We can live with one extra copy of the ELPA repository.

-- Stephe

reply via email to

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