git/list[1] front-page[2] threads[3] people[4] search[5] about
 

stdout versus stderr for cmd line git

From
MHMichael Hunley <michael@codecobblers.com>
Date
May 8, 2013, 01:48 UTC
Message-ID
<CAKk5qjVoDUzeurgAL51jixXsm4rJCMCDf620vAv_Gsafk8N7iA@mail.gmail.com>

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
Next: Jonathan Nieder
Message 1 of 2 in “stdout versus stderr for cmd line git”
  1. Michael HunleyMay 8, 2013
  2. Jonathan NiederMay 10, 2013

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.