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: Wed, 27 Jan 2021 18:20:27 +0200 Message-ID: <83sg6mz704.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> <8335yq4350.fsf@gnu.org> <86k0s26qqt.fsf@stephe-leake.org> <83sg6q2is5.fsf@gnu.org> <86wnw06cgo.fsf@stephe-leake.org> <83y2gg23qb.fsf@gnu.org> <867dny5u4u.fsf@stephe-leake.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="29005"; 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 Wed Jan 27 17:21:52 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 1l4nZm-0007Pa-Fu for ged-emacs-devel@m.gmane-mx.org; Wed, 27 Jan 2021 17:21:50 +0100 Original-Received: from localhost ([::1]:38284 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l4nZl-00068U-Gw for ged-emacs-devel@m.gmane-mx.org; Wed, 27 Jan 2021 11:21:49 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48092) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l4nYU-0005Yb-6w for emacs-devel@gnu.org; Wed, 27 Jan 2021 11:20:30 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:49903) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l4nYT-0007Eo-0n; Wed, 27 Jan 2021 11:20:29 -0500 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:1294 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1l4nYG-0002xp-Dt; Wed, 27 Jan 2021 11:20:27 -0500 In-Reply-To: <867dny5u4u.fsf@stephe-leake.org> (message from Stephen Leake on Wed, 27 Jan 2021 06:31:13 -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:263511 Archived-At: > From: Stephen Leake > Cc: phillip.lord@russet.org.uk, emacs-devel@gnu.org > Date: Wed, 27 Jan 2021 06:31:13 -0800 > > > Maybe if you explained why splitting ELPA into several repositories > > would save some of that disk space, I could then try answering the > > question. > > Gnu ELPA is currently a single repository with lots of branches, one > branch per package. > > git submodule downloads the entire repository, even if you only want one > branch. > > So one way to eliminate the ballast is to split Gnu ELPA into one > repository per package; then git submodule will only download the > repository for that package. Since Stefan says this is a non-starter, we can forget about this alternative. > Stefan's suggestion eliminates the ballast in a different way; by keeping > the release branches of bundled packages in emacs.git, there is no > ballast in the local emacs repository. This could work, but we will have to arrange for some periodic job to update the copies of the bundled packages frequently enough. > >> I can see some reasons for the current git design; _all_ of the info needed > >> to update the code for project foo is in foo/.git. Worktrees stretch > >> that; allowing submodules to be worktree-like references to yet another > >> repository somewhere else would probably break many things in git. > > > > I think we should first find a way to have a single worktree with all > > the bundled packages that come from ELPA. How to have several > > worktrees from that is something we should consider later. > > I don't think we can leave it until later; if we choose a design that > explicitly prohibits worktrees, there is nothing that can be done later. It will mean that people who use worktrees will have to find some way of doing that, or give up worktrees. But IMO the convenience of bundling a package and handling such a bundled package trumps the convenience of people who use worktrees a lot.