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

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

[Kyle Meyer]

* 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/

 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
-- 
2.29.2.454.gaff20da3a2

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

[zimoun]

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:

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

>     $ # 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] :-)

1; <https://yhetil.org/guix-devel/86sgbhz3fe.fsf@gmail.com>
2: <https://yhetil.org/guix-patches/20201012082003.19936-1-zimon.toutoune@gmail.com>


>   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

[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 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.

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

[zimoun]

Hi,

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


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

>> 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”. :-)


> 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:

  <https://updates.orgmode.org/>

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).

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

[Christopher Baines]

[-- Attachment #1: Type: text/plain, Size: 3694 bytes --]


Kyle Meyer <kyle@kyleam.com> writes:

> * 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>
>  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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 987 bytes --]

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

[Kyle Meyer]

Christopher Baines writes:

> 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!