Junio C Hamano wrote: > 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? Ah, ofcourse. My stupidity. > 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. Are you 100% sure about this? --porcelain:: Give the output in an easy-to-parse format for scripts. This is similar to the short output, but will remain stable across Git versions and regardless of user configuration. See below for details. status.branch is an exception, no doubt: it just adds one line clearly prefixed with "##" to the beginning, and any script can ignore it easily. > 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?)??? Yeah, the submodule.c parser is very naively written (see submodule.c:737), and I can fix it. But the bigger question still remains: if we have such a non-robust parser in git.git itself, wouldn't you expect external parsers to be even worse? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html