Hi Kyle,
Thank you for the detailed explanations and hints.
On Mon, 16 Nov 2020 at 21:36, Kyle Meyer <k...@kyleam.com> wrote:
>> 4. !! send-email --to=guix-patc...@gnu.org 0000-cover-letter.patch
>> 5. Wait and refresh my inbox
>> 6. !! send-email --to=12...@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=12...@debbugs.gnu.org v1/*.patch
(With or without --in-reply-to, another story. :-))
All the best,
simon
