Re: [PATCH] git-rev-list: give better diagnostic for failed write

Linus Torvalds [off-list ref] wrote:

On Mon, 25 Jun 2007, Jim Meyering wrote:

quoted

Remember: I'm trying to improve existing code here.
You should save some of your ire for the person who wrote that code.

Ehh. Remind me who I should be pissed at when the old code was _better_
before your change?

If someone pointed out a bug in coreutils whereby a tool failed
to give an accurate diagnostic, I would thank them (and honestly,
I'd be grateful), even if their attempt at fixing it introduced
a horrible bug.  Of course, if the original bug were mine, I might
be annoyed with myself, but certainly would not shoot the messenger.

With the current git.c, we report write errors quite well.

Yes, I'm glad (in spite of the tone of much of your feedback)
that my little improvements are making it into git.

We don't give
the exact output you want, but on a scale of 1-10, how important is that?
Pretty damn low on the list.

If you get a report of a git write error, you might well
appreciate knowing right away whether it was due to EIO or to ENOSPC.

And the reason I'm really really irritated at you is that you ignore me
when I tell you what your bugs are.

Be careful when throwing stones...
I mentioned (without making a fuss) a regression you introduced,
  http://thread.gmane.org/gmane.comp.version-control.git/50742/focus=50917
and you included similar code in a snippet in the very message to which
I'm replying now.  I do see that you omitted the troublesome ferror call
from your eventual patch.

 - I *told* you that EPIPE is special. What did you do? Ignore my advice,
   and made a broken patch that did exactly the opposite of what I told
   you.

I did not ignore your advice.  I considered it carefully and explained
why I hold the opposing view.  We've already beaten this to death, but
for the record, I'd summarize it like this:

You and I have a difference of opinion.  I firmly believe that it is
unnecessary and counterproductive (it is prohibited by POSIX for many
of the tools I maintain) to suppress an EPIPE diagnostic and to exit
successfully in spite of a write error.  Since EPIPE doesn't even arise
in most normal situations, the only reason to do that is if you want
to pander to the needs of some theoretical, broken-by-design (i.e.,
SIGPIPE-ignoring) git Porcelain program.  You want to add such code to
git, at every point where writing to stdout may fail.