[PATCH] gnu: Add b4.

  • Done
  • quality assurance status badge
Details
3 participants
  • Kyle Meyer
  • Christopher Baines
  • zimoun
Owner
unassigned
Submitted by
Kyle Meyer
Severity
normal
K
K
Kyle Meyer wrote on 14 Nov 2020 01:39
(address . guix-patches@gnu.org)
20201114003906.25111-1-kyle@kyleam.com
* gnu/packages/version-control.scm (b4): New variable.
---

b4 is focused on lore.kernel.org public-inbox archives, but it's useful for
any public-inbox [1] instance, including yhetil.org/guix-patches :). Here's
an example with a recent multi-patch thread that involves multiple versions.

$ # 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.

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.


gnu/packages/version-control.scm | 41 ++++++++++++++++++++++++++++++++
1 file changed, 41 insertions(+)

Toggle diff (56 lines)
diff --git a/gnu/packages/version-control.scm b/gnu/packages/version-control.scm
index 16c70bd1a7..de7c961cea 100644
--- a/gnu/packages/version-control.scm
+++ b/gnu/packages/version-control.scm
@@ -2301,6 +2301,47 @@ (define-public grokmirror
based on a manifest file published by servers.")
(license license:gpl3+)))
+(define-public b4
+ (package
+ (name "b4")
+ (version "0.5.2")
+ (source
+ (origin
+ (method git-fetch)
+ (uri (git-reference
+ (url "https://git.kernel.org/pub/scm/utils/b4/b4.git")
+ (commit (string-append "v" version))))
+ (file-name (string-append name "-" version "-checkout"))
+ (sha256
+ (base32 "1w11fiyspyncz2m7njrjfylgzch4azi7560ngd8i733wvjjhg3mj"))))
+ (build-system python-build-system)
+ (arguments
+ `(#:tests? #f ; No tests.
+ #:phases
+ (modify-phases %standard-phases
+ (add-after 'install 'install-manpages
+ (lambda* (#:key outputs #:allow-other-keys)
+ (let ((man (string-append (assoc-ref outputs "out")
+ "/man/man5/")))
+ (mkdir-p man)
+ (for-each (lambda (file) (install-file file man))
+ (find-files "man" "\\.[1-8]$")))
+ #t)))))
+ (inputs
+ `(("python-requests" ,python-requests)))
+ (home-page "https://git.kernel.org/pub/scm/utils/b4/b4.git")
+ (synopsis "Tool for working with patches in public-inbox archives")
+ (description "The @code{b4} command is designed to make it easier to
+participate in patch-based workflows for projects that have public-inbox
+archives. Features include
+@itemize
+@item downloading a thread's mbox given a message ID
+@item processing an mbox so that is ready to be fed to @code{git-am}
+@item creating templated replies for processed patches and pull requests
+@item submitting cryptographic attestation for patches.
+@end itemize")
+ (license license:gpl2+)))
+
(define-public git-annex-remote-rclone
(package
(name "git-annex-remote-rclone")

base-commit: 4e9b2e8ba26dd601df67f112852237d5df2f3341
--
2.29.2.454.gaff20da3a2
Z
Z
zimoun wrote on 14 Nov 2020 03:14
86ima8d6rh.fsf@tournier.info
Hi Kyle,

I have not tried your patch, yet. And I have questions about tooling,
maybe it is not the right place to do so.


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

Toggle quote (4 lines)
> b4 is focused on lore.kernel.org public-inbox archives, but it's useful for
> any public-inbox [1] instance, including yhetil.org/guix-patches :). Here's
> an example with a recent multi-patch thread that involves multiple versions.

Look super useful.

Toggle quote (9 lines)
> $ # 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?

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

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?


BTW, I think that base commit should be strongly encouraged when
submitting patches. See [2] :-)



Toggle quote (4 lines)
> 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?


Well, does b4 and piem works with worktree?

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?

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


All the best,
simon
K
K
Kyle Meyer wrote on 14 Nov 2020 06:22
(name . zimoun)(address . zimon.toutoune@gmail.com)(address . 44625@debbugs.gnu.org)
87wnyo5x7v.fsf@kyleam.com
zimoun writes:

Toggle quote (14 lines)
> 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.

Toggle quote (2 lines)
> 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

Toggle quote (5 lines)
> 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:


Toggle quote (6 lines)
> 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: )

Toggle quote (6 lines)
>> 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...

Toggle quote (2 lines)
> 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.

Toggle quote (12 lines)
> 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:

Toggle quote (3 lines)
> (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.
Z
Z
zimoun wrote on 14 Nov 2020 14:36
(name . Kyle Meyer)(address . kyle@kyleam.com)(address . 44625@debbugs.gnu.org)
86361cys9h.fsf@tournier.info
Hi,

Thank you for the explanations, drifting from the patch. :-)


On Sat, 14 Nov 2020 at 00:22, Kyle Meyer <kyle@kyleam.com> wrote:

Toggle quote (5 lines)
>> BTW, I think that base commit should be strongly encouraged when
>> submitting patches. See [2] :-)
>
> I very much agree (and remember https://github.com/magit/magit/issues/4028 :>)

Yeah! And the last remaining piece if “git-send-email”. :-)


Toggle quote (4 lines)
> 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.

Yes, somehow. Generally, I create a new checked out worktree with a new
branch starting at base-commit, then I apply the patches in. Well, my
sequence looks like:

M-C-SPC M-w <base-commmit>
C-x b <magit-guix-master>
% c /path/to/wk/foo RET C-y RET foo RET
C-x b <message-with-patch>
| git gam foo

and I am not enough annoyed (yet!) to write some Emacs helper
functions. However, if b4+piem could do that for me, should be
awesome. :-)


All the best,
simon

PS:
After a discussion with Bastien and when I let my imagination goes far
away, it could be nice to something like:


bridging <issues.guix.gnu.org> and
<lists.gnu.org/archive/html/{{bug,help}-guix,guix-{devel,patches}}>
(or an instance of public-inbox as <yhetil.org>)
and <ci.guix.gnu.org> and <data.guix.gnu.org>,
even maybe <logs.guix.gnu.org>.

The email-based workflow with some fancy interfaces to be welcoming with
new contributors (smooth the learning curve).
C
C
Christopher Baines wrote on 15 Nov 2020 21:18
(name . Kyle Meyer)(address . kyle@kyleam.com)(address . 44625-done@debbugs.gnu.org)
87d00ez855.fsf@cbaines.net
Kyle Meyer <kyle@kyleam.com> writes:

Toggle quote (21 lines)
> * gnu/packages/version-control.scm (b4): New variable.
> ---
>
> b4 is focused on lore.kernel.org public-inbox archives, but it's useful for
> any public-inbox [1] instance, including yhetil.org/guix-patches :). Here's
> an example with a recent multi-patch thread that involves multiple versions.
>
> $ # 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.
>
> 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.
>
> [1] https://public-inbox.org/
n>
Toggle quote (58 lines)
> gnu/packages/version-control.scm | 41 ++++++++++++++++++++++++++++++++
> 1 file changed, 41 insertions(+)
>
> diff --git a/gnu/packages/version-control.scm b/gnu/packages/version-control.scm
> index 16c70bd1a7..de7c961cea 100644
> --- a/gnu/packages/version-control.scm
> +++ b/gnu/packages/version-control.scm
> @@ -2301,6 +2301,47 @@ (define-public grokmirror
> based on a manifest file published by servers.")
> (license license:gpl3+)))
>
> +(define-public b4
> + (package
> + (name "b4")
> + (version "0.5.2")
> + (source
> + (origin
> + (method git-fetch)
> + (uri (git-reference
> + (url "https://git.kernel.org/pub/scm/utils/b4/b4.git")
> + (commit (string-append "v" version))))
> + (file-name (string-append name "-" version "-checkout"))
> + (sha256
> + (base32 "1w11fiyspyncz2m7njrjfylgzch4azi7560ngd8i733wvjjhg3mj"))))
> + (build-system python-build-system)
> + (arguments
> + `(#:tests? #f ; No tests.
> + #:phases
> + (modify-phases %standard-phases
> + (add-after 'install 'install-manpages
> + (lambda* (#:key outputs #:allow-other-keys)
> + (let ((man (string-append (assoc-ref outputs "out")
> + "/man/man5/")))
> + (mkdir-p man)
> + (for-each (lambda (file) (install-file file man))
> + (find-files "man" "\\.[1-8]$")))
> + #t)))))
> + (inputs
> + `(("python-requests" ,python-requests)))
> + (home-page "https://git.kernel.org/pub/scm/utils/b4/b4.git")
> + (synopsis "Tool for working with patches in public-inbox archives")
> + (description "The @code{b4} command is designed to make it easier to
> +participate in patch-based workflows for projects that have public-inbox
> +archives. Features include
> +@itemize
> +@item downloading a thread's mbox given a message ID
> +@item processing an mbox so that is ready to be fed to @code{git-am}
> +@item creating templated replies for processed patches and pull requests
> +@item submitting cryptographic attestation for patches.
> +@end itemize")
> + (license license:gpl2+)))
> +
> (define-public git-annex-remote-rclone
> (package
> (name "git-annex-remote-rclone")
>
> base-commit: 4e9b2e8ba26dd601df67f112852237d5df2f3341

Thanks Kyle, I tweaked the formatting of the description, just adding a
newline as I thought it looked better, and pushed this to master as
3b77ba78684e201382b1c28f2618252205891568.

Thanks again,

Chris
-----BEGIN PGP SIGNATURE-----

iQKlBAEBCgCPFiEEPonu50WOcg2XVOCyXiijOwuE9XcFAl+xjQZfFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDNF
ODlFRUU3NDU4RTcyMEQ5NzU0RTBCMjVFMjhBMzNCMEI4NEY1NzcRHG1haWxAY2Jh
aW5lcy5uZXQACgkQXiijOwuE9Xesyg//QwokDmkrxeJbtDXEKILvcO03jQlP31BJ
TtozIsZxa8KmXAisfPzi50B3G1zXfBvvV7LRuJdoycjU4pwk3606JCm9/ANcNPA8
bkYPIRa9EzceD8l35DNz6/rcS3hcakD9iE7A+ZzYJFhP2SKg51YDluRXkdKAOpac
iWQdcynuSOv35tqIZbCQogJKUW0ojKHO0miKs74r3V6eJP+x9LwIJRUIa0X1a59J
yD02ACXAANKlXMbZWRNMOis7Jn6NwaFT80pwt3jgdXF6MW6FB1YqyxnUBHWyyxsn
ZNOVgwKolW4zCkrJmjIIUNbf8ksFmp96rKQ80QxtcmbgGDtMyL3E+/5U+lDVvjIP
PcWKPQ5OmY2x9X3VTy0ieueZjglVWMbrqWc7qtfchhXmv1VhI6v1eWabZkqaELXF
GdJkt19Oiu6loOq5TLq0IjXwf5HR64XSjHJUDDLBf/o/Cx/11/Qj2ydg4j0kJqkA
Ae5ZcReVYPeO+G+WjRPIX3GD/rDrpuGWdtFp2RRtW3nBacZp1rBlrvKKBKYa+BkB
08QDiIkFnY2JQOwCA2y17O9YZT2LL0yRcxL4Kf2Z1eXlzjDnt8/aHLXOC2rPbEnv
/XhKP5JBDfdeJDjr5Tmo0OFlMga9LV70QPfpB0kQIg/bgRZbwTlw2rps0qlXzJ4B
3Qq/1MvCdPY=
=TatH
-----END PGP SIGNATURE-----

Closed
K
K
Kyle Meyer wrote on 15 Nov 2020 21:53
(name . Christopher Baines)(address . mail@cbaines.net)(address . 44625@debbugs.gnu.org)
87sg9al4tn.fsf@kyleam.com
Christopher Baines writes:

Toggle quote (4 lines)
> Thanks Kyle, I tweaked the formatting of the description, just adding a
> newline as I thought it looked better, and pushed this to master as
> 3b77ba78684e201382b1c28f2618252205891568.

The tweaked formatting looks good to me.

Thanks!
?
Your comment

This issue is archived.

To comment on this conversation send an email to 44625@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 44625
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch