From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: policy discussion on bundling ELPA packages in the emacs tarball Date: Sun, 24 Jan 2021 20:10:35 +0200 Message-ID: <8335yq4350.fsf@gnu.org> References: <86eeifawx8.fsf@stephe-leake.org> <87czxygdl9.fsf@russet.org.uk> <86tur88izp.fsf@stephe-leake.org> <86h7n880lo.fsf@stephe-leake.org> <83y2gk3rin.fsf@gnu.org> <86o8he6y4k.fsf@stephe-leake.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="24803"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org, phillip.lord@russet.org.uk To: Stephen Leake Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Jan 24 19:11:59 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1l3jrh-0006Gh-Ll for ged-emacs-devel@m.gmane-mx.org; Sun, 24 Jan 2021 19:11:57 +0100 Original-Received: from localhost ([::1]:59314 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l3jrg-000423-Cm for ged-emacs-devel@m.gmane-mx.org; Sun, 24 Jan 2021 13:11:56 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47138) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l3jqb-0003Rn-5P for emacs-devel@gnu.org; Sun, 24 Jan 2021 13:10:51 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:33765) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l3jqU-0003Iz-RF; Sun, 24 Jan 2021 13:10:46 -0500 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:4185 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1l3jqK-0007RY-Ub; Sun, 24 Jan 2021 13:10:39 -0500 In-Reply-To: <86o8he6y4k.fsf@stephe-leake.org> (message from Stephen Leake on Sun, 24 Jan 2021 09:30:35 -0800) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:263347 Archived-At: > From: Stephen Leake > 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'.