Re: [PATCH] git-version-gen: include command name in one more diagnostic

[Jim Meyering]

Bruce Korb wrote:
> Hi Jim,
>
> On 01/03/11 07:17, Jim Meyering wrote:
>> I now see that your patch ... combined stderr with the potentially
>> mangled output from a failing "cat" command,...
>>
>> Also, while it's not likely that the file is missing at that point,
>> it is possible, since there is a race condition.
>
> And if the file contains trash exclusive of 0x0A and starts with
> 0x30 through 0x39 then you'll get hosed, too.  You have to make
> a trade off between programming complexity and usefulness.
> If "cat" has a read error, the most likely output will be only
> to stderr and you won't have junk.  "cat" would have to use
> multiple reads before it would emit junk data before printing
> an error message.  It would not make particular sense to read
> line-at-a-time.
>
> This whole series of emails came about because some GIT command
> emitted a fatal error message to stderr, git-version-gen ignored

Did you determine which git command failed and why?

The only git commands that git-version-gen should be running
these days are git describe (it runs git rev-list only to accommodate
very old versions of git), git update-index, and git diff-index.

> the "fatal" error and I was left wondering what happened.
> Perhaps the real "best" solution would be to divert all stderr
> to a temp file.  It would be printed out on real failure and
> otherwise simply removed.

I would prefer to keep git-version-gen simple, and using a temporary
file would induce disproportionate complexity (having to portably
do something like mktemp and having to clean up e.g., upon interrupt).

> I'll supply that patch, if you like.
> Is it okay to use the post-1977 concept of a shell function?
> Even the Solaris /bin/sh supports it .....

Yes, it inherits portability constraints from configure,
which now uses shell functions.