Re: [Chicken-hackers] [PATCH] ##sys#read: don't drop first character of octal escape in error msg

[Peter Bex]

On Sun, Mar 17, 2013 at 01:56:23PM +0100, Florian Zumbiehl wrote:
> > Florian, I'd really appreciate it if you could attach your patches
> > instead of putting them inline in your mail.  Your patches are the
> > only ones that are different, breaking the standard workflow I use
> > when dealing with patches from chicken-core.
> 
> Would what git format-patch's --attach produces help you? Not sure whether
> that actually would work with my workflow, but I could try it ...

I don't know what that will do, but maybe you can give it a try on your
next patch.  As long as it produces an email that looks like everyone
else's, it should be fine.

> I really don't intend to make life difficult for you, but it's just so
> convenient to have git format-patch produce a bunch of files and then call
> mutt -H on them, optionally add some non-commit-message comment, and send
> it, with automatic threading and all, much less hassle than putting each
> mail together manually from multiple pieces, and much less risk of screwing
> things up as well.

Creating one thread with four messages results in a jumble of mostly
unrelated messages as different messages create different discussions,
see your recent set of mails starting with message ID
<address@hidden>.
I find this rather confusing.  I've set up threading in my mailer, but if
they're individual top-level threads I find it easier to follow than deeply
nested discussions.  I can only guess how messy it would look to people
using less capable software (like gmail's horrid interface, for example).

> Plus, the mails are exactly the format you seem to expect as an attachment,
> so I would expect you should be able to just feed the whole mail into your
> process instead of just the attachment? Presumably, you are using git am?

Yeah.  Still, the workflow is slightly different than usual.

> Also, apart from the compatibility of our two processes: IMO it's good and
> useful that the diff format is a plain text format and one should take
> advantage of it. The diffs really are an important part of the message that
> should be easy to quote and comment on. And that should be readily
> accessible when reading the mail, which applies even more so for the commit
> message. Attaching patches to patch mails strikes me a bit like attaching
> word documents to otherwise almost empty "letter emails".

If you take a look at our workflow and other people's mail, you'll see
that we generally try to include a written description of why the patch
is required and how it works, and possibly some remaining questions for
consideration of the reviewer.

This is too much verbiage for a commit message and does not really
belong there anyway; the commit message can be a shorter and more
to-the-point.  By sending it inline, you lose the opportunity of adding
an explanation, and I guess you'd have to send a separate mail with
the explanation, or a mail saying "I'm going to send you a patch soon",
which is equally clumsy as the "letter emails" you mentioned.

I also have no idea how to send an improved patch with feedback on the
original patch without that feedback ending up in the commit message,
without a Ph.D in git.  Attaching the patch avoids these problems.

Cheers,
Peter
-- 
http://www.more-magic.net