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

[Stefan Monnier]

>> 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.
> Couldn't we filter out mail to elpa-diffs where the diffs only touch
> files that aren't included using :files/:include?

The elpa-diffs email messages are generated on Savannah's side for all
pushes, so we really don't have very much control over them :-(

> Your point about package-vc identifies a disadvantage of using
> upstream's history, to be sure, but I think it's outweighed by the value
> of distributing upstream's actual history (arguably it's part of the
> preferred form for modification for the code).

I fully agree that using upstream's history verbatim is
a significant advantage.  Which is why ideally, they'd split their ELisp
code into a separate branch/repository.  Short of that we have to choose
between various sets of ills :-(

>> 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).
> Is it a hard requirement that the updates be automatic?

No it doesn't have to be automatic.  It should definitely be scripted
enough, otherwise I expect it'll get messy (with errors in the parallel
history, etc...).  But if it's not fully automatic, I expect it will
be forgotten.

> Couldn't we just manually import the emacs/ subdirectory to the branch
> whenever upstream make a release?

Not sure what you mean by that, but if it doesn't preserve the Git
history of the ELisp files, then it's definitely worse than `git
subtree` (or `git filter-branch/repo`).

> It doesn't happen every week, and it could be scripted.

This is not the first time the need arises, so such a script would be
a welcome addition (and we could run it on elpa.gnu.org to make the
workaround reasonably transparent).


        Stefan