* Workflow with mu4e + magit for sending patchsets to guix? @ 2020-11-16 20:28 Christopher Lemmer Webber 2020-11-16 20:48 ` Christopher Baines 2020-11-16 23:49 ` zimoun 0 siblings, 2 replies; 16+ messages in thread From: Christopher Lemmer Webber @ 2020-11-16 20:28 UTC (permalink / raw) To: help-guix 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Workflow with mu4e + magit for sending patchsets to guix? 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 1 sibling, 0 replies; 16+ messages in thread From: Christopher Baines @ 2020-11-16 20:48 UTC (permalink / raw) To: Christopher Lemmer Webber; +Cc: help-guix [-- 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 --] ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Workflow with mu4e + magit for sending patchsets to guix? 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 1 sibling, 1 reply; 16+ messages in thread From: zimoun @ 2020-11-16 23:49 UTC (permalink / raw) To: Christopher Lemmer Webber, help-guix; +Cc: Kyle Meyer 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> ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Workflow with mu4e + magit for sending patchsets to guix? 2020-11-16 23:49 ` zimoun @ 2020-11-17 2:36 ` Kyle Meyer 2020-11-17 7:28 ` Pierre Neidhardt ` (2 more replies) 0 siblings, 3 replies; 16+ messages in thread From: Kyle Meyer @ 2020-11-17 2:36 UTC (permalink / raw) To: zimoun; +Cc: help-guix 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. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Workflow with mu4e + magit for sending patchsets to guix? 2020-11-17 2:36 ` Kyle Meyer @ 2020-11-17 7:28 ` Pierre Neidhardt 2020-11-17 14:10 ` zimoun 2020-11-17 15:01 ` zimoun 2020-11-17 15:39 ` Kyle Meyer 2 siblings, 1 reply; 16+ messages in thread From: Pierre Neidhardt @ 2020-11-17 7:28 UTC (permalink / raw) To: Kyle Meyer, zimoun; +Cc: help-guix [-- 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 --] ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Workflow with mu4e + magit for sending patchsets to guix? 2020-11-17 7:28 ` Pierre Neidhardt @ 2020-11-17 14:10 ` zimoun 2020-11-25 9:19 ` Pierre Neidhardt 0 siblings, 1 reply; 16+ messages in thread From: zimoun @ 2020-11-17 14:10 UTC (permalink / raw) To: Pierre Neidhardt, Kyle Meyer; +Cc: help-guix 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Workflow with mu4e + magit for sending patchsets to guix? 2020-11-17 14:10 ` zimoun @ 2020-11-25 9:19 ` Pierre Neidhardt 2020-11-25 12:33 ` zimoun 0 siblings, 1 reply; 16+ messages in thread From: Pierre Neidhardt @ 2020-11-25 9:19 UTC (permalink / raw) To: zimoun, Kyle Meyer; +Cc: help-guix [-- 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 --] ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Workflow with mu4e + magit for sending patchsets to guix? 2020-11-25 9:19 ` Pierre Neidhardt @ 2020-11-25 12:33 ` zimoun 2020-11-26 9:51 ` Pierre Neidhardt 0 siblings, 1 reply; 16+ messages in thread From: zimoun @ 2020-11-25 12:33 UTC (permalink / raw) To: Pierre Neidhardt, Kyle Meyer; +Cc: help-guix 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Workflow with mu4e + magit for sending patchsets to guix? 2020-11-25 12:33 ` zimoun @ 2020-11-26 9:51 ` Pierre Neidhardt 2020-11-30 22:30 ` Kyle Meyer 0 siblings, 1 reply; 16+ messages in thread From: Pierre Neidhardt @ 2020-11-26 9:51 UTC (permalink / raw) To: zimoun, Kyle Meyer; +Cc: help-guix [-- 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 --] ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Workflow with mu4e + magit for sending patchsets to guix? 2020-11-26 9:51 ` Pierre Neidhardt @ 2020-11-30 22:30 ` Kyle Meyer 2020-12-01 9:10 ` Pierre Neidhardt 0 siblings, 1 reply; 16+ messages in thread From: Kyle Meyer @ 2020-11-30 22:30 UTC (permalink / raw) To: Pierre Neidhardt; +Cc: help-guix 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Workflow with mu4e + magit for sending patchsets to guix? 2020-11-30 22:30 ` Kyle Meyer @ 2020-12-01 9:10 ` Pierre Neidhardt 2020-12-01 16:26 ` zimoun 0 siblings, 1 reply; 16+ messages in thread From: Pierre Neidhardt @ 2020-12-01 9:10 UTC (permalink / raw) To: Kyle Meyer; +Cc: help-guix [-- 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 --] ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Workflow with mu4e + magit for sending patchsets to guix? 2020-12-01 9:10 ` Pierre Neidhardt @ 2020-12-01 16:26 ` zimoun 0 siblings, 0 replies; 16+ messages in thread From: zimoun @ 2020-12-01 16:26 UTC (permalink / raw) To: Pierre Neidhardt, Kyle Meyer; +Cc: help-guix 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Workflow with mu4e + magit for sending patchsets to guix? 2020-11-17 2:36 ` Kyle Meyer 2020-11-17 7:28 ` Pierre Neidhardt @ 2020-11-17 15:01 ` zimoun 2020-11-18 4:55 ` Kyle Meyer 2020-11-17 15:39 ` Kyle Meyer 2 siblings, 1 reply; 16+ messages in thread From: zimoun @ 2020-11-17 15:01 UTC (permalink / raw) To: Kyle Meyer; +Cc: help-guix 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Workflow with mu4e + magit for sending patchsets to guix? 2020-11-17 15:01 ` zimoun @ 2020-11-18 4:55 ` Kyle Meyer 2020-11-18 8:17 ` zimoun 0 siblings, 1 reply; 16+ messages in thread From: Kyle Meyer @ 2020-11-18 4:55 UTC (permalink / raw) To: zimoun; +Cc: help-guix 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--- ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Workflow with mu4e + magit for sending patchsets to guix? 2020-11-18 4:55 ` Kyle Meyer @ 2020-11-18 8:17 ` zimoun 0 siblings, 0 replies; 16+ messages in thread From: zimoun @ 2020-11-18 8:17 UTC (permalink / raw) To: Kyle Meyer; +Cc: help-guix 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Workflow with mu4e + magit for sending patchsets to guix? 2020-11-17 2:36 ` Kyle Meyer 2020-11-17 7:28 ` Pierre Neidhardt 2020-11-17 15:01 ` zimoun @ 2020-11-17 15:39 ` Kyle Meyer 2 siblings, 0 replies; 16+ messages in thread From: Kyle Meyer @ 2020-11-17 15:39 UTC (permalink / raw) To: zimoun; +Cc: help-guix 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. ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2020-12-01 16:34 UTC | newest] Thread overview: 16+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 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 2020-11-18 8:17 ` zimoun 2020-11-17 15:39 ` Kyle Meyer
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/guix.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.