Junio C Hamano <gitster@xxxxxxxxx> writes: > I am not yet sure if it makes sense to mix both the regular output > and an error into the same buffer for the callers to process (your > "reason 1)" above), and this looks like a wrong way to allow a > caller that wants no output (your "reason 2)" above). A caller that > wants to massage the output would want to know which ones are errors > and which ones are not, I would imagine, and setting a knob to make > both output() and err() a no-op would be a more suitable way to give > a caller a total silence. I actually now see how this would work well for "reason 2)". If a caller wants to run the function and wants to pretend as if it did not run anything when it failed, for example, using this to spool all output and error to a strbuf and discard it when the function returns an error, and emit the spooled output to standard output and standard error in the order the lines were collected when the function returns a success, would be a good way to do so. That however brings me back to the "reason 1" thing. Shouldn't the spooling be done not just with a single strbuf, but with an array of <bool, const char *> tuples, where the bool says if it is for the standard output, and the string holds the message? output() would mark its element in the array with true, while err() would do so with false. -- 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