[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug#44625] [PATCH] gnu: Add b4.
[bug#44625] [PATCH] gnu: Add b4.
Sat, 14 Nov 2020 00:22:28 -0500
> On Fri, 13 Nov 2020 at 19:39, Kyle Meyer <firstname.lastname@example.org> wrote:
>> $ # in the guix repo
>> $ git config b4.attestation-policy off
>> $ git config b4.midmask https://yhetil.org/guix-patches/%s
>> $ b4 am email@example.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
>> 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 ), 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:
firstname.lastname@example.org/t.mbox.gz">https://email@example.com/t.mbox.gz | zless
> BTW, I think that base commit should be strongly encouraged when
> submitting patches. See  :-)
> 1; <https://firstname.lastname@example.org>
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
[*] You can even get by without a public-inbox instance:
> (Aside messages including non inlined patches, if I read correctly the
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