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 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?)??? -- 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
