Re: [RFC PATCH 0/5] Localise error headers

From: Jeff King <peff@peff.net>
Date: Jan 21, 2017, 14:24 UTC
Message-ID: <20170121142455.qoyqagaw4atic5n6@sigill.intra.peff.net>
In-Reply-To: <CAGZ79kYVFbaMy1_-6qqe9zYQyktE2-7xu1Zz_qyeLWK=scgFKQ@mail.gmail.com>

On Wed, Jan 11, 2017 at 09:15:22AM -0800, Stefan Beller wrote:

Show 12 quoted lines

> > That's the assumption I'm challenging. Certainly the behavior and
> > certain aspects of the output of a plumbing command should remain the
> > same over time. But error messages to stderr?
> 
> In an ideal world that assumption would hold true and any machine
> readable information from the plumbing commands are on stdout and
> nobody in their sane mind would ever try to parse stderr.
> 
> There is no easy way to check though except auditing all the code.
> Having pointed out some string handling mistakes in the prior email,
> my confidence is not high that plumbing commands are that strict about
> separating useful machine output and errors for human consumption.

I think it's impossible to audit all the code, because "all the code" includes things not in git itself. It would really take a willingness to declare "if you are parsing stderr you're doing it wrong".

I suppose the unpack-trees example speaks against that. I'm not sure that is sane overall, but it is something we tried to account for in the past.

If we are just talking about translation, though, it seems like the right action for a script that really wants to parse stderr is to run the sub-command with LC_MESSAGES=C. I know that's a breaking change, but I wonder if it's a reasonable path forward.

-Peff