Re: Adopt a patch!

[Maxim Cournoyer <maxim.cournoyer@gmail.com>]

Hi Thomas,

Thomas Danckaert <post@thomasdanckaert.be> writes:

> I don't mind the e-mail-based workflow in principle, and find it has
> some advantages, but there are a few practical issues.  I'll list my
> frustrations, maybe there are concrete solutions for some of them:
>
>  - I find that saving a long patch series from a bunch of e-mails, and
>    applying them all to a local git checkout is tedious, with a lot of
>    potential to miss a patch, apply a wrong one, or otherwise screw up
>    (not to mention patches occasionally get mangled somewhere in the
>    e-mail pipeline, so git won't apply them).  Also, sometimes patches
>    are in the message body, at other times they are attachments,
>    ... It *is* a lot of error-prone manual work, compared to just
>    fetching a branch with git.  I think this is where the “glossy
>    interfaces of Github & co.” do have an advantage.
>
>    Perhaps there are better ways to deal with this, though... Am I
>    missing some tricks to easily retrieve a bunch of patches from
>    e-mails, and apply them?  Maybe a tutorial by someone who finds the
>    current workflow comfortable, could already help.

In Gnus, with the cursor on the body of a message, you can pipe the
patch-in-body using the `|' shortcut or M-x gnus-summary-pipe-output and
then giving it the command "git am -s" as Ludovic pointed out some time
ago. It works the same if you place the cursor on a MIME (attachment)
object. You can also apply multiple patches in a row by giving it a
prefix argument (e.g. C-u N |) to apply N patches from N messages
(haven't tried that one yet but it's documented, see C-h f
gnus-summary-pipe-output).

I intend to script this method in Elisp so that would deal with both
types of patches (in-body/as-attachment) transparently but haven't
gotten around it just yet. I packaged the very old emacs-dvc thinking it
could help in doing that but it doesn't, so haven't bothered releasing
it.

> The other issue is that, in my opinion, the only user-friendly way to
> interact with debbugs, is using emacs + debbugs-gnu, once you are
> familiar with both.  I think that's a really high barrier.
>
> - I briefly subscribed to the guix-patches mailing list, but found the
>   volume of e-mail much too high.
> - That leaves debbugs.  I find the web interface quite terrible, it's
>    just walls of text you have to find your way through. For example,
>    Github's “issues” are much more readable (and you can interact with
>    them via e-mail, too).
> - The debbugs emacs interface is quite ok (at least there's a threaded
>   conversation view), although now you have to learn to use Gnus if
>   you want to participate in the conversation.

I can highly recommend Gnus to get some hold of high mailing list
traffic. Expiry is a nifty way to storm through the mails, and there's
always the last resort 'c' catchup that will put you back on top of
things after coming back from a long weekend.

Maxim