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

Re: CR codes from git commands

From
Brent Goodrick <bgoodr@gmail.com>
Date
Jan 21, 2009, 14:42 UTC
Message-ID
<18807.13411.984420.252378@hungover.brentg.com>
In-Reply-To
<alpine.DEB.1.00.0901210930370.7929@racer>
Johannes Schindelin writes:
 > Hi,
 > 
 > is there a special reason you un-Cc:ed the list?

No, my mistake. CCing the mailing list now. I was foiled into thinking that the reply operation in my email client meant reply-all, but instead it was set to reply-to-sender-only. Now fixed.

 > 
 > On Tue, 20 Jan 2009, Brent Goodrick wrote:
 > 
 > > Johannes Schindelin writes:
 > > 
 > >  > On Tue, 20 Jan 2009, Brent Goodrick wrote:
 > >  > 
 > >  > > I am considering converting from CVS over to using git. I'm 
 > >  > > currently using git version 1.5.6.5 on Debian Linux "testing".
 > >  > 
 > >  > First of all, 1.5.6.5 is from last August, so chances are that the 
 > >  > behavior you complain about was fixed in the meantime.  We're at 
 > >  > 1.6.1 at the moment.
 > > 
 > > Yes, I thought that was a good point, so I rebuilt from the source 
 > > tarball git version 1.6.1 and retried my script and got the same 
 > > behavior.
 > > 
 > >  > The only place I can think about where a CR is output is when showing 
 > >  > the progress of downloading.
 > >  > 
 > >  > Usually, our code checks if stdout is a tty, and does not show 
 > >  > progress.
 > >  >
 > >  > As a work-around, piping into cat should work, though.
 > > 
 > > Actually only redirecting stderr and then piping to cat seems to work, 
 > > e.g.,:
 > > 
 > >   get pull 2>&1 | cat
 > > 
 > > 
 > > I don't mind seeing the progress lines, I just don't want git to emit 
 > > any CR codes at all.
 > > 
 > > How about a config option to just turn off any tty-detecting logic 
 > > entirely, so that I don't have to wrap git with a lot of silly scripts 
 > > that set environment variables and redirect stdout and stderr and piped 
 > > into "cat"?
 > 
 > Nope, the config option is not needed.  This is just a Plain Old Bug which 
 > needs fixing, that's all.
 > 
 > Let's see what I can do today.

Thanks. The fix should be to arrange it so that I can set something so that a bare call such as (but just "git pull"):

  git pull

will emit no CR codes at all, ever, regardless of if there is a tty. Even if it is an env var, but a config setting would be ok too.

Thanks, Brent

Previous: Junio C HamanoNext: Johannes Schindelin
Message 22 of 24 in “CR codes from git commands”
  1. Brent GoodrickJan 20, 2009
  2. Johannes SchindelinJan 20, 2009
  3. Daniel BarkalowJan 22, 2009
  4. Brent GoodrickJan 22, 2009
  5. Daniel BarkalowJan 22, 2009
  6. Junio C HamanoJan 22, 2009
  7. Mike RalphsonJan 22, 2009
  8. Brent GoodrickJan 22, 2009
  9. Mike RalphsonJan 22, 2009
  10. Johannes SchindelinJan 22, 2009
  11. Daniel BarkalowJan 22, 2009
  12. Johannes SchindelinJan 22, 2009
  13. Brent GoodrickJan 23, 2009
  14. Junio C HamanoJan 23, 2009
  15. Johannes SchindelinJan 23, 2009
  16. Brent GoodrickJan 24, 2009
  17. Johannes SchindelinJan 24, 2009
  18. Boyd Stephen Smith Jr.Jan 25, 2009
  19. Brent GoodrickJan 25, 2009
  20. Brent GoodrickFeb 2, 2009
  21. The lifecycle of a patch and the maintainer involvementJunio C Hamano, Jan 25, 2009
  22. Brent GoodrickJan 21, 2009
  23. Johannes SchindelinJan 21, 2009
  24. Brent GoodrickJan 22, 2009

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.