Matthieu Moy <matthieu....@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
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
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 unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html