[PATCH] Print progress message to stderr, not stdout

Printing progress messages to stdout causes them to get mixed up with
the actual output of the program. Using stderr is much better, since
the user can then redirect the two components separately.

Signed-off-by: Karl Hasselström <redacted>
---

I noticed this when creating a patch with "stg export -s" for the
import regression test.

 stgit/git.py |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/stgit/git.py b/stgit/git.py
index 2a6ae91..8d88769 100644
--- a/stgit/git.py
+++ b/stgit/git.py

@@ -186,8 +186,8 @@ def __tree_status(files = None, tree_id
     """Returns a list of pairs - [status, filename]
     """
     if verbose:
-        print 'Checking for changes in the working directory...',
-        sys.stdout.flush()
+        sys.stderr.write('Checking for changes in the working directory...')
+        sys.stderr.flush()
 
     refresh_index()
 

@@ -226,7 +226,7 @@ def __tree_status(files = None, tree_id
             cache_files.append(fs)
 
     if verbose:
-        print 'done'
+        print >> sys.stderr, 'done'
 
     return cache_files

Hi,

On Mon, 4 Dec 2006, Catalin Marinas wrote:

I'll first move the message back to stdout.

In other parts of git, the progress message is only printed if output goes 
to a tty. Why not do the same?

Ciao,
Dscho

On 05/12/06, Johannes Schindelin [off-list ref] wrote:

On Mon, 4 Dec 2006, Catalin Marinas wrote:

quoted

I'll first move the message back to stdout.

In other parts of git, the progress message is only printed if output goes
to a tty. Why not do the same?

Thanks for the hint. This seems to me like the easiest solution.

-- 

On 12/4/06, Catalin Marinas [off-list ref] wrote:

On 04/12/06, Marco Costalba [off-list ref] wrote:

quoted

On 12/4/06, Karl Hasselström [off-list ref] wrote:

quoted

I introduced this since I wanted to divert the output to a file, and
the progress message had no business being written to that file. But a
command line option to suppress progress messages would work just as
well if that's what git does.

If you don't mind I would prefer a command line option to _enable_
progress messages, something like -v or --verbose so to keep back
compatibility with current versions of tools that do not expect stderr
messages.

I'll first move the message back to stdout. Does qgit rely on the
StGIT output to have a certain format/information? Does the progress
message affect it in any way?

No. It just checks stderr for empty.

The only commands whose output is used by qgit are stg series/applied/u

On 04/12/06, Marco Costalba [off-list ref] wrote:

On 12/4/06, Karl Hasselström [off-list ref] wrote:

quoted

I introduced this since I wanted to divert the output to a file, and
the progress message had no business being written to that file. But a
command line option to suppress progress messages would work just as
well if that's what git does.

If you don't mind I would prefer a command line option to _enable_
progress messages, something like -v or --verbose so to keep back
compatibility with current versions of tools that do not expect stderr
messages.

I'll first move the message back to stdout. Does qgit rely on the
StGIT output to have a certain format/information? Does the progress
message affect it in any way?

I consider many of the other messages to be progress messages (like
"pushing... done") and I haven't differentiated between them until
Karl's patch. For commands like diff or status, you expect the command
to check the working copy anyway and it doesn't output this specific
message.

The best would probably be to add a "verbose" config option to enable
this message (and maybe a command line option later but this means
modifying all the commands to accept this option). I'll try to push
this change tomorrow (together with moving from stgitrc to gitconfig).

-- 

On 11/11/06, Karl Hasselström [off-list ref] wrote:

Printing progress messages to stdout causes them to get mixed up with
the actual output of the program. Using stderr is much better, since
the user can then redirect the two components separately.

This patch breaks qgit.

GUI interface to stgit pop and push commands is broken because a
command that prints to stderr is considered a failing one by qgit.

I would kindly ask you to:

1 - Revert the patch. That would be the best. You can use a prefix to
printed message instead, see git pull, something like 'stg: bla bla
bla' . In any case, IMHO, using stderr for normal activity logging
does not sound like a great idea in general.

2 - At least add a '-v' '--verbose' option that defaults to quiet so
to not break back compatibility.


Thanks
Marco

P.S: I cannot change the stderr == 'something has gone wrong'
behaviour because the interface to git commands works with this, and,
BTW, _all_ the git commands respect the behaviour stderr == empty ->

On 02/12/06, Marco Costalba [off-list ref] wrote:

On 11/11/06, Karl Hasselström [off-list ref] wrote:

quoted

Printing progress messages to stdout causes them to get mixed up with
the actual output of the program. Using stderr is much better, since
the user can then redirect the two components separately.

This patch breaks qgit.

GUI interface to stgit pop and push commands is broken because a
command that prints to stderr is considered a failing one by qgit.

I would kindly ask you to:

1 - Revert the patch. That would be the best. You can use a prefix to
printed message instead, see git pull, something like 'stg: bla bla
bla' . In any case, IMHO, using stderr for normal activity logging
does not sound like a great idea in general.

2 - At least add a '-v' '--verbose' option that defaults to quiet so
to not break back compatibility.

Since there are other tools relying on a clean stderr, I think I would
revert it and add a verbose flag and/or config option. Karl, any
thoughts on this (since you sent the patch)?

-- 

On 12/4/06, Karl Hasselström [off-list ref] wrote:

On 2006-12-04 09:17:16 +0000, Catalin Marinas wrote:

quoted

On 02/12/06, Marco Costalba [off-list ref] wrote:

quoted

On 11/11/06, Karl Hasselström [off-list ref] wrote:

quoted

Printing progress messages to stdout causes them to get mixed up
with the actual output of the program. Using stderr is much
better, since the user can then redirect the two components
separately.

This patch breaks qgit.

Since there are other tools relying on a clean stderr, I think I
would revert it and add a verbose flag and/or config option. Karl,
any thoughts on this (since you sent the patch)?

I introduced this since I wanted to divert the output to a file, and
the progress message had no business being written to that file. But a
command line option to suppress progress messages would work just as
well if that's what git does.

If you don't mind I would prefer a command line option to _enable_
progress messages, something like -v or --verbose so to keep back
compatibility with current versions of tools that do not expect stderr
messages.

Thanks

On 2006-12-04 09:17:16 +0000, Catalin Marinas wrote:

On 02/12/06, Marco Costalba [off-list ref] wrote:

quoted

On 11/11/06, Karl Hasselström [off-list ref] wrote:

quoted

Printing progress messages to stdout causes them to get mixed up
with the actual output of the program. Using stderr is much
better, since the user can then redirect the two components
separately.

This patch breaks qgit.

Since there are other tools relying on a clean stderr, I think I
would revert it and add a verbose flag and/or config option. Karl,
any thoughts on this (since you sent the patch)?

I introduced this since I wanted to divert the output to a file, and
the progress message had no business being written to that file. But a
command line option to suppress progress messages would work just as
well if that's what git does.

-- 
Karl Hasselström, kha@treskal.com

On 2006-12-05 08:41:57 +0100, Johannes Schindelin wrote:

On Mon, 4 Dec 2006, Catalin Marinas wrote:

quoted

I'll first move the message back to stdout.

In other parts of git, the progress message is only printed if
output goes to a tty. Why not do the same?

That sounds like a good idea for two reasons:

  1. It will address all concerns raised in this thread (I think).

  2. It will remove an unnecessary difference between git and stgit.

-- 
Karl Hasselström, kha@treskal.com