Re: Submodule init uses STDERR output

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux