Re: [PATCH 3/3] diff: make "too many files" rename warning optional
- From
Paul Mackerras <paulus@samba.org>
- Date
- May 4, 2008, 23:28 UTC
- Message-ID
- <18462.18066.769759.585596@cargo.ozlabs.ibm.com>
- In-Reply-To
- <20080504192332.GB13029@sigill.intra.peff.net>
Jeff King writes:
Show 6 quoted lines
> Hrm. Is gitk on cygwin somehow squishing stderr and stdout together? Or > does gitk in general look at what happens on stderr? > > Because while I am happy that removing this message fixes your problem, > it is a little disconcerting to think that we can break gitk just by > issuing a warning diagnostic on stderr.
It's a more general Tcl thing - if you are reading from a process, and the process writes to stderr, and the script hasn't explicitly redirected stderr, the Tcl infrastructure assumes that the process is signalling an error, even if the exit status is 0. Gitk does redirect stderr (to stdout) when it does a git reset, but not for other commands.
At the moment I don't think there is a good way in Tcl to get hold of the stderr output if a subcommand returns a non-zero exit status, but ignore it if the exit status is 0, other than by redirecting stderr to a temporary file, which has its own problems. Tcl can bundle stderr in with stdout, or ignore it, or take it as an error indication, or send it to a file.
So if git commands can avoid writing non-error messages to stderr, that will make my life easier...
Paul.