[bug#44625] [PATCH] gnu: Add b4.

[Kyle Meyer]

zimoun writes:

> On Fri, 13 Nov 2020 at 19:39, Kyle Meyer <kyle@kyleam.com> wrote:

>>     $ # in the guix repo
>>     $ git config b4.attestation-policy off
>>     $ git config b4.midmask https://yhetil.org/guix-patches/%s
>>     $ b4 am 20201028165112.28575-1-zimon.toutoune@gmail.com
>>
>>   The end result is a filtered mbox with the v2 patches.  Also, because the
>>   sender helpfully included the base commit, `b4 am' will use that 
>> information
>>   in the instructions that it outputs.
>
> You mean ’b4’ filters out the 2 Ludo’s messages when applying the 2
> patches, right?

Right, 'b4 am' will try to extract the patch messages for the latest (or
specified) version, discarding everything else.  The end product is what
its documentation refers to as an "am-ready" mbox.

> In this case, ’b4’ will also fetch the patches from yhetil.org, right?

Yes.  Without the midmask above, it would try to fetch from an archive
at <https://lore.kernel.org> instead.

> If <issues.guix.gnu.org> exposes (somewhere?) the Message-ID (as we have
> discussed [1]), then one user could browse, copy the Message-ID that
> they is interested and paste locally as you explain above; without the
> need to subscribe or use Emacs-Debbugs.  Right?

Right, anybody can grab the mbox with just the message ID.  b4 is taking
advantage of the fact that public-inbox makes it easy to download a
thread's mbox by specifying the message ID:

  curl -fSsL 
86ima8d6rh.fsf@tournier.info/t.mbox.gz">https://yhetil.org/guix-patches/86ima8d6rh.fsf@tournier.info/t.mbox.gz | zless

> BTW, I think that base commit should be strongly encouraged when
> submitting patches.  See [2] :-)
>
> 1; <https://yhetil.org/guix-devel/86sgbhz3fe.fsf@gmail.com>
> 2: 
> <https://yhetil.org/guix-patches/20201012082003.19936-1-zimon.toutoune@gmail.com>

I very much agree (and remember https://github.com/magit/magit/issues/4028 :>)

>>   If the above sounds useful to you but you'd prefer to work in Emacs, you
>>   might be interested in piem (<https://git.kyleam.com/piem/about/>), which
>>   includes a transient (i.e magit-popup's successor) interface to b4.
>
> I have not tried either.  Is it packaged for Guix?

No.  I'm too sheepish to package my own stuff and at this point I'm
aware of no other piem user :).  Also I'm still not quite sure where I
want to go with it (and that answer probably largely depends on where
public-inbox goes with some planned features).

But there is a .guix.scm file in piem's repo that has a definition...

> Well, does b4 and piem works with worktree?

Yes.  'b4 am' stops at the am-ready patches, so it doesn't really care
at all.  piem will go farther, checking out a branch and calling git-am
with the output of b4 am.  It should play fine with worktrees (I use it
with one regularly), as long as :coderepo in piem-inboxes points to the
worktree you want to use.

Hmm, or reading ahead, now I'm wondering if you mean _creates_ a
worktree for applying the patch?  In that case, no, piem doesn't do
that.  It's not something I've considered before.

> Currently, I am using Emacs and Notmuch.  I have subscribed to
> guix-patches and when I try a patch, I do:
>
>   | git gam the-branch-worktree
>
> where ’gam’ is just ’-C ~/src/guix/wk/ am -3 --reject’.  And depending
> on the thread structure, sometimes I have to go patch by patch.
>
> Using b4+piem, then reading the message, I will do ’M-x piem-b4-am’ and
> whatever the thread structure, the patches sent as “in-reply-to“ will be
> applied.  Right?

Yes, you would invoke the piem-b4-am transient, select any options, and
then call piem-b4-am-from-mid ("a").  (The transient contains two other
commands, but they are essentially _just_ calling 'b4 am', stopping at
the am-ready mbox.)

As for which patches are applied, it depends on b4's analysis of the
thread.  When you have piem-notmuch-mode enabled, piem tries first to
use the local notmuch database before downloading a thread from a
public-inbox instance [*].  The message ID from the current buffer is
used to generate the entire thread with notmuch, in the same way that
'GET /MID/t.mbox.gz' on a public-inbox instance grabs the whole thread.
At that point, it is up to 'b4 am' which patches are extracted; by
default, it prefers the latest version it finds in the thread, but you
can explicitly select a version with the --use-version argument in the
piem-b4-am transient.

 [*] You can even get by without a public-inbox instance:
     
https://docs.kyleam.com/piem.html#Applying-patches-without-a-public_002dinbox-archive

> (Aside messages including non inlined patches, if I read correctly the
> doc.)

Correct, b4 only handles inline patches.  There is another command,
piem-am, that will try to do something sensible with attached patches in
the current message, but things get a lot less fancy once b4 is out of
the equation.