Workflow with mu4e + magit for sending patchsets to guix?

Workflow with mu4e + magit for sending patchsets to guix?

[Christopher Lemmer Webber]

I've been making patchset series of emails to guix-patches manually.
I'm sure this is the wrong thing to do.  I use mu4e + magit and know
others have a similar setup.

What do you all do?
 - Chris

Re: Workflow with mu4e + magit for sending patchsets to guix?

[Christopher Baines]

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


Christopher Lemmer Webber <cwebber@dustycloud.org> writes:

> I've been making patchset series of emails to guix-patches manually.
> I'm sure this is the wrong thing to do.  I use mu4e + magit and know
> others have a similar setup.

I think git send-email on the command line does the right thing.

For a single patch, I just git send-email --to=guix-patches@gnu.org
HEAD^

For a series of patches, it's more drawn out. First I run git
format-patch --cover-letter ... then copy the cover letter in to an
email, and then send to guix-patches@gnu.org. Then I wait for the
reply, and then git send-email --to=NUMBER@debbugs.gnu.org
--in-reply-to=MESSAGE ID FROM THE FIRST EMAIL.

I'm not sure if the --in-reply-to bit is useful.

I do use mu4e and magit myself, but I'm not sure I know a way of sending
patches more quickly or more easily than this.

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

Re: Workflow with mu4e + magit for sending patchsets to guix?

[zimoun]

Hi Chris

+CC Kyle since they probably knows the status [1].

On Mon, 16 Nov 2020 at 15:28, Christopher Lemmer Webber <cwebber@dustycloud.org> wrote:

> I've been making patchset series of emails to guix-patches manually.
> I'm sure this is the wrong thing to do.  I use mu4e + magit and know
> others have a similar setup.
>
> What do you all do?

I am sending really few patches so my workflow is probably not
optimized.  What I do is from magit-status:

 1. Select the commits
 2. W c
    C-m b origin/master RET
    C-m l
    c
 3. Edit the cover letter
 4. !! send-email --to=guix-patches@gnu.org 0000-cover-letter.patch
 5. Wait and refresh my inbox
 6. !! send-email --to=12345@gnu.org 000?-*.patch

Be careful if other patches remain in your current worktree.

Note base-commit which provides the information against which commit the
series applies.  It is really helpful for applying; especially if the
series falls in the crack *or* for the “new” tool b4 and the Emacs
front-end piem [2].  See thread here [3]. :-)


AFAIK, there is no ’send-email’ support with Magit.  I have never check
the built-in vc-mode.

What I have understood is that Magit-forge should implement ’send-email’
as a backend (forge) but it has not happened yet.  Or I missed the
news. :-)

I am curious to know how others Emacsers fellows do.


Hope that helps,
simon

1: <https://github.com/magit/magit/issues/2499>
2: <https://git.kyleam.com/piem/about/>
3: <https://yhetil.org/guix-patches/20201114003906.25111-1-kyle@kyleam.com>
4: <https://github.com/magit/magit/issues/1800>

Re: Workflow with mu4e + magit for sending patchsets to guix?

[Kyle Meyer]

zimoun writes:

> Hi Chris
>
> +CC Kyle since they probably knows the status [1].

Sorry, I have no good news for you :/

> On Mon, 16 Nov 2020 at 15:28, Christopher Lemmer Webber <cwebber@dustycloud.org> wrote:
>
>> I've been making patchset series of emails to guix-patches manually.
>> I'm sure this is the wrong thing to do.  I use mu4e + magit and know
>> others have a similar setup.
>>
>> What do you all do?
>
> I am sending really few patches so my workflow is probably not
> optimized.  What I do is from magit-status:
>
>  1. Select the commits

I'd suggest always setting an upstream for topic branches.  Then the
range you're interested in is almost always "@{upstream}.." (which can
be shortened to "@{u}..").  Or you can add something like this to
Magit's popup [1]:

  ;; https://git.kyleam.com/emacs.d/tree/lisp/km-magit.el?id=928629a9ccd8b439d0e98d9976b75c4cf5f048f9#n836

  (defun km/magit-patch-create-from-upstream (&optional args)
    (interactive (list (transient-args 'magit-patch-create)))
    (if-let ((upstream (magit-get-upstream-branch)))
        (apply #'magit-run-git "format-patch" upstream args)
      (user-error "No upstream branch")))

  (transient-append-suffix 'magit-patch-create "c"
    '("u" "@{upstream}.." km/magit-patch-create-from-upstream))

Most of my magit customizations never find their way upstream (they tend
to be very tailored to me), but something like the command above would
probably be good to add.

>  2. W c
>     C-m b origin/master RET

Yay, base commit :)  Note that with the upstream set, you can select
"auto" here.  Or you can configure format.useAutoBase to "whenAble" and
not bother setting the option for each invocation.

>     C-m l

If you follow the convention of writing a cover letter only for
multi-patch series, you can drop the 'C-m l' because by default git will
generate a cover letter when there is more than one commit.

>     c
>  3. Edit the cover letter
>  4. !! send-email --to=guix-patches@gnu.org 0000-cover-letter.patch
>  5. Wait and refresh my inbox
>  6. !! send-email --to=12345@gnu.org 000?-*.patch

Yeah, 4-6 are tricky and debbugs-specific.  For other projects, it could
just be 'send-email *.patch' once sendemail.to is configured to point to
the list's address.

For 6, using '--no-thread --in-reply-to=...' will retain the same
threading you'd see if you weren't using debbugs (i.e didn't have to do
the two-step send).

Also, not helpful for mu4e users, but since I know simon uses notmuch...
notmuch has a really handy notmuch-show-stash-git-send-email.  I have a
variant for step 5 above.  If you call it visiting the acknowledgment
message, it will copy

  --to="NNNNN@debbugs.gnu.org"  --in-reply-to="message-id"

to your kill ring.

  https://git.kyleam.com/emacs.d/tree/lisp/km-mail.el?id=928629a9ccd8b439d0e98d9976b75c4cf5f048f9#n225

> AFAIK, there is no ’send-email’ support with Magit.  [...]
>
> What I have understood is that Magit-forge should implement ’send-email’
> as a backend (forge) but it has not happened yet.  Or I missed the
> news. :-)

Right, there's no send-email support in Magit (or any of the extensions
under its organization).  I of course can't speak for Jonas, but I'm not
aware of any movement or concrete plans on that front.  I think the most
recent thread to touch on this is actually the one you opened early this
year about extending format-patch options:
<https://github.com/magit/magit/issues/4028>.

And, sadly I guess, my view is still similar to what I said there:

  send-email has of course come up a number of times before (gh-1756 and
  gh-1800 are the most relevant, I think), and tackling that requires a
  vision that I don't really have.  Perhaps due to a lack of
  imagination, I can't think of an implementation on Magit's side that
  would improve the simple send-email command that I run.  In terms of
  sending mail, the most involved thing that I need to do is get the
  --to/--ccs and --in-reply-to from an existing thread, but in my view
  that's outside of Magit's scope.

I don't know.  Maybe I should try to think harder about it.

A final note of hope: as a lurker on the notmuch list, I've noticed that
Jonas has starting doing some patch-based contributions.  So, perhaps
he'll get an itch and do his amazing Jonas thing.

Re: Workflow with mu4e + magit for sending patchsets to guix?

[Pierre Neidhardt]

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

Kyle Meyer <kyle@kyleam.com> writes:

> Also, not helpful for mu4e users, but since I know simon uses notmuch...
> notmuch has a really handy notmuch-show-stash-git-send-email.

Notmuch user here, today I learned about
notmuch-show-stash-git-send-email!

Thanks for the tip!

-- 
Pierre Neidhardt
https://ambrevar.xyz/

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

Re: Workflow with mu4e + magit for sending patchsets to guix?

[zimoun]

Hi Pierre,

On Tue, 17 Nov 2020 at 08:28, Pierre Neidhardt <mail@ambrevar.xyz> wrote:

> Notmuch user here, today I learned about
> notmuch-show-stash-git-send-email!

Some weeks (months?) ago, I also “discovered“ the Notmuch stash stuff.


For example, if I want to refer to your previous message via classic
way, I do:

 1. Open webbrowser and go to the relevant page of archives
 2. Scroll to find the message, click
 3. Stash the URL
 4. Swicth back to Emacs, yank

<https://lists.gnu.org/archive/html/help-guix/2020-11/msg00109.html>

Maybe instead of webbrowser, I could use eww to avoid the switch.
Anyway.

The issue here is the numbering.  Your message was the 109th message on
help-guix this month but this number is impossible to guess, well one
needs to parse all the mbox archive and count.  Argh!  Each email has an
unique identifier the header Message-ID field.  For example, the one of
your message is: 87pn4ca1c7.fsf@ambrevar.xyz.

And <https://yhetil.org> serves the mapping via public-inbox.
Concretely, I do ’cl’ (notmuch-show-stash-mlarchive-link) reading your
message, select the archive and I get:

<https://yhetil.org/guix-user/87pn4ca1c7.fsf@ambrevar.xyz>

Select the archive because by default it is linux-kernel related
archives: LKML, MARC, etc. even if I do not know about Gmane.  My config
is:

--8<---------------cut here---------------start------------->8---
  ;; c l stashes a hyperlink using Message-ID instead of numbering, e.g.:
  ;; https://yhetil.org/guix-user/acba4413-a4ca-d7e5-08f7-24ac9839b830@posteo.de
  ;; vs https://lists.gnu.org/archive/html/help-guix/2020-10/msg00177.html
  (mapcar (lambda (what)
            (add-to-list 'notmuch-show-stash-mlarchive-link-alist
                         `(,what . ,(concat "https://yhetil.org/" what "/"))))
          (reverse'("guix-devel"
                    "guix-user"
                    "guix-science"
                    "gwl"
                    "guix-bugs"
                    "guix-patches")))
--8<---------------cut here---------------end--------------->8---

(Instead of manually selecting the archive, an helper function could
parse the header fields and do the job but I have not been annoyed
enough yet. :-))

Neat!  Isn’t it? :-)


In this picture, you could be interested by this thread:

  Mummi wishlist: API using Message-ID
  <https://yhetil.org/guix-devel/86sgbhz3fe.fsf@gmail.com>

Note that the project Org-mode switched to a public-inbox instance
recently:

    <https://orgmode.org/list/87r1vd92eg.fsf@bzg.fr/>


Hope that helps,
simon

Re: Workflow with mu4e + magit for sending patchsets to guix?

[Pierre Neidhardt]

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

zimoun <zimon.toutoune@gmail.com> writes:

> And <https://yhetil.org> serves the mapping via public-inbox.
> Concretely, I do ’cl’ (notmuch-show-stash-mlarchive-link) reading your
> message, select the archive and I get:
>
> <https://yhetil.org/guix-user/87pn4ca1c7.fsf@ambrevar.xyz>
>
> Select the archive because by default it is linux-kernel related
> archives: LKML, MARC, etc. even if I do not know about Gmane.  My config
> is:
>
> --8<---------------cut here---------------start------------->8---
>   ;; c l stashes a hyperlink using Message-ID instead of numbering, e.g.:
>   ;; https://yhetil.org/guix-user/acba4413-a4ca-d7e5-08f7-24ac9839b830@posteo.de
>   ;; vs https://lists.gnu.org/archive/html/help-guix/2020-10/msg00177.html
>   (mapcar (lambda (what)
>             (add-to-list 'notmuch-show-stash-mlarchive-link-alist
>                          `(,what . ,(concat "https://yhetil.org/" what "/"))))
>           (reverse'("guix-devel"
>                     "guix-user"
>                     "guix-science"
>                     "gwl"
>                     "guix-bugs"
>                     "guix-patches")))
> --8<---------------cut here---------------end--------------->8---
>
> (Instead of manually selecting the archive, an helper function could
> parse the header fields and do the job but I have not been annoyed
> enough yet. :-))

At your service:

--8<---------------cut here---------------start------------->8---
(defvar ambrevar/known-mailing-list-archives
  '(("help-guix@gnu.org" . "guix-user")
    ("guix-devel@gnu.org" . "guix-devel")
    ("guix-bugs" . "guix-bugs")
    ("guix-patches" . "guix-patches"))
  "Alist of mail adresses and their Yhetil name.")

(defun ambrevar/guess-yhetil-link (message-id)
  (let* ((all-addresses
          (mapcar #'second
                  (mail-extract-address-components
                   (mapconcat #'identity
                              (list
                               (notmuch-show-get-header :To)
                               (notmuch-show-get-header :Cc))
                              ", ")
                   'all)))
         (mailing-list
          (cdr (seq-find
                (lambda (pair)
                  (member (car pair) all-addresses))
                ambrevar/known-mailing-list-archives))))
    (when mailing-list
      (concat "https://yhetil.org/"
              mailing-list "/" message-id))))

(add-to-list 'notmuch-show-stash-mlarchive-link-alist
             (cons "Yhetil" #'ambrevar/guess-yhetil-link))
--8<---------------cut here---------------end--------------->8---

I had to create an alist to map between the address of the mailing list
and the Yhetil name because in the case of guix-user, the address is not
the same (help-guix).  I wonder why.

Cheers!

-- 
Pierre Neidhardt
https://ambrevar.xyz/

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

Re: Workflow with mu4e + magit for sending patchsets to guix?

[zimoun]

Hi Pierre,

Thanks!

On Wed, 25 Nov 2020 at 10:19, Pierre Neidhardt <mail@ambrevar.xyz> wrote:

> --8<---------------cut here---------------start------------->8---
> (defvar ambrevar/known-mailing-list-archives
>   '(("help-guix@gnu.org" . "guix-user")
>     ("guix-devel@gnu.org" . "guix-devel")
>     ("guix-bugs" . "guix-bugs")
>     ("guix-patches" . "guix-patches"))
>   "Alist of mail adresses and their Yhetil name.")
>
> (defun ambrevar/guess-yhetil-link (message-id)
>   (let* ((all-addresses
>           (mapcar #'second
>                   (mail-extract-address-components
>                    (mapconcat #'identity
>                               (list
>                                (notmuch-show-get-header :To)
>                                (notmuch-show-get-header :Cc))
>                               ", ")
>                    'all)))
>          (mailing-list
>           (cdr (seq-find
>                 (lambda (pair)
>                   (member (car pair) all-addresses))
>                 ambrevar/known-mailing-list-archives))))
>     (when mailing-list
>       (concat "https://yhetil.org/"
>               mailing-list "/" message-id))))
>
> (add-to-list 'notmuch-show-stash-mlarchive-link-alist
>              (cons "Yhetil" #'ambrevar/guess-yhetil-link))
> --8<---------------cut here---------------end--------------->8---

Neat!  It fails for Bugs/Patches since the addresses are
12345@debbugs.gnu.org.  So the “all-addresses” should be a bit smarter.
But, anyway because I do not use yhetil to refer to Bug/Patch but
issues.guix.gnu.org.


Cheers,
simon

Re: Workflow with mu4e + magit for sending patchsets to guix?

[Pierre Neidhardt]

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

Fixed:

--8<---------------cut here---------------start------------->8---
(defvar ambrevar/known-mailing-list-archives
  '(("help-guix@gnu.org" . "guix-user")
    ("guix-devel@gnu.org" . "guix-devel")
    ("debbugs.gnu.org" . "guix-bugs"))
  "Alist of mail adresses and their Yhetil name.
Alternatively the key may just be a host name against which a
recipient will be matched.")

(defun ambrevar/guess-yhetil-link (message-id)
  (let* ((all-addresses
          (mapcar #'second
                  (mail-extract-address-components
                   (mapconcat #'identity
                              (list
                               (notmuch-show-get-header :To)
                               (notmuch-show-get-header :Cc))
                              ", ")
                   'all)))
         (mailing-list
          (cdr (seq-find
                (lambda (pair)
                  (let ((address-or-host (car pair)))
                    (if (string-match "@" address-or-host)
                        (member address-or-host all-addresses)
                      (seq-find (lambda (address)
                                  (string-match address-or-host address))
                                all-addresses))))
                ambrevar/known-mailing-list-archives))))
    (when mailing-list
      (concat "https://yhetil.org/"
              mailing-list "/" message-id))))

(defun ambrevar/guess-yhetil-link-prefer-patches (message-id)
  (let ((ambrevar/known-mailing-list-archives
         (copy-alist
          ambrevar/known-mailing-list-archives)))
    (push '("debbugs.gnu.org" . "guix-patches")
          ambrevar/known-mailing-list-archives)
    (ambrevar/guess-yhetil-link message-id)))

(add-to-list 'notmuch-show-stash-mlarchive-link-alist
             (cons "Yhetil" #'ambrevar/guess-yhetil-link))
(add-to-list 'notmuch-show-stash-mlarchive-link-alist
             (cons "Yhetil/patches" #'ambrevar/guess-yhetil-link-prefer-patches))

(setq notmuch-show-stash-mlarchive-link-default "Yhetil")
--8<---------------cut here---------------end--------------->8---

The last line should be useful ;)

Note that I've set two entries, one that prefer guix-patches over
guix-bugs because they seem to use the same recipient domain
(debbugs.gnu.org) and I don't know how to differentiate the two.

--
Pierre Neidhardt
https://ambrevar.xyz/

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

Re: Workflow with mu4e + magit for sending patchsets to guix?

[Kyle Meyer]

Pierre Neidhardt writes:

> --8<---------------cut here---------------start------------->8---
> (defvar ambrevar/known-mailing-list-archives
>   '(("help-guix@gnu.org" . "guix-user")
>     ("guix-devel@gnu.org" . "guix-devel")
>     ("debbugs.gnu.org" . "guix-bugs"))
>   "Alist of mail adresses and their Yhetil name.
[...]

Thanks.

> Note that I've set two entries, one that prefer guix-patches over
> guix-bugs because they seem to use the same recipient domain

Eric Wong has been working on adding an "external index" to public-inbox
that allows operating on a collection of inboxes.

  https://public-inbox.org/meta/20201027075453.19163-1-e@80x24.org/
  https://public-inbox.org/meta/20201126194543.GA30337@dcvr/

The feature is still being cooked, but I got around to trying it out
this weekend, and it seems to work nicely.

Anyway, that feature helps here because it allows all Guix-related lists
to be exposed under a single inbox.  You can now construct a URL without
worrying about which particular list the message is from:

  https://yhetil.org/guix/87k0u8v42a.fsf@ambrevar.xyz

Re: Workflow with mu4e + magit for sending patchsets to guix?

[Pierre Neidhardt]

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

Ah!  That's good to know!

So here is my final, hopefully fully-functioning version then:

--8<---------------cut here---------------start------------->8---
(defvar ambrevar/known-mailing-list-archives
  '(("help-guix@gnu.org" . "guix")
    ("guix-devel@gnu.org" . "guix")
    ("debbugs.gnu.org" . "guix"))
  "Alist of mail adresses and their Yhetil name.
Alternatively the key may just be a host name against which a
recipient will be matched.")

(defun ambrevar/guess-yhetil-link (message-id)
  (let* ((all-addresses (mapcar #'second
                                (mail-extract-address-components
                                 (mapconcat #'identity
                                            (list
                                             (notmuch-show-get-header :To)
                                             (notmuch-show-get-header :Cc))
                                            ", ")
                                 'all)))
         (match-address (lambda (address-or-host)
                          (if (string-match "@" address-or-host)
                              (member address-or-host all-addresses)
                            (seq-find (lambda (address)
                                        (string-match address-or-host address))
                                      all-addresses))))
         (mailing-list (alist-get
                        (seq-find match-address
                                  (mapcar #'car ambrevar/known-mailing-list-archives))
                        ambrevar/known-mailing-list-archives
                        nil nil #'string=)))
    (when mailing-list
      (concat "https://yhetil.org/"
              mailing-list "/" message-id))))

(add-to-list 'notmuch-show-stash-mlarchive-link-alist
             (cons "Yhetil" #'ambrevar/guess-yhetil-link))

(setq notmuch-show-stash-mlarchive-link-default "Yhetil")
--8<---------------cut here---------------end--------------->8---

Cheers!

-- 
Pierre Neidhardt
https://ambrevar.xyz/

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

Re: Workflow with mu4e + magit for sending patchsets to guix?

[zimoun]

Hi Pierre,

On Tue, 01 Dec 2020 at 10:10, Pierre Neidhardt <mail@ambrevar.xyz> wrote:

> So here is my final, hopefully fully-functioning version then:

I am testing it.  Thanks!

Cheers,
simon

Re: Workflow with mu4e + magit for sending patchsets to guix?

[zimoun]

Hi Kyle,

Thank you for the detailed explanations and hints.


On Mon, 16 Nov 2020 at 21:36, Kyle Meyer <kyle@kyleam.com> wrote:

>>  4. !! send-email --to=guix-patches@gnu.org 0000-cover-letter.patch
>>  5. Wait and refresh my inbox
>>  6. !! send-email --to=12345@gnu.org 000?-*.patch
>
> Yeah, 4-6 are tricky and debbugs-specific.  For other projects, it could
> just be 'send-email *.patch' once sendemail.to is configured to point to
> the list's address.
>
> For 6, using '--no-thread --in-reply-to=...' will retain the same
> threading you'd see if you weren't using debbugs (i.e didn't have to do
> the two-step send).

[...]

> And, sadly I guess, my view is still similar to what I said there:
>
>   send-email has of course come up a number of times before (gh-1756 and
>   gh-1800 are the most relevant, I think), and tackling that requires a
>   vision that I don't really have.  Perhaps due to a lack of
>   imagination, I can't think of an implementation on Magit's side that
>   would improve the simple send-email command that I run.  In terms of
>   sending mail, the most involved thing that I need to do is get the
>   --to/--ccs and --in-reply-to from an existing thread, but in my view
>   that's outside of Magit's scope.
>
> I don't know.  Maybe I should try to think harder about it.
>
> A final note of hope: as a lurker on the notmuch list, I've noticed that
> Jonas has starting doing some patch-based contributions.  So, perhaps
> he'll get an itch and do his amazing Jonas thing.

To me, today the main annoyance is the selection of the patches at the
step #6.  For example, avoid to resend unrelated patches, as:

 - 000?-*.patch could resend the 0000-cover-letter.patch
 - *.patch could resend 0000-cover-letter.patch and 0001-Foo-bar.patch
    if I am currently sending v2-0001-Foo-bar.patch
 - any previous patchset remaining.  Recent example inside my
    guix-artwork checkout: 

--8<---------------cut here---------------start------------->8---
0000-cover-letter.patch
0001-website-Add-conference-announcement.patch
0001-website-Add-fetch-methods-to-JSON-sources-and-packag.patch
0001-website-Add-integrity-to-JSON-sources.patch
0001-website-Release-conference-schedule.patch
0001-website-Update-announce-online-Guix-days.patch
0001-website-Update-manifest.patch
tiny.patch
v2-0001-website-Add-conference-announcement.patch
v2-0001-website-Release-conference-schedule.patch
v3-0001-website-Add-conference-announcement.patch
v3-0001-website-Release-conference-schedule.patch
v4-0001-website-Add-conference-announcement.patch
v4-0001-website-Release-conference-schedule.patch
--8<---------------cut here---------------end--------------->8---


That’s why time to time I create an output directory and put the series
in.  But the 0000-cover-letter.patch (or vN-0000-cover-letter.patch) is
still annoying because it blocks the simple *.patch.  Nothing simpler
than * could be done, I see you regexp integrist. :-)


I am thinking loud.  One option (some setq) could be added to Magit
format-patch, and do under the hood:

 - create 0000-cover-letter.patch in the root directory
 - create folder v1 (default), otherwise v2 … vN and put the series
   in.

This would be configurable via Magit variables, say:

  magit-send-email-workflow t
  magit-format-patch-directory-prefix “v”
  
Then, the sequence,

  W C-m l C-m c
  W C-m v2 c
  W C-m l C-m v3 c

would produce the final tree:

  +
  +- .git
  +- 0000-cover-letter.patch
  +- v3-0000-cover-letter.patch
  +- v1
     +- 0001-Foo-Bar.patch
     …
     +- 0042-Yahoga.patch
  +- v2
     +- v2-0001-Foo-Bar.patch
     …
     +- v2-0012-Kikool.patch
  +- v3
     +- v3-0001-Foo-Bar.patch
     …
     +- v3-0021-Rock-and-roll.patch
 
This way, step #6 would become:

  !! send-email --to=12345@debbugs.gnu.org v1/*.patch

(With or without --in-reply-to, another story. :-))


All the best,
simon

Re: Workflow with mu4e + magit for sending patchsets to guix?

[Kyle Meyer]

zimoun writes:

> On Mon, 16 Nov 2020 at 21:36, Kyle Meyer <kyle@kyleam.com> wrote:
>
>>>  4. !! send-email --to=guix-patches@gnu.org 0000-cover-letter.patch
>>>  5. Wait and refresh my inbox
>>>  6. !! send-email --to=12345@gnu.org 000?-*.patch
>>
>> Yeah, 4-6 are tricky and debbugs-specific.  For other projects, it could
>> just be 'send-email *.patch' once sendemail.to is configured to point to
>> the list's address.
>>
>> For 6, using '--no-thread --in-reply-to=...' will retain the same
>> threading you'd see if you weren't using debbugs (i.e didn't have to do
>> the two-step send).
[...]
> To me, today the main annoyance is the selection of the patches at the
> step #6.  For example, avoid to resend unrelated patches, as:
>
>  - 000?-*.patch could resend the 0000-cover-letter.patch
>  - *.patch could resend 0000-cover-letter.patch and 0001-Foo-bar.patch
>     if I am currently sending v2-0001-Foo-bar.patch
>  - any previous patchset remaining.

Yeah, I agree about that being the most annoying aspect, but I'd say
that core problem comes from the need for a two-step send.  That's a
quirky enough divergence from the standard workflow that I think any
solution/helper here is unlikely to be in the scope of Magit.  But that
doesn't mean I don't think it'd be nice to come up with a helper.

> Recent example inside my
>     guix-artwork checkout: 
> --8<---------------cut here---------------start------------->8---
> 0000-cover-letter.patch
> 0001-website-Add-conference-announcement.patch
[...]
> 0001-website-Update-manifest.patch
> tiny.patch
> v2-0001-website-Add-conference-announcement.patch
[...]
> v4-0001-website-Release-conference-schedule.patch
> --8<---------------cut here---------------end--------------->8---
>
> That’s why time to time I create an output directory and put the series
> in.  But the 0000-cover-letter.patch (or vN-0000-cover-letter.patch) is
> still annoying because it blocks the simple *.patch.  Nothing simpler
> than * could be done, I see you regexp integrist. :-)

Yeah, I'd guess a directory per topic and version is pretty common to
make selecting the patches simply DIR/* (again, assuming a normal
one-step send-email process).

> I am thinking loud.  One option (some setq) could be added to Magit
> format-patch, and do under the hood:
>
>  - create 0000-cover-letter.patch in the root directory
>  - create folder v1 (default), otherwise v2 … vN and put the series
>    in.
>
> This would be configurable via Magit variables, say:
>
>   magit-send-email-workflow t
>   magit-format-patch-directory-prefix “v”

As I said, I'm not sold on this being something that fits Magit proper,
but I'll help write a helper :)

> Then, the sequence,
>
>   W C-m l C-m c
>   W C-m v2 c
>   W C-m l C-m v3 c
>
> would produce the final tree:
>
>   +
>   +- .git
>   +- 0000-cover-letter.patch
>   +- v3-0000-cover-letter.patch
>   +- v1
>      +- 0001-Foo-Bar.patch

Here's a command that gets you close to that layout.  It adds an
additional "<name>/" directory on top of the structure you show above.
The name is reads from the caller (with a default completion value of
the current branch name).  It also depends on the caller having an
upstream branch set (which I think is a good thing), but you could
rework it to avoid it.

--8<---------------cut here---------------start------------->8---
(defun my/magit-patch-create-split-directory (name &optional args files)
  "Create patches in a split layout.

Call `git format-patch ARGS -- FILES`, splitting the cover letter
off from the main patches.  A standard format-patch calls creates
a layout like

   0000-cover-letter.patch
   0001-commit-1-subj.patch
   0002-commit-2-subj.patch
   ...

in the directory specified by `--output-directory=' or the
current directory.

This command expands the structure as

  NAME
  |-- 0000-cover-letter.patch
  `-- vN
      |-- 0001-commit-1-subj.patch
      |-- 0002-commit-1-subj.patch

where NAME is a name for the series and N is the version
specified via `--reroll-count='.  The cover letter will have a
\"vN-\" prefix after the first version.

The motivation for the above layout is to make it easier to send
the cover letter to a Debbugs list and, once a bug number is
assigned, follow up with the remaining patches:

  $ git send-email --to=$debbugs-list NAME/0000-cover-letter.patch
  $ # [ wait for mail ]
  $ git send-email --to=$bug-address-from-mail \\
    --in-reply-to=$cover-letter-message-id --no-thread NAME/vN/*"
  (interactive (cons (read-string "Series name: "
                                  nil nil (magit-get-current-branch))
                     (let ((args (transient-args 'magit-patch-create)))
                       (list (seq-filter #'stringp args)
                             (cdr (assoc "--" args))))))
  (let* ((upstream (or (magit-get-upstream-branch)
                       (user-error "No upstream branch")))
         (version
          (or (seq-some
               (lambda (arg)
                 (and (string-match "\\`--reroll-count=\\(.+\\)" arg)
                      (format "v%s" (match-string 1 arg))))
               args)
              "v1"))
         (dir
          (file-name-as-directory
           (expand-file-name
            name
            (or (seq-some
                 (lambda (arg)
                   (and (string-match "\\`--output-directory=\\(.+\\)"
                                      arg)
                        (expand-file-name (match-string 1 arg))))
                 args)))))
         (vdir (concat dir version)))
    (when (file-exists-p vdir)
      (user-error "Directory already exists: %s" vdir))
    (magit-run-git "format-patch" upstream
                   (concat "--output-directory=" vdir)
                   (seq-remove
                    (lambda (arg)
                      (string-match-p "\\`--output-directory=" arg))
                    args)
                   "--" files)
    (let ((cover (or (car (directory-files
                           vdir t
                           (rx string-start
                               (zero-or-one "v" (one-or-more digit) "-")
                               (one-or-more "0") "-cover-letter.patch")))
                     (error "No cover letter found"))))
      (rename-file cover (concat dir (file-name-nondirectory cover))))))

(transient-append-suffix 'magit-patch-create "c"
  '("s" "Split directory" my/magit-patch-create-split-directory))
--8<---------------cut here---------------end--------------->8---

Re: Workflow with mu4e + magit for sending patchsets to guix?

[zimoun]

Hi,

On Tue, 17 Nov 2020 at 23:55, Kyle Meyer <kyle@kyleam.com> wrote:

>>>>  4. !! send-email --to=guix-patches@gnu.org 0000-cover-letter.patch
>>>>  5. Wait and refresh my inbox
>>>>  6. !! send-email --to=12345@gnu.org 000?-*.patch

[...]

>> To me, today the main annoyance is the selection of the patches at the
>> step #6.  For example, avoid to resend unrelated patches, as:

[...]

> Yeah, I agree about that being the most annoying aspect, but I'd say
> that core problem comes from the need for a two-step send.  That's a
> quirky enough divergence from the standard workflow that I think any
> solution/helper here is unlikely to be in the scope of Magit.  But that
> doesn't mean I don't think it'd be nice to come up with a helper.

[...]

> As I said, I'm not sold on this being something that fits Magit proper,
> but I'll help write a helper :)

Instead of Magit, maybe the helper should be in Emacs-Guix.

> Here's a command that gets you close to that layout.  It adds an
> additional "<name>/" directory on top of the structure you show above.
> The name is reads from the caller (with a default completion value of
> the current branch name).  It also depends on the caller having an
> upstream branch set (which I think is a good thing), but you could
> rework it to avoid it.
>
> --8<---------------cut here---------------start------------->8---
> (defun my/magit-patch-create-split-directory (name &optional args files)
>   "Create patches in a split layout.

Awesome!  Thank you.  I am going to add to my config and see how it is
going. :-)


> (transient-append-suffix 'magit-patch-create "c"
>   '("s" "Split directory" my/magit-patch-create-split-directory))
> --8<---------------cut here---------------end--------------->8---

Yeah, you are right, it seems better that way than being part of Magit
proper.


Thanks,
simon

Re: Workflow with mu4e + magit for sending patchsets to guix?

[Kyle Meyer]

Kyle Meyer writes:

>>     C-m l
>
> If you follow the convention of writing a cover letter only for
> multi-patch series, you can drop the 'C-m l' because by default git will
> generate a cover letter when there is more than one commit.

Sorry, I was mistaken: generating a cover letter for a multi-patch
series is _not_ git's default behavior.  That requires setting
format.coverLetter to "auto" in your git configuration.