[PATCH] fix color.pager = false with "git diff"

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 <redacted>
---
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

[reordered for convenience]
Jeff King wrote:

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.

I'd say, go for it.  At least one person (Benjamin Kudria, cc-ed) cared
at some point.  And including the code means that maybe some future hero
refactoring "git diff" will notice and implement the proper solution.

Though to that end, wouldn't it make sense to include

                                                        A more elegant
solution would be totally rewriting the color code to check for the
pager at first output.

in the commit message?