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

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

[Jeff King]

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

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

[Jonathan Nieder]

[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?

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

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

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

Hmm, with "[color] pager = false", what should

    $ git diff --color

do?

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

[Jeff King]

On Thu, Oct 21, 2010 at 03:53:36PM -0700, Junio C Hamano wrote:

> > 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.
> 
> Hmm, with "[color] pager = false", what should
> 
>     $ git diff --color
> 
> do?

Ugh. It should definitely turn color on, which my patch breaks. And
there's currently no way to know at that point in the code whether the
COLOR_DIFF bit came from --color or from the config.

So we would need to start keeping that information through the
callchain, or we need to refactor the color code to push the color
decision until later (probably first use). The latter is the right way,
I think, but it's going to take some surgery.

Either way, let's scrap my patch. The bug it introduces is just as bad
as the bug it fixes.

Thanks for noticing.

-Peff