From: Paul Mackerras <paulus@samba.org>
To: Jeff King <peff@peff.net>
Cc: Ramsay Jones <ramsay@ramsay1.demon.co.uk>,
Junio C Hamano <gitster@pobox.com>,
Andrew Morton <akpm@linux-foundation.org>,
git@vger.kernel.org
Subject: Re: [PATCH 3/3] diff: make "too many files" rename warning optional
Date: Mon, 5 May 2008 09:28:18 +1000 [thread overview]
Message-ID: <18462.18066.769759.585596@cargo.ozlabs.ibm.com> (raw)
In-Reply-To: <20080504192332.GB13029@sigill.intra.peff.net>
Jeff King writes:
> 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.
next prev parent reply other threads:[~2008-05-04 23:32 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-26 13:32 warning: too many files, skipping inexact rename detection Andrew Morton
2008-04-26 13:57 ` Jeff King
2008-04-26 14:06 ` Andrew Morton
2008-04-26 14:52 ` Jeff King
2008-04-30 17:21 ` [PATCH 0/3] rename limit improvements Jeff King
2008-04-30 17:23 ` [PATCH 1/3] add merge.renamelimit config option Jeff King
2008-04-30 18:18 ` Jeff King
2008-05-03 20:15 ` Junio C Hamano
2008-05-04 19:31 ` Jeff King
2008-04-30 17:24 ` [PATCH 2/3] bump rename limit defaults Jeff King
2008-04-30 17:25 ` [PATCH 3/3] diff: make "too many files" rename warning optional Jeff King
2008-05-03 17:34 ` Ramsay Jones
2008-05-04 19:23 ` Jeff King
2008-05-04 23:28 ` Paul Mackerras [this message]
2008-05-05 13:59 ` Jeff King
2008-05-05 17:02 ` Jeff King
2008-05-05 19:52 ` Junio C Hamano
2008-05-12 11:15 ` Paul Mackerras
2008-05-06 22:33 ` Ramsay Jones
2008-05-06 22:29 ` Ramsay Jones
2008-05-04 0:10 ` Junio C Hamano
2008-05-04 19:20 ` Jeff King
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=18462.18066.769759.585596@cargo.ozlabs.ibm.com \
--to=paulus@samba.org \
--cc=akpm@linux-foundation.org \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=peff@peff.net \
--cc=ramsay@ramsay1.demon.co.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).