Re: [PATCH] git-status: colorize status output

Matthias Lederhofer [off-list ref] writes:

Junio C Hamano [off-list ref] wrote:

quoted

Matthias Lederhofer [off-list ref] writes:

quoted

quoted

Color support is controlled by status.color and status.color.*. There is no
command line option, and the status.color variable is a simple boolean (no
checking for tty output).

Is there any way to do isatty() from shell scripts?

Yes.

How? :)

Arrrrrrrgh!  The message I wanted to send you went to Jeff.

Your Mail-Followup-To: fooled me.  Please do not do this.

$ git grep -B1 'standard input' -- '*.sh'
git-commit.sh-		test -t 0 &&
git-commit.sh:		echo >&2 "(reading log message from standard input)"

Is there any reason not checking isatty()?

Not that I can think of, but do people really run "git status"?

I think Jeff's follow-up "vim colorizer" makes a lot more sense
than colorizing "git status" output -- it gives reminder during
the last chance the user has to notice such problems, which is
while composing the commit log message.

Junio C Hamano [off-list ref] wrote:

Matthias Lederhofer [off-list ref] writes:
Arrrrrrrgh!  The message I wanted to send you went to Jeff.

Your Mail-Followup-To: fooled me.  Please do not do this.

Sorry.

quoted

Is there any reason not checking isatty()?

Not that I can think of, but do people really run "git status"?

I do :)

I think Jeff's follow-up "vim colorizer" makes a lot more sense
than colorizing "git status" output -- it gives reminder during
the last chance the user has to notice such problems, which is
while composing the commit log message.

I like the colored git status.  Here is a patch to honor isatty(1) and
pager_in_use (exporting GIT_PAGER_IN_USE) with pager.color.

---
From c01b26cd332283d3b3feaeae4a8218bb409aea2c Mon Sep 17 00:00:00 2001
From: Matthias Lederhofer <redacted>
Date: Sat, 5 Aug 2006 14:09:49 +0200
Subject: [PATCH] git-status: do not use colors all the time

Either [ -t 1 ] has to be true or the pager is used and pager.color is
not false.

Signed-off-by: Matthias Lederhofer <redacted>
---
 git-commit.sh |    6 +++++-
 pager.c       |    1 +
 2 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/git-commit.sh b/git-commit.sh
index b7269c2..ad0cbb1 100755
--- a/git-commit.sh
+++ b/git-commit.sh

@@ -20,7 +20,11 @@ case "$0" in
 *status)
 	status_only=t
 	unmerged_ok_if_status=--unmerged
-	color=`git-repo-config --bool --get status.color`
+	[ "`git-repo-config --bool --get status.color`" = 'true' ] &&
+		([ -t 1 ] || (
+			[ -n "$GIT_PAGER_IN_USE" ] &&
+			[ "`git-repo-config --bool --get pager.color`" != 'false' ]
+		)) && color=true
 	eval `git-repo-config --get-regexp status.color. \
 	      | while read k v; do
 	          echo color_${k#status.color.}=$v

diff --git a/pager.c b/pager.c
index dcb398d..3ba4166 100644
--- a/pager.c
+++ b/pager.c

@@ -27,6 +27,7 @@ void setup_pager(void)
 		return;
 
 	pager_in_use = 1; /* means we are emitting to terminal */
+	setenv("GIT_PAGER_IN_USE", "1", 1);
 
 	if (pipe(fd) < 0)
 		return;

-- 
1.4.2.rc2.gd71a

On Sat, Aug 05, 2006 at 04:42:29AM -0700, Junio C Hamano wrote:

Not that I can think of, but do people really run "git status"?

I do! :) I actually wrote the vim colorizer first and used it for a
week before realizing it was not sufficient, and that I wanted
git-status output colorized, too. So please consider including the
patch.

I think Jeff's follow-up "vim colorizer" makes a lot more sense
than colorizing "git status" output -- it gives reminder during
the last chance the user has to notice such problems, which is
while composing the commit log message.

It looks like we have some similar emacs stuff in contrib/. Should I
prepare a short patch to create contrib/vim/?

-Peff

On Sat, Aug 05, 2006 at 02:18:21PM +0200, Matthias Lederhofer wrote:

I like the colored git status.  Here is a patch to honor isatty(1) and
pager_in_use (exporting GIT_PAGER_IN_USE) with pager.color.

Doesn't this have different behavior when you use 'git-status' rather
than 'git status'? Maybe rather than a boolean, we would be better off
with a true/false/auto value similar to diff.color.

-Peff

Jeff King [off-list ref] wrote:

On Sat, Aug 05, 2006 at 02:18:21PM +0200, Matthias Lederhofer wrote:

quoted

I like the colored git status.  Here is a patch to honor isatty(1) and
pager_in_use (exporting GIT_PAGER_IN_USE) with pager.color.

Doesn't this have different behavior when you use 'git-status' rather
than 'git status'? Maybe rather than a boolean, we would be better off
with a true/false/auto value similar to diff.color.

I don't see the case where git-status and git status behave
differently (except for git -p status but git-status does not have an
option for paging at all).

Not that I can think of, but do people really run "git status"?

Always (almost) before I run 'git fetch'.
I do it to check that I have not made any local modifications that I
need to get rid of before fetching and that I do not have stale files
around.

One example is my copy of Linus' kernel tree. I use it now and then for
small experiments (can I reporoduce this bug etc) and when fetching I
want it to be gone.

	Sam