* 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
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
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.
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).
[-- 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 --]
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!