emacs-devel
[Top][All Lists]
Advanced

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

Re: [nongnu] main 385623dca6 2/2: * elpa-packages (notmuch): New package


From: Stefan Monnier
Subject: Re: [nongnu] main 385623dca6 2/2: * elpa-packages (notmuch): New package.
Date: Wed, 21 Dec 2022 23:03:15 -0500
User-agent: Gnus/5.13 (Gnus v5.13)

>> While I hope Git grows support for "partial clones" (or more likely is
>> superseded by something else which does support such things), the
>> current situation is that you just can't do that.  Which means
>> `elpa-diffs` will be spammed with irrelevant commit to the non-Emacs
>> part of Notmuch, for example, and `package-vc` will still have to
>> download the 10MB of Notmuch's repository just to get at the relevant
>> 0.5MB.
>
> Do you know if this is being worked on?  Does it even fit into Git's
> internal model?

I don't think so, no.

> (This might be too hacking, but I recently found out that GitHub
> supports checking out repositories using Subversion.  I guess they use
> some bridge to translate the requests.  I don't know if it is possible
> to make use of this and a second SVN->Git bridge to check out partial
> repositories as SVN does)

It's no better than using `git subtree`.

Maybe something like Pijul (which supports partial trees really well)
will grow to be a worthy competitor, but we're pretty far from
that, AFAIK.

>> The closest we can get, AFAIK, is to run an interposer repository which
>> fetches from https://git.notmuchmail.org/git/notmuch and filters the
>> `emacs` subtree into a new branch, and then add *that* branch to
>> `elpa-packages`.  Of course, that creates a whole parallel history, so
>> it may end up biting us down the line, but I think given the current
>> situation it'd the "least wrong" way to do it (The Right Way being if
>> they do that split upstream and then use the new branch as the official
>> upstream).
>
> This was discussed back when I wanted to add a few modes developed in
> mono-repos (erlang was one example, cmake is another).  I had managed to
> make this work using filter-branch IIRC, but we never set up a mirror.
> Perhaps we should tackle that again, even if the solution is suboptimal

I think we should yes.

> and host the filtered repositories on savannah.nongnu.org.

Or the filtered result could just live in nongnu.git/elpa.git.

> I could set up a similar structure to nongnu.git and have each
> repository we are interested in mirrored on their own branches that
> nongnu.git:elpa-packages would target.

I was thinking of doing the work within `elpaa--fetch`, actually.


        Stefan




reply via email to

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