chicken-hackers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-hackers] [PATCH] ##sys#read: don't drop first character of


From: Florian Zumbiehl
Subject: Re: [Chicken-hackers] [PATCH] ##sys#read: don't drop first character of octal escape in error msg
Date: Sun, 17 Mar 2013 18:25:22 +0100
User-agent: Mutt/1.5.20 (2009-06-14)

Hi,

> > 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.

It attaches the patch but leaves the commit message inline (assuming mutt
manages to use that as a template) ...

> 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

Well, the point of it is to group related changes. I may not have been
totally consistent with that, but that's at least the idea--in particular
to indicate changes that depend on one another and should be applied in
order. Not quite optimal, but unfortunately email does not provide any
"sequence of related threads" semantics, so I guess that's what one has to
work with. But I certainly could split things up a bit more where there
aren't any real dependencies.

> nested discussions.  I can only guess how messy it would look to people
> using less capable software (like gmail's horrid interface, for example).

Well, if someone chooses a horrid interface for their email, why should I
destroy the experience they have carefully selected according to their
taste?

> > 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.

How do you create patch mails? Anything easier than composing them
manually?

> 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

I would think the first two points are actually good to include in the
commit message. Anything that can help you with understanding the change
that you end up at after a bisect is good to put into the commit message
(within limits ... ;-).

> 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.

Well, yeah, that really would be bad, if it were true ;-)

You can add non-commit-message comments after the --- line, where git also
puts the diffstat, which also gets dropped by git am. As I have done in a
number of my patch mails, BTW.

> 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.

You can give git format-patch the message ID that you want to reply to
(--in-reply-to) and then send the resulting file using mutt -H as usual,
inserting your feedback after the --- line in mutt's edit step.

Whether reading man git-format-patch and man git-am earns you a PhD in
gitology is for you to decide, I guess ;-)

Regards, Florian



reply via email to

[Prev in Thread] Current Thread [Next in Thread]