On Tue, Jun 28, 2011 at 11:33:48AM -0700, Junio C Hamano wrote: > > So far progress always uses \r to produce one-line output on stderr. > > This only produces useful and easy parsable output if stderr is opened > > on a file which does interpret CR as a real carriage return operation. > > This patch changes EOL to the plain newline \n control if isatty() is > > false instead. > > > > Signed-off-by: Steffen Daode Nurpmeso <sdaoden@xxxxxxxxx> > > I kind of like this patch, in the sense that if there is a sane scenario > to emit progress to non-tty, we should do just LF not CRLF, but I would > like to know the real motivation behind this proposal. > > I thought that we try to disable the progress pretty much everywhere when > we are not talking to a tty, so ugliness coming from many CRLF appearing > in the cron e-mail shouldn't be the issue. We certainly do try to turn off progress reporting when stderr isn't a tty. So unless "--progress" is being given explicitly, seeing it is a bug that should be fixed. I'm not sure dropping the CR is a good thing, though. One of the uses for forcing output to a non-terminal via "--progress", is that something _else_ is going to parse the output. And that other thing gets useful information from the carriage returns. For example, you may be piping into a file or a fifo and running 'tail' to a terminal on the other end. You want the CR because we are ultimately going to a terminal. Another example: you write a GUI wrapper around git that captures and parses stderr. You show progress and informative messages in a running dialog. The difference between CR and LF is important. The former means "clear the progress line and show this new one instead"; the latter means "keep this on the screen and show more lines". I'm willing to accept that there are use cases where you don't want the CRs, but just want a list of lines[1]. But it seems like this change hurts some existing use cases. -Peff [1] Actually, I would be curious to see such a use case. If you are planning on saving the output, is it really useful to have a hundred lines saying: Compressing objects 1% (100/10000) Compressing objects 2% (200/10000) and so forth? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html