[PATCH] git-status: colorize status output

[PATCH] git-status: colorize status output

[Jeff King]

The git-status output can sometimes be very verbose, making it difficult to
quickly see whether your files are updated in the index. This adds 4 levels
of colorizing to the status output:
  - general header (defaults to normal white)
  - updated but not committed (defaults to green)
  - changed but not updated (defaults to red)
  - untracked files (defaults to red)
The idea is that red things indicate a potential mistake on the part of the
user (e.g., forgetting to update a file, forgetting to git-add a file).

This patch also has a few minor output related cleanups. Untracked files are
now displayed using the 'report' function (marked with the character 'O').
The report function now uses a simple hdr_shown variable instead of
flip-flopping the header and trailer, which was somewhat difficult to read.

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

Signed-off-by: Jeff King <peff@peff.net>
---
 Documentation/config.txt |   12 ++++++
 git-commit.sh            |   99 ++++++++++++++++++++++++++++++----------------
 2 files changed, 77 insertions(+), 34 deletions(-)

diff --git a/Documentation/config.txt b/Documentation/config.txt
index d89916b..83f4627 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -222,6 +222,18 @@ showbranch.default::
 	The default set of branches for gitlink:git-show-branch[1].
 	See gitlink:git-show-branch[1].
 
+status.color::
+	A boolean to enable/disable color in the output of
+	gitlink:git-status[1]. Defaults to false.
+
+status.color.<slot>::
+	Use customized color for status colorization. `<slot>` is
+	one of `header` (the header text of the status message),
+	`updated` (files which are updated but not committed),
+	`changed` (files which are changed but not updated in the index),
+	or `untracked` (files which are not tracked by git). The values of
+	these variables may be specified as in diff.color.<slot>.
+
 tar.umask::
 	By default, gitlink:git-tar-tree[1] sets file and directories modes
 	to 0666 or 0777. While this is both useful and acceptable for projects
diff --git a/git-commit.sh b/git-commit.sh
index 4cf3fab..b7269c2 100755
--- a/git-commit.sh
+++ b/git-commit.sh
@@ -10,15 +10,49 @@ SUBDIRECTORY_OK=Yes
 git-rev-parse --verify HEAD >/dev/null 2>&1 || initial_commit=t
 branch=$(GIT_DIR="$GIT_DIR" git-symbolic-ref HEAD)
 
+color=false
+color_header=normal
+color_updated=green
+color_changed=red
+color_untracked=red
+
 case "$0" in
 *status)
 	status_only=t
-	unmerged_ok_if_status=--unmerged ;;
+	unmerged_ok_if_status=--unmerged
+	color=`git-repo-config --bool --get status.color`
+	eval `git-repo-config --get-regexp status.color. \
+	      | while read k v; do
+	          echo color_${k#status.color.}=$v
+	        done`
+	;;
 *commit)
 	status_only=
 	unmerged_ok_if_status= ;;
 esac
 
+color() {
+	case "$color" in true) ;; *) return ;; esac
+	case `eval "echo \\$color_$1"` in
+	  normal) ;;
+	  bold)    printf '\033[1m' ;;
+	  red)     printf '\033[31m' ;;
+	  green)   printf '\033[32m' ;;
+	  yellow)  printf '\033[33m' ;;
+	  blue)    printf '\033[34m' ;;
+	  magenta) printf '\033[35m' ;;
+	  cyan)    printf '\033[36m' ;;
+	esac
+}
+
+uncolor() {
+	case "$color" in true) ;; *) return ;; esac
+	case "$1" in
+	  normal) ;;
+	  *) printf '\033[m' ;;
+	esac
+}
+
 refuse_partial () {
 	echo >&2 "$1"
 	echo >&2 "You might have meant to say 'git commit -i paths...', perhaps?"
@@ -33,30 +67,32 @@ save_index () {
 }
 
 report () {
-  header="#
-# $1:
-#   ($2)
-#
-"
-  trailer=""
+  hdr_shown=0
   while read status name newname
   do
-    printf '%s' "$header"
-    header=""
-    trailer="#
-"
+    case "$hdr_shown" in
+      0) color header; echo "# $2:"; uncolor header
+         color header; echo "#   ($3)"; uncolor header
+	 color header; echo "#"; uncolor header
+	 hdr_shown=1
+	 ;;
+    esac
+    color header; printf '#\t'; uncolor header
     case "$status" in
-    M ) echo "#	modified: $name";;
-    D*) echo "#	deleted:  $name";;
-    T ) echo "#	typechange: $name";;
-    C*) echo "#	copied: $name -> $newname";;
-    R*) echo "#	renamed: $name -> $newname";;
-    A*) echo "#	new file: $name";;
-    U ) echo "#	unmerged: $name";;
+    M ) color $1; echo "modified: $name"; uncolor $1;;
+    D*) color $1; echo "deleted:  $name"; uncolor $1;;
+    T ) color $1; echo "1change: $name"; uncolor $1;;
+    C*) color $1; echo "copied: $name -> $newname"; uncolor $1;;
+    R*) color $1; echo "renamed: $name -> $newname"; uncolor $1;;
+    A*) color $1; echo "new file: $name"; uncolor $1;;
+    U ) color $1; echo "unmerged: $name"; uncolor $1;;
+    O ) color $1; echo "$name"; uncolor $1;;
     esac
   done
-  printf '%s' "$trailer"
-  [ "$header" ]
+  case "$hdr_shown" in
+    1) color header; echo '#'; uncolor header;;
+  esac
+  test "$hdr_shown" = 0
 }
 
 run_status () {
@@ -109,7 +145,7 @@ run_status () {
 		    s/\\/\\\\/g
 		    s/ /\\ /g
 	    ' |
-	    report "Updated but not checked in" "will commit"
+	    report updated "Updated but not checked in" "will commit"
 	    committable="$?"
 	else
 	    echo '#
@@ -121,7 +157,7 @@ #'
 		    s/ /\\ /g
 		    s/^/A /
 	    ' |
-	    report "Updated but not checked in" "will commit"
+	    report updated "Updated but not checked in" "will commit"
 
 	    committable="$?"
 	fi
@@ -131,14 +167,13 @@ #'
 		s/\\/\\\\/g
 		s/ /\\ /g
 	' |
-	report "Changed but not updated" \
+	report changed "Changed but not updated" \
 	    "use git-update-index to mark for commit"
 
         option=""
         if test -z "$untracked_files"; then
             option="--directory --no-empty-directory"
         fi
-	hdr_shown=
 	if test -f "$GIT_DIR/info/exclude"
 	then
 	    git-ls-files --others $option \
@@ -148,16 +183,12 @@ #'
 	    git-ls-files --others $option \
 		--exclude-per-directory=.gitignore
 	fi |
-	while read line; do
-	    if [ -z "$hdr_shown" ]; then
-		echo '#'
-		echo '# Untracked files:'
-		echo '#   (use "git add" to add to commit)'
-		echo '#'
-		hdr_shown=1
-	    fi
-	    echo "#	$line"
-	done
+	sed -e '
+		s/\\/\\\\/g
+		s/ /\\ /g
+		s/^/O /
+	' |
+	report untracked "Untracked files" "use git add to commit"
 
 	if test -n "$verbose" -a -z "$IS_INITIAL"
 	then
-- 
1.4.2.rc3.g06c3

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

[Jeff King]

On Fri, Aug 04, 2006 at 11:14:19PM -0400, Jeff King wrote:

> The idea is that red things indicate a potential mistake on the part of the
> user (e.g., forgetting to update a file, forgetting to git-add a file).

I actually wanted to do this because I started syntax-highlighting the
git-commit message in vim. I found myself catching simple mistakes in
commits, like the ones I mentioned above, before committing, saving me
from doing an --amend. Then I got so hooked on it I wanted the
colorization everytime I ran git-status.

If anyone is interested in the vim syntax highlighting, it is below.
Copy the file to $HOME/.vim/syntax/gitcommit.vim and add the following
line to your .vimrc:
  autocmd BufNewFile,BufRead COMMIT_EDITMSG set filetype=gitcommit

-Peff

-- >8 --
syn region gitLine start=/^#/ end=/$/
syn region gitCommit start=/^# Updated but not checked in:$/ end=/^#$/ contains=gitHead,gitCommitFile
syn region gitHead contained start=/^#   (.*)/ end=/^#$/
syn region gitChanged start=/^# Changed but not updated:/ end=/^#$/ contains=gitHead,gitChangedFile
syn region gitUntracked start=/^# Untracked files:/ end=/^#$/ contains=gitHead,gitUntrackedFile

syn match gitCommitFile contained /^#\t.*/hs=s+2
syn match gitChangedFile contained /^#\t.*/hs=s+2
syn match gitUntrackedFile contained /^#\t.*/hs=s+2

hi def link gitLine Comment
hi def link gitCommit Comment
hi def link gitChanged Comment
hi def link gitHead Comment
hi def link gitUntracked Comment
hi def link gitCommitFile Type
hi def link gitChangedFile Constant
hi def link gitUntrackedFile Constant

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

[Greg KH]

On Fri, Aug 04, 2006 at 11:21:35PM -0400, Jeff King wrote:
> On Fri, Aug 04, 2006 at 11:14:19PM -0400, Jeff King wrote:
> 
> > The idea is that red things indicate a potential mistake on the part of the
> > user (e.g., forgetting to update a file, forgetting to git-add a file).
> 
> I actually wanted to do this because I started syntax-highlighting the
> git-commit message in vim. I found myself catching simple mistakes in
> commits, like the ones I mentioned above, before committing, saving me
> from doing an --amend. Then I got so hooked on it I wanted the
> colorization everytime I ran git-status.
> 
> If anyone is interested in the vim syntax highlighting, it is below.
> Copy the file to $HOME/.vim/syntax/gitcommit.vim and add the following
> line to your .vimrc:
>   autocmd BufNewFile,BufRead COMMIT_EDITMSG set filetype=gitcommit

Ah, very nice, thanks for this, makes commits much easier to read now.

greg k-h

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

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> +    M ) color $1; echo "modified: $name"; uncolor $1;;
> +    D*) color $1; echo "deleted:  $name"; uncolor $1;;
> +    T ) color $1; echo "1change: $name"; uncolor $1;;

Is "1" a typo?

> +    C*) color $1; echo "copied: $name -> $newname"; uncolor $1;;
> +    R*) color $1; echo "renamed: $name -> $newname"; uncolor $1;;
> +    A*) color $1; echo "new file: $name"; uncolor $1;;
> +    U ) color $1; echo "unmerged: $name"; uncolor $1;;
> +    O ) color $1; echo "$name"; uncolor $1;;

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

[Jeff King]

On Sat, Aug 05, 2006 at 02:28:31AM -0700, Junio C Hamano wrote:

> > +    M ) color $1; echo "modified: $name"; uncolor $1;;
> > +    D*) color $1; echo "deleted:  $name"; uncolor $1;;
> > +    T ) color $1; echo "1change: $name"; uncolor $1;;
> Is "1" a typo?

Oops, yes, not sure how that got in there.

-Peff

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

[Jeff King]

On Sat, Aug 05, 2006 at 06:21:18AM -0400, Jeff King wrote:

> > > +    T ) color $1; echo "1change: $name"; uncolor $1;;
> > Is "1" a typo?
> Oops, yes, not sure how that got in there.

Oh, I see. It should be 'typechange' in case you didn't reference
against the original version.

-Peff

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

[Matthias Lederhofer]

Jeff King <peff@peff.net> wrote:
> The git-status output can sometimes be very verbose, making it difficult to
> quickly see whether your files are updated in the index. This adds 4 levels
> of colorizing to the status output:
>   - general header (defaults to normal white)
>   - updated but not committed (defaults to green)
>   - changed but not updated (defaults to red)
>   - untracked files (defaults to red)
> The idea is that red things indicate a potential mistake on the part of the
> user (e.g., forgetting to update a file, forgetting to git-add a file).
Perhaps the default values should not use the same color twice? I'd
suggest yellow for changed but not updated.  But well, it's no problem
to change this in my config, I just find it a bit confusing to have
the same color for different things.

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

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

[Junio C Hamano]

Matthias Lederhofer <matled@gmx.net> writes:

> Jeff King <peff@peff.net> wrote:
>> The git-status output can sometimes be very verbose, making it difficult to
>> quickly see whether your files are updated in the index. This adds 4 levels
>> of colorizing to the status output:
>>   - general header (defaults to normal white)
>>   - updated but not committed (defaults to green)
>>   - changed but not updated (defaults to red)
>>   - untracked files (defaults to red)
>> The idea is that red things indicate a potential mistake on the part of the
>> user (e.g., forgetting to update a file, forgetting to git-add a file).
> Perhaps the default values should not use the same color twice? I'd
> suggest yellow for changed but not updated.  But well, it's no problem
> to change this in my config, I just find it a bit confusing to have
> the same color for different things.
>
>> 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.

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

[Junio C Hamano]

Junio C Hamano <junkio@cox.net> writes:

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

Oops -- wrong answer which is too short.

$ git grep -B1 'standard input' -- '*.sh'

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

[Matthias Lederhofer]

Junio C Hamano <junkio@cox.net> wrote:
> Matthias Lederhofer <matled@gmx.net> writes:
> >> 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? :) Is there any reason not checking isatty()?

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

[Junio C Hamano]

Matthias Lederhofer <matled@gmx.net> writes:

> Junio C Hamano <junkio@cox.net> wrote:
>> Matthias Lederhofer <matled@gmx.net> writes:
>> >> 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.

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

[Matthias Lederhofer]

Junio C Hamano <junkio@cox.net> wrote:
> Matthias Lederhofer <matled@gmx.net> writes:
> Arrrrrrrgh!  The message I wanted to send you went to Jeff.
> 
> Your Mail-Followup-To: fooled me.  Please do not do this.
Sorry.

> > 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 <matled@gmx.net>
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 <matled@gmx.net>
---
 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

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

[Jeff King]

On Sat, Aug 05, 2006 at 12:59:53PM +0200, Matthias Lederhofer wrote:

> Perhaps the default values should not use the same color twice? I'd
> suggest yellow for changed but not updated.  But well, it's no problem
> to change this in my config, I just find it a bit confusing to have
> the same color for different things.

I'm fine with changing the defaults as you suggest. It makes more sense
to me with only two colors (files is a potential mistake or not), but I
added more fine-grained support because it was trivial and I thought
others might want to customize it.

We could, of course, allow even more fine-grained control by matching
file type (added, deleted, modified, etc), but I'm not sure anybody
would want that.

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

As Junio said, test -t. :) Is there interest in me adding that feature?

-Peff

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

[Jeff King]

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

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

[Jeff King]

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

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

[Matthias Lederhofer]

Jeff King <peff@peff.net> wrote:
> > Is there any way to do isatty() from shell scripts?
> 
> As Junio said, test -t. :) Is there interest in me adding that feature?
I would suggest that all scripts that use colors have a
always/auto/never (with boolean fallback) option and also honor
pager.color if the pager is in use.

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

[Matthias Lederhofer]

Jeff King <peff@peff.net> wrote:
> 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.
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).

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

[Jeff King]

On Sat, Aug 05, 2006 at 10:27:59PM +0200, Matthias Lederhofer wrote:

> I would suggest that all scripts that use colors have a
> always/auto/never (with boolean fallback) option and also honor
> pager.color if the pager is in use.

I'll send out a patch in a moment.

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

Sorry, I didn't say what I meant at all. My problem was that one
cannot get color with a pager using git-status (by doing
'git-status | less'). The output is not a tty, but GIT_PAGER_IN_USE is
not set (and of course I cannot use '-p'). However, that is a moot point
with always/auto/never, since in such a case I can just use 'always'.

-Peff

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

[Joel Becker]

On Fri, Aug 04, 2006 at 11:14:19PM -0400, Jeff King wrote:
> The git-status output can sometimes be very verbose, making it difficult to
> quickly see whether your files are updated in the index. This adds 4 levels
> of colorizing to the status output:
>   - general header (defaults to normal white)
>   - updated but not committed (defaults to green)
>   - changed but not updated (defaults to red)
>   - untracked files (defaults to red)

Please do one of two things:
1) Add code to discover a terminal is white-on-black and use bright colors
or
2) Default this to off.

I like the idea of colors, but the colors most people use in
black-on-white terminals are invisible on my screen.  colorls has the
same problem.

Joel

-- 

"What no boss of a programmer can ever understand is that a programmer
 is working when he's staring out of the window"
	- With apologies to Burton Rascoe


Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127

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

[Jeff King]

On Sat, Aug 05, 2006 at 10:01:38PM -0700, Joel Becker wrote:

> Please do one of two things:
> 1) Add code to discover a terminal is white-on-black and use bright colors
> or
> 2) Default this to off.

It defaults to off. The colors are also easily customizable should you
want to use it.

-Peff

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

[Sam Ravnborg]

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