threads / patch / 5139

patchgit-status: colorize status output

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

## tl;dr

21 messages between Aug 5, 2006 and Aug 7, 2006. Diffs are folded; open one to read it.

replies: 20people: 6as markdown or json

Jeff King· Aug 5, 2006, 03:14 UTC · lore
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(-)
Show changes to 2 files +77 −34

Documentation/config.txt, git-commit.sh

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
Jeff King· Aug 5, 2006, 03:21 UTC · re: Jeff King · lore

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

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

Greg KH· Aug 5, 2006, 08:16 UTC · re: Jeff King · lore

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

On Fri, Aug 04, 2006 at 11:21:35PM -0400, Jeff King wrote:
Show 15 quoted lines
> 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
Junio C Hamano· Aug 5, 2006, 09:28 UTC · re: Jeff King · lore

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

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?
Show 5 quoted lines
> +    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;;
Jeff King· Aug 5, 2006, 10:21 UTC · re: Junio C Hamano · lore

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

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
Jeff King· Aug 5, 2006, 10:44 UTC · re: Jeff King · lore

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

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
Matthias Lederhofer· Aug 5, 2006, 10:59 UTC · re: Jeff King · lore

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

Jeff King <peff@peff.net> wrote:
Show 9 quoted lines
> 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?
Junio C Hamano· Aug 5, 2006, 11:21 UTC · re: Matthias Lederhofer · lore

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

Matthias Lederhofer <matled@gmx.net> writes:
Show 19 quoted lines
> 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.
Junio C Hamano· Aug 5, 2006, 11:27 UTC · re: Junio C Hamano · lore

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

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'
Matthias Lederhofer· Aug 5, 2006, 11:28 UTC · re: Junio C Hamano · lore

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

Junio C Hamano <junkio@cox.net> wrote:
Show 7 quoted lines
> 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()?
Junio C Hamano· Aug 5, 2006, 11:42 UTC · re: Matthias Lederhofer · lore

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

Matthias Lederhofer <matled@gmx.net> writes:
Show 9 quoted lines
> 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.

Matthias Lederhofer· Aug 5, 2006, 12:18 UTC · re: Junio C Hamano · lore

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

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(-)
Show changes to 2 files +6 −1

git-commit.sh, pager.c

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
Jeff King· Aug 5, 2006, 19:54 UTC · re: Matthias Lederhofer · lore

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

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
Matthias Lederhofer· Aug 5, 2006, 20:31 UTC · re: Jeff King · lore

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

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

Jeff King· Aug 5, 2006, 23:42 UTC · re: Matthias Lederhofer · lore

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

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
Jeff King· Aug 5, 2006, 19:51 UTC · re: Junio C Hamano · lore

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

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
Sam Ravnborg· Aug 7, 2006, 17:12 UTC · re: Junio C Hamano · lore

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

> 
> 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
Jeff King· Aug 5, 2006, 19:45 UTC · re: Matthias Lederhofer · lore

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

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
Matthias Lederhofer· Aug 5, 2006, 20:27 UTC · re: Jeff King · lore

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

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.

Joel Becker· Aug 6, 2006, 05:01 UTC · re: Jeff King · lore

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

On Fri, Aug 04, 2006 at 11:14:19PM -0400, Jeff King wrote:
Show 7 quoted lines
> 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
Jeff King· Aug 6, 2006, 06:16 UTC · re: Joel Becker · lore

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

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

← back to recent threads