From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: [PATCH] fix color.pager = false with "git diff"
Date: Thu, 21 Oct 2010 11:02:45 -0400 [thread overview]
Message-ID: <20101021150244.GA18426@sigill.intra.peff.net> (raw)
The color code makes a decision early on about whether to
use colors based on the config and whether we are using a
pager. For the most part, this works, because if we are
using a pager, we will start it more or less immediately.
In the case of diff, however, we delay starting the pager in
case --exit-code is being used. If this happens, then the
color code makes the wrong decision (because it doesn't
yet realize we are using a pager), and we need to correct
the decision after deciding whether to use a pager.
Signed-off-by: Jeff King <peff@peff.net>
---
Original discussion here:
http://thread.gmane.org/gmane.comp.version-control.git/89599
I have mixed feelings on this one. It's kind of a hack. A more elegant
solution would be totally rewriting the color code to check for the
pager at first output.
In favor of this patch:
1. It fixes a real bug.
2. Perfect is the enemy of the good, and I don't care enough about
this case to refactor the color code.
Against:
1. It does nothing to fix other times when this ordering problem may
arise (I don't think there are others, but I didn't check very
thoroughly. And of course new ones may appear).
2. The bug was reported over 2 years ago, and hasn't come up since,
despite remaining unfixed. Maybe nobody actually cares.
builtin/diff.c | 15 +++++++++++++++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/builtin/diff.c b/builtin/diff.c
index a43d326..cbe15c9 100644
--- a/builtin/diff.c
+++ b/builtin/diff.c
@@ -318,6 +318,21 @@ int cmd_diff(int argc, const char **argv, const char *prefix)
setup_pager();
/*
+ * Special case: we have already examined the config for
+ * color, but we didn't know at that point whether we were
+ * going to start a pager. The only case that we care about is
+ * when we turned on color, but shouldn't have (we will never
+ * "should have but didn't" because of the pager, since
+ * a lack of a pager implies either the tty is stdout, in
+ * which case we do turn on color, or it is not, in which
+ * case we don't start a pager).
+ */
+ if (DIFF_OPT_TST(&rev.diffopt, COLOR_DIFF) &&
+ pager_in_use() &&
+ !pager_use_color)
+ DIFF_OPT_CLR(&rev.diffopt, COLOR_DIFF);
+
+ /*
* Do we have --cached and not have a pending object, then
* default to HEAD by hand. Eek.
*/
--
1.7.3.1.235.gdd6c0
next reply other threads:[~2010-10-21 15:02 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-21 15:02 Jeff King [this message]
2010-10-21 19:02 ` [PATCH] fix color.pager = false with "git diff" Jonathan Nieder
2010-10-21 22:53 ` Junio C Hamano
2010-10-22 1:49 ` 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=20101021150244.GA18426@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/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).