Re: [PATCH 1/2] status: really ignore config with --porcelain

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 24, 2013, 14:55 UTC
Message-ID: <7v8v1zd0du.fsf@alter.siamese.dyndns.org>
In-Reply-To: <vpqhagnwraj.fsf@anie.imag.fr>

Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:

> I really don't like this. If we go for a solution looking explicitely at
> argv[], we should at least iterate over it (also not satisfactory
> because --porcelain could be the argument of another switch).

Ram, thanks for a report.

I won't comment on what is the correct way to see if "--porcelain" is given by the caller before I have enough time to think about it, but we did read configurattion even when "--porcelain"is given before the topic was merged, and I think it was done for a good reason.

Configuration related to the output format (like color=always) must be ignored under "--porcelain", but if we do not read core-ish configuration variables (e.g. core.crlf) that affect the logic to list what is changed what is not, we would not give the right result, no?

So checking "--porcelain" option and skipping configuration may not be a solution but merely trading one regression with another.

For now, I'll revert the merge and see if people can come up with a reasonable way forward. My knee-jerk reaction is that, because the "--porcelain" output was designed to be extensible and scripts reading from it is expected to ignore what it does not understand, if the setting of status.branch is a problem, the reading side is buggy and needs to be fixed.

Do we have in-core reader that does not behave well when one or both of these configuration variables are set (perhaps something related to submodule?)???