On 2020-05-23 at 22:44:59, Michal Vrana wrote: > Hello, > I've come across an issue that seems like a bug to me. If I clone a > repository with a submodule but want to initialize it separately, then > the error output is used during this initialization for what seems to > be a standard message. > Motivation: > Cannot use - Fail on standard error setting in a devops pipeline In general, this is not a good setting to use with Git. Git uses standard error for many progress outputs if standard output is potentially scriptable. You're better off checking exit codes to determine success or failure. Git is also not the only tool to do this; other tools such as Docker do as well. > Steps to reproduce: > 1. git clone > 2. git submodule init 2>err.txt > > The err.txt contains a message like > Submodule 'xyz' (xyz.git) registered for path 'abc' > From what I've read this is the standard output in this case. And if > not then why when I use "quiet" mode then the error output is empty. > So why is the error output even used? c66410ed32a gives us the answer: Reroute the output of stdout to stderr as it is just informative messages, not to be consumed by machines. This should not regress any scripts that try to parse the current output, as the output is already internationalized and therefore unstable. We want to init submodules from the helper for `submodule update` in a later patch and the stdout output of said helper is consumed by the parts of `submodule update` which are still written in shell. So we have to be careful which messages are on stdout. I haven't looked to see if we could change it back, but that's the reason it was written that way. -- brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204
Attachment:
signature.asc
Description: PGP signature