[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: Eli Zaretskii
Subject: Re: policy discussion on bundling ELPA packages in the emacs tarball
Date: Sun, 24 Jan 2021 20:10:35 +0200

> 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

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

reply via email to

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