[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: |
Mon, 16 Nov 2020 21:36:18 -0500 |
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.
- Workflow with mu4e + magit for sending patchsets to guix?, Christopher Lemmer Webber, 2020/11/16
- 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 <=
- 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, 2020/11/17
- 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