unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Stephen Leake <stephen_leake@stephe-leake.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: emacs-devel@gnu.org, phillip.lord@russet.org.uk
Subject: Re: policy discussion on bundling ELPA packages in the emacs tarball
Date: Mon, 25 Jan 2021 11:30:47 -0800	[thread overview]
Message-ID: <86wnw06cgo.fsf@stephe-leake.org> (raw)
In-Reply-To: <83sg6q2is5.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 24 Jan 2021 22:15:38 +0200")

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Stephen Leake <stephen_leake@stephe-leake.org>
>> Cc: phillip.lord@russet.org.uk,  emacs-devel@gnu.org
>> Date: Sun, 24 Jan 2021 12:10:02 -0800
>> 
>> Do you agree that having one full copy of the ELPA repository in your
>> local emacs .git repository is acceptable?
>
> IMO, people who are interested only in packages bundled with Emacs
> should not need to have ELPA on their local machines.  Not even one
> checkout of ELPA should be needed.  They should just need to clone the
> Emacs Git repository (modulo the submodules-related options), and
> that's all.  Exactly like they do today: there's no need to clone ELPA
> to have a fully functional clone of the Emacs Git repository.

That is exactly what using submodules accomplishes.

But I'm not sure you've answered my question. Let me phrase it
differently:

Doing 'git clone <membername>@git.savannah.gnu.org:/srv/git/emacs.git'
results in disk space usage of around 300 MB in emacs/.git, and does not
populate emacs/elpa.

Doing 'git clone <membername>@git.savannah.gnu.org:/srv/git/emacs.git
--recurse-submodules' results in disk space usage of around 500 MB in
emacs/.git, and populates emacs/elpa.

If we implemented the suggestion to split the ELPA repository into one
repository per bundled package, that extra 200 MB would be smaller.

Is 200 MB acceptable?

>> For developers who also have elpa.git cloned separately, that's a
>> duplicate copy.
>
> Which it shouldn't be.

I agree it would be nice, but that's up to the git maintainers. Or we
could look for another CM tool ...

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.

-- 
-- Stephe



  parent reply	other threads:[~2021-01-25 19:30 UTC|newest]

Thread overview: 70+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-21  1:41 policy discussion on bundling ELPA packages in the emacs tarball Stephen Leake
2021-01-21 14:17 ` Eli Zaretskii
2021-01-22 10:56   ` [SPAM UNSURE] " Stephen Leake
2021-01-22 11:50     ` Eli Zaretskii
2021-01-22 14:05       ` Stefan Monnier
2021-01-21 21:54 ` Phillip Lord
2021-01-23  2:50   ` Stephen Leake
2021-01-23  8:17     ` Eli Zaretskii
2021-01-24 16:26       ` [SPAM UNSURE] " Stephen Leake
2021-01-24 21:49       ` Phillip Lord
2021-01-25 19:38         ` [SPAM UNSURE] " Stephen Leake
2021-01-25 19:54           ` Eli Zaretskii
2021-01-25 20:39           ` Stefan Monnier
2021-01-26  1:04             ` Andy Moreton
2021-01-26  2:38               ` Stefan Monnier
2021-01-26 14:44             ` Eli Zaretskii
2021-01-26 15:25               ` Stefan Monnier
2021-01-26 15:34                 ` Eli Zaretskii
2021-01-26 16:14                   ` Stefan Monnier
2021-01-26 16:30                     ` Eli Zaretskii
2021-01-26 17:27                       ` Stefan Monnier
2021-01-26 17:42                         ` Eli Zaretskii
2021-01-26 17:57                           ` Stefan Monnier
2021-01-26 19:12                             ` Eli Zaretskii
2021-01-28  0:15                               ` Stephen Leake
2021-01-28  2:05                                 ` Stefan Monnier
2021-01-28 13:47                                   ` Eli Zaretskii
2021-01-28 13:43                                 ` Eli Zaretskii
2021-01-27 14:52                         ` Dmitry Gutov
2021-01-27 14:57                           ` Stefan Monnier
2021-01-26 18:02                 ` Stefan Monnier
2021-01-26 18:12                   ` Stefan Monnier
2021-01-27 14:21                   ` Stephen Leake
2021-01-27 14:35                     ` Stefan Monnier
2021-01-27 14:48               ` Stephen Leake
2021-01-27 14:42             ` Stephen Leake
2021-01-27 16:22               ` Eli Zaretskii
2021-01-23  9:27     ` Stephen Leake
2021-01-23  9:57       ` Eli Zaretskii
2021-01-24  2:28         ` Dmitry Gutov
2021-01-24 16:27           ` Stephen Leake
2021-01-24 17:30         ` Stephen Leake
2021-01-24 18:10           ` Eli Zaretskii
2021-01-24 20:10             ` Stephen Leake
2021-01-24 20:15               ` Eli Zaretskii
2021-01-24 20:42                 ` Dmitry Gutov
2021-01-25 22:00                   ` Stephen Leake
2021-01-26  1:57                     ` Dmitry Gutov
2021-01-26 14:48                     ` Eli Zaretskii
2021-01-26 15:24                       ` Andreas Schwab
2021-01-27 14:37                       ` Stephen Leake
2021-01-27 16:22                         ` Eli Zaretskii
2021-01-28  0:10                           ` Stephen Leake
2021-01-28 13:38                             ` Eli Zaretskii
2021-01-25 19:30                 ` Stephen Leake [this message]
2021-01-25 19:53                   ` Eli Zaretskii
2021-01-27 14:31                     ` Stephen Leake
2021-01-27 14:44                       ` Stefan Monnier
2021-01-28  3:34                         ` Andy Moreton
2021-01-27 16:20                       ` Eli Zaretskii
2021-01-29 17:47                         ` Phillip Lord
2021-02-01  8:45                           ` Robert Pluim
2021-02-01 15:09                             ` Eli Zaretskii
2021-01-24 22:09     ` Phillip Lord
2021-01-25 19:14       ` Stephen Leake
2021-01-27 11:10         ` Phillip Lord
2021-01-27 14:31           ` Stefan Monnier
2021-01-28  0:05           ` Stephen Leake
2021-01-24 20:19   ` Stephen Leake
2021-01-24  2:59 ` Dmitry Gutov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=86wnw06cgo.fsf@stephe-leake.org \
    --to=stephen_leake@stephe-leake.org \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=phillip.lord@russet.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).