[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: Phillip Lord
Subject: Re: policy discussion on bundling ELPA packages in the emacs tarball
Date: Fri, 29 Jan 2021 17:47:39 +0000
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

Eli Zaretskii <eliz@gnu.org> writes:

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

To give you an idea of why I use worktrees, it is because Emacs does not
really do an out of source build. So, on the windows build machine I
currently have:


For emacs-27 I only ever do full builds; creating a new worktree means
that I start from clean, but is clearly not the only way to achieve

For emacs-28, though, when I release snapshots, I do not (always) do
clean builds. I use the .elc files from the previous build. The same
will be true for native-comp once I have that working enough to build

It's not a disaster, but I will have to switch the windows packaging
scripts away from this schema if worktrees do not work; I guess I will
use mulitple clones instead. This may mean I run out of disk space on my
windows build machine, though which only has a tiny disc, I don't
know. It depends on how well git works, and how clever Windows file
system compression is.

I do the same on my working machines, so I can keep multiple branches
open. So I can test master, but jump back to a release branch if it
breaks and I am busy. I guess I will use multiple clones here again.


reply via email to

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