[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Workflow with mu4e + magit for sending patchsets to guix?
From: |
Kyle Meyer |
Subject: |
Re: Workflow with mu4e + magit for sending patchsets to guix? |
Date: |
Tue, 17 Nov 2020 23:55:55 -0500 |
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?, (continued)
- Re: Workflow with mu4e + magit for sending patchsets to guix?, Christopher Baines, 2020/11/16
- Re: Workflow with mu4e + magit for sending patchsets to guix?, zimoun, 2020/11/16
- Re: Workflow with mu4e + magit for sending patchsets to guix?, Kyle Meyer, 2020/11/16
- Re: Workflow with mu4e + magit for sending patchsets to guix?, Pierre Neidhardt, 2020/11/17
- Re: Workflow with mu4e + magit for sending patchsets to guix?, zimoun, 2020/11/17
- Re: Workflow with mu4e + magit for sending patchsets to guix?, Pierre Neidhardt, 2020/11/25
- Re: Workflow with mu4e + magit for sending patchsets to guix?, zimoun, 2020/11/25
- Re: Workflow with mu4e + magit for sending patchsets to guix?, Pierre Neidhardt, 2020/11/26
- Re: Workflow with mu4e + magit for sending patchsets to guix?, Kyle Meyer, 2020/11/30
- Re: Workflow with mu4e + magit for sending patchsets to guix?, zimoun, 2020/11/17
- Re: Workflow with mu4e + magit for sending patchsets to guix?,
Kyle Meyer <=
- Re: Workflow with mu4e + magit for sending patchsets to guix?, zimoun, 2020/11/18
- Re: Workflow with mu4e + magit for sending patchsets to guix?, Kyle Meyer, 2020/11/17