unofficial mirror of help-guix@gnu.org 
 help / color / mirror / Atom feed
From: Kyle Meyer <kyle@kyleam.com>
To: zimoun <zimon.toutoune@gmail.com>
Cc: help-guix@gnu.org
Subject: Re: Workflow with mu4e + magit for sending patchsets to guix?
Date: Tue, 17 Nov 2020 23:55:55 -0500	[thread overview]
Message-ID: <87eekr461w.fsf@kyleam.com> (raw)
In-Reply-To: <86wnykni2v.fsf@gmail.com>

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



  reply	other threads:[~2020-11-18  4:56 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-16 20:28 Workflow with mu4e + magit for sending patchsets to guix? Christopher Lemmer Webber
2020-11-16 20:48 ` Christopher Baines
2020-11-16 23:49 ` zimoun
2020-11-17  2:36   ` Kyle Meyer
2020-11-17  7:28     ` Pierre Neidhardt
2020-11-17 14:10       ` zimoun
2020-11-25  9:19         ` Pierre Neidhardt
2020-11-25 12:33           ` zimoun
2020-11-26  9:51             ` Pierre Neidhardt
2020-11-30 22:30               ` Kyle Meyer
2020-12-01  9:10                 ` Pierre Neidhardt
2020-12-01 16:26                   ` zimoun
2020-11-17 15:01     ` zimoun
2020-11-18  4:55       ` Kyle Meyer [this message]
2020-11-18  8:17         ` zimoun
2020-11-17 15:39     ` Kyle Meyer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87eekr461w.fsf@kyleam.com \
    --to=kyle@kyleam.com \
    --cc=help-guix@gnu.org \
    --cc=zimon.toutoune@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).