Re: policy discussion on bundling ELPA packages in the emacs tarball

[Phillip Lord]

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:

emacs-build/master
emacs-build/emacs-27
emacs-build/emacs-27.1.91
emacs-build/feature/native-comp

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

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

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.

Phil