Johannes Schindelin writes: > Hi, > > On Thu, 22 Jan 2009, Daniel Barkalow wrote: > > > In any case, it's all done in progress.c, so it should be easy enough to > > make changes to if you can come up with something better to do with > > progress messages and some way to determine when it should be done. > > Maybe "git --no-progress <program>" would be a sensible user > interface? Thanks. I now see the \r reference inside the "display" file-static function inside progress.c. However, I propose to add two options, the first being, IMO, the minimal one to implement, and the second being "nice-to-have": - Bare minimum: Add a new --no-cr option (e.g., "git --no-cr <program>") that would prevent any git code (inside progress.c or elsewhere) from emitting a CR code from stdout or stderr. This has the effect of allowing progress messages, but not asking too much of terminals-that-are-not-really-terminals such as the GNU Emacs shell mode. - Nice-to-have: Add a "git --no-progress" message that would never show progress at all (e.g., perhaps by not installing a signal handler inside progress.c such that no messages would not be emitted at all. Both options are intended to be independent of each other. And for both options, I would like there to be a config option to allow the user to enable said behavior globally across all git operations covered by that config file. I might be willing to take a swipe at this myself and submit a patch, provided I receive adequate noobie hand-holding (or hand-slapping) on patch submission and test case development. bg -- 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
