emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [SPAM UNSURE] Re: policy discussion on bundling ELPA packages in the


From: Stephen Leake
Subject: Re: [SPAM UNSURE] Re: policy discussion on bundling ELPA packages in the emacs tarball
Date: Mon, 25 Jan 2021 11:38:20 -0800
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (windows-nt)

Phillip Lord <phillip.lord@russet.org.uk> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> If the submodules cannot be worktrees, then I think we have to
>>> abandon this approach.
>>
>> I'm not sure.  There are alternatives to using worktrees, so the fact
>> that some of us use worktrees in some workflows should not necessarily
>> veto the submodule solution to integrating ELPA into Emacs, because
>> this integration is more important than personal workflows.
>>
>> But maybe I misunderstand what you mean by "submodule cannot be
>> worktrees", because AFAIU Phillip raised an issue that is a different
>> one: whether submodules live well with different branches being
>> checked out in different worktrees -- there's nothing there to suggest
>> that submodules themselves should be worktrees.
>
> Just so.
>
> The version of git (2.25.1) on my laptop reports worktree and submodules
> as being broken.
>
> And the 2.30 also the same https://git-scm.com/docs/git-worktree

Ah. I'm using 2.17 in mingw64, but I haven't updated in a long time.
I'll update.

In particular, my tests so far have been creating new submodules in
worktrees. I have not committed a submodule (ie .gitmodules), then made
a worktree from that.

But we should not rely on something that the git maintainers say doesn't
work.

So we are back to using worktrees from a local elpa.git checkout. Sigh.

-- 
-- Stephe



reply via email to

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