On Sat, 28 May 2011 14:52:00 -0700, Jameson Graef Rollins <jrollins at finestructure.net> wrote: > The declaration of the GMimeStream pointer to stdout in > format_part_content_text was somehow preventing subsequent printf > calls from outputting to stdout if the output was redirected to a > file. Scoping the declaration to the actual use of the stream pointer > works around this problem.
This commit message sounds like we don't actually understand the problem being fixed here. I'd like to investigate this more. Perhaps with a test case? Otherwise, the patches up to this point in the thread have all either been pushed or I've asked for some additional information (perhaps that's just this patch and the "old style fcc dirs" patch?). I'll continue to work through my patch queue as contained in email messages. I'm finding it easier to do that (and just piping the patches I like to "git am") as opposed to working through a release-candidate branch in git, (and having to keep rebasing/postponing it after I reject some patch in the series). I'm actually a bit surprised to see myself preferring patches in email. When Linus first wrote git, I couldn't understand why the Linux community kept to such a consistent culture of sending patches via email. It seemed so backwards to do these awkward machinations (git format-patch, git send-email, SMTP, MUA, git am), and risk all the problems of email clients corrupting patches, etc.?especially when git has such clean mechanisms for reliably moving patches around (git push, git pull). Call me converted. Email really is the right way to do collaborative code development. -Carl -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20110603/48e88dcd/attachment.pgp>