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

[Eli Zaretskii]

> From: Stephen Leake <stephen_leake@stephe-leake.org>
> Cc: phillip.lord@russet.org.uk,  emacs-devel@gnu.org
> Date: Sun, 24 Jan 2021 09:30:35 -0800
> 
> > 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.

I think it affects your point, because if ELPA will not present itself
as a single monolith repository, but instead will allow us to
submodule it at package granularity, the problem you mention will go
away.

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

So should 'ls'.