stdout versus stderr for cmd line git

Michael Hunley· May 8, 2013, 01:48 UTC · lore

I have been building some automated patching scripts to update multiple servers at once from our dev host. In doing so I ran into some oddities with linux command line GIT version 1.8.0-rc0, so a couple minor revisions behind.

First, a "git pull" puts the list of branches updated onto stderr. These are not errors and should be on stdout. E.g. Filtered error: From <git host>:service-framework Filtered error: 017f911..b1f72db patching -> origin/patching

Ok, we can filter that out. But worse is that actual errors in a pull request are sent to stdout instead of standard error. For example, merge conflicts or pull failures because you have unstaged changes.

For now I have to merge all stdout to stderr on my git requests in my patching script, then filter the results to find the real errors.

Can we please make it so all actual errors appear on stderr, but not non-errors?

If this was fixed in 1.8.2 latest, please forgive as I am running fast and furious to get this available tonight.

thanks

Jonathan Nieder· May 10, 2013, 03:28 UTC · re: Michael Hunley · lore

Re: stdout versus stderr for cmd line git

Hi,

Michael Hunley wrote:

> Ok, we can filter that out.  But worse is that actual errors in a pull
> request are sent to stdout instead of standard error.  For example,
> merge conflicts or pull failures because you have unstaged changes.

Yes, errors and progress output should go to stderr. The git-pull.sh script is pretty old and is probably just a bit sloppy about forgetting to redirect output from "echo". Patches welcome. (See Documentation/SubmittingPatches for details.)

Hope that helps, Jonathan