Jeff King <peff@xxxxxxxx> writes: > I know this is not strictly a bugfix and we are in -rc, but: > > 1. It is an enhancement to a previously unreleased feature, and > shouldn't affect anything outside of that. > > 2. It affects the scripting interface to textconv, so I would like to > get it in before textconv is ever released so that it is always the > "right way" to turn text conversion off or on. I'd agree with #1, especially if you said "doesn't" instead of "shouldn't". But I am not 100% sure if the scripting part is "the right way". If a script wants to take whatever Porcelain users are happy as the "presentation for human consumption" and pass that through as its own output to the end user, maybe it is better off reading from Porcelain, instead of reading from the plumbing (the latter of which requires making the plumbing output less reliable)? When we later enhance textconv output from the "diff" Porcelain to benefit interactive users, it will automatically help the script that passes through the "diff" output to the end users. You can certainly argue that this "textconv" feature that is grafted from Porcelain into plumbing is a special case in that its output is subject to change any time to help human consumption and we never strive for its stability as we do for other features in the plumbing to support machine readability by scripts. You can propagate the later enhancement of textconv diff output we'd make for Porcelain to the scripted users that reads from the plumbing that way. But then wouldn't it be the same for these scripts that do value the "presentation meant for human consumption" over "machine readability" to read from Porcelain? That would not have to blur the distinction between the Porcelain and plumbing like the approach you are suggesting here. -- 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
