Scott Chamberlain Scott Chamberlain - 1 month ago 7
Git Question

Can't get git to stop outputting to StdErr

I am working on some build scripts that get run on TFS. During the build process I need to check in the changes that where done during the build process (A set of binaries other projects depend on).

I would really like to leave the option "Fail on Standard Error" enabled for the script, however my push keeps writing to standard error even though I told it not to.

The line I do is:

git push -q binaryRepo HEAD:"$Env:BUILD_SOURCEBRANCH"


But I get the following in my log after the build

2016-10-28T20:05:32.3179442Z ##[error]remote:
remote: Analyzing objects... (3/3) (657 ms)
remote: Storing packfile... done (40 ms)
remote: Storing index... done (42 ms)

2016-10-28T20:05:32.3209423Z Done
2016-10-28T20:05:32.4019436Z ##[error]Process completed with exit code 0 and had 1 error(s) written to the error stream.
2016-10-28T20:05:32.4029436Z ##[debug]System.Exception: Process completed with exit code 0 and had 1 error(s) written to the error stream.


Why am I still getting output to standard error when I included the
-q
switch?




If it matters
git version
reports
2.10.0.windows.1

Answer

Anything prefixed with remote: is spit out not by your Git, but rather by the other Git, the one you're pushing-to.

There's no built-in way to shut up the other Git. You could find out what sort of pre-receive and update hook they1 have set up—these hooks, or the things they invoke, are what are printing Analyzing objects and so on—and see if they have provided a "quiet" flag, and if so, whether they have also provided some way for you to set that flag.2 If not, you are stuck: you must either discard stderr output entirely, or ignore it (which amount to the same thing). You can trust that if your Git prints some important failure message, it will exit with a nonzero status: that's something you can control (by fixing your own Git if necessary, or switching to another version), while "things done on the remote" are generally something you cannot control.


1It sounds like "they" are in fact you, which means you're in luck! Just stand over on the other, server, side, where you're doing these scripts, and see footnote 2.

2Due to a lack of exposed side channels, there's no easy and convenient, yet universal, way to set flags. If you're using ssh:// as your protocol, you can use $HOME/.ssh/environment to pass extra environment variables, provided that their sshd permits this. That's a bit clumsy, and obviously does not work at all if you are using https://.

Another method that will work in theory—I've never tried it in practice—is to have an agreed-upon, always-force-push-able, dummy branch or tag name. This cannot be used with an update hook, but a pre-receive hook could scan athrough all the proposed updates, and if the special branch or tag is included, use its presence and/or its target object to provide the smuggled data (e.g., flags for the remaining pre-receive branch actions).