On 01.12.2021 08:50, Eric Sunshine wrote:
On Wed, Dec 1, 2021 at 3:33 AM Fabian Stelzer <fs@xxxxxxxxxxxx> wrote:
On 01.12.2021 00:32, Eric Sunshine wrote:
>+ We make a distinction between a command's primary output and output
>+ which is merely chatty feedback (for instance, status messages,
>+ running transcript, or progress display), as well as error messages.
>+ Roughly speaking, a command's primary output is that which one might
>+ want to capture to a file or send down a pipe; its chatty output
>+ should not interfere with those use-cases.
>+
>+ As such, primary output should be sent to the standard output stream
>+ (stdout), and chatty output should be sent to the standard error
>+ stream (stderr). Examples of commands which produce primary output
>+ include `git log`, `git show`, and `git branch --list` which generate
>+ output on the stdout stream.
>+
>+ Not all commands have primary output; this is often true of commands
>+ whose main function is to perform an action. Some action commands are
>+ silent, whereas others are chatty. An example of a chatty action
>+ commands is `git clone` with its "Cloning into '<path>'..." and
>+ "Checking connectivity..." status messages which it sends to the
>+ stderr stream.
>+
>+ Error messages are always sent to the stderr stream.
This is not necessarily true in the context of the tests.
We just spoke about this in:
https://lore.kernel.org/git/211130.86wnkpd6ou.gmgdl@xxxxxxxxxxxxxxxxxxx/T/#u
I don't think it necessary to bloat this explanation with the test details.
But mentioning it as an exception would be good.
Yep, I tried to be clear about that by repeatedly stating that
_command_ output should follow this guideline, where "command" means
"Git command". I strongly considered writing "Git command" to be
perfectly clear, but figured reviewers would insist that it was
redundant to mention "Git".
However, I can certainly change these to say "Git command" if you
think it would make the intent clearer, and can update the final point
to say:
Error messages from Git commands should always
be sent to the stderr stream.
Maybe it was just because i was working on test-lib stuff earlier that i did
not connect `a commands output` to a `git command` but basically understood
it as all output in git code.
Still, I think your addition to the last sentence is a good idea and won't
hurt.
Thanks
