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

Yes.

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

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
(https://docs.microsoft.com/en-us/troubleshoot/windows-client/deployment/address-disk-space-issues-caused-by-winsxs).
mingw64 'du' reports the correct size.

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

--
-- Stephe