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

On Wed, 27 Jun 2007, Jim Meyering wrote:

The thing is, I don't think stdio output is "important" enough.

In fact, by definition, if the data was really important, it had better not use stdio.

So look at where git uses "real" IO, and where it uses stdio, and you'll see where the "diagnostics" matter.

In other words, the diagnostics matter for:
 - the actual git database (including refs).
 - doing things like "git checkout" that writes the working tree

Those are the ones where we want to *guarantee* correctness. And that means that they don't use stdio (and if any of them do, then that really *is* a bug, and should be fixed asap)

In contrast, if you redirect stdout, that's a totally different level of correctness, and all bets are off. Exactly because we use stdio. If we really cared, we shouldn't use stdio.

Right. There's a difference between an email saying "ok, this is how you might want to do it" and then actually sitting down and thinking about it and coding it.

If you look closer, you'll notice that my initial suggestion wouldn't even *compile*.

By the time I sent out a patch, I had actually thought it through.

And no, I don't guarantee that I do that all the time. I try to, but hey, mistakes happen. It's when the mistake is repeated over and over after being pointed out that I get irritated.

Quite frankly, the tools you maintain are mostly filters in the first place! In other words, for you, stdout *matters*. That's the real data!

But look at something like "cp" one of these days, and ask yourself: 

 - do you check error returns for the IO operations that actually do the 
   copy (I hope yes). 

   I also hope to high heaven that you would never use stdio for that IO. 
   Because you *will* lose error information!

 - do you check the error returns of informational messages like the ones 
   from the verbose output switch (cp -v).

If you answered "no" to the second question, you should really think about that fact. Please realize that there's a *huge* difference in error checking between "core data" and "random information".

For something like "cat", the core data is the actual stream. You care a lot more about that. For git, the core data is the working tree and the database. I care about _that_. That's the stuff that should be protected and must never _ever_ fail silently.

The rest is really "statistics".

Let's get it right, but unlike core data, that's mostly a politeness issue, much less important than "oops, we just corrupted your archive".

And when we talk about politeness, avoiding the _idiotic_ error messages 
like "Broken pipe" is a big part of it! The "Broken pipe" message means 
either:
 - the receiver already got everything he wanted (and you should damn well 
   shut up about it)
 - the receiver had some problem (and it's damn well *that* which matters, 
   since the sender was fine, and you shouldn't confuse the issue by 
   writing bogus error messages)

The fact that you have some broken POSIX spec to worry about is not git's problem. I hold git to higher standards.

		Linus