Re: [PATCH 25/25] Fix stdout stream grabbing in format_part_content_text

Subject: Re: [PATCH 25/25] Fix stdout stream grabbing in format_part_content_text

Date: Fri, 03 Jun 2011 12:56:50 -0700

To: Jameson Graef Rollins, Notmuch Mail

Cc:

From: Carl Worth


On Sat, 28 May 2011 14:52:00 -0700, Jameson Graef Rollins <jrollins@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
part-000.sig (application/pgp-signature)

Thread: