What's in git.git and announcing v1.4.1-rc1

What's in git.git and announcing v1.4.1-rc1

[Junio C Hamano]

I've merged quite a bit of stuff and tagged the tip of "master"
as GIT 1.4.1-rc1.

As promised, 1.4.X series will be managed slightly differently,
and this is in preparation of the first installment of it.  The
releases will come from the "master" branch to contain both
fixes and enhancements from now on.  Hotfix releases when
necessary would have 1.4.X.Y revision numbers, but I am hoping
that we do not have to do that very often.

Since all the exciting and potentially risky developments are to
happen on the "next" branch and they are supposed to graduate to
"master" branch after they are reasonably well cooked, this
change will help the end-users to stay reasonably current
without hopefully not introducing unexpected problems.  The
older scheme left out all the enhancements if people followed
packaged versions, and gave big surprises when upgrading from
version X.Y.Z to X.(Y+1).0 which was not so nice.

Notable improvements since v1.4.0 are:

 - PPC SHA1 routine can grok more than half-gig of data (Paul
   Mackerras)

 - rev-list and object-layer in general is less (much less)
   space hungry (Linus).

 - the source is more friendly to stricter compilers such as
   Sun's (Florian Forster).

 - git rebase --merge (Eric Wong).  This uses the usual 3-way
   merge machinery while running rebase, and you can rebase
   across renames if you use the recursive strategy which is the
   default.

 - gitweb updates -- mostly cleanups (Jakub Narebski with help
   from Pasky and Timo Hirvonen).

 - diff --color (Johannes).

 - ~/.gitconfig and $ENV{GIT_CONFIG} (Pasky and Johannes).

 - core.sharedrepository can take umask, group or world (Linus
   and I)

 - "git checkout -f" removes files that becomes untracked from
   the working tree

 - "git clone/fetch" from a corrupt repository does not
   propagate brokenness to the downloaders.

 - "git clone/fetch" over the network gives better progress
   updates; this may also help TCP timeout problems for people
   behind NAT.

 - Many more commands are built-in (Lukas Sandström)

 - git can now be used on Kiritimati (Paul Eggert)

----------------------------------------------------------------

* The 'master' branch has these since the last announcement.

   Andre Noll:
      object-refs: avoid division by zero

   David Woodhouse:
      Log peer address when git-daemon called from inetd

   Dennis Stosberg:
      Make t8001-annotate and t8002-blame more portable
      Fix t8001-annotate and t8002-blame for ActiveState Perl

   Eric W. Biederman:
      Fix git-format-patch -s
      Check and document the options to prevent mistakes.

   Eric Wong:
      git-svn: fix --rmdir when using SVN:: libraries
      rebase: Allow merge strategies to be used when rebasing
      rebase: error out for NO_PYTHON if they use recursive merge
      git-svn: fix commit --edit flag when using SVN:: libraries

   Florian Forster:
      Remove ranges from switch statements.
      Initialize FAMs using `FLEX_ARRAY'.
      Don't instantiate structures with FAMs.
      Cast pointers to `void *' when used in a format.
      Don't use empty structure initializers.
      Change types used in bitfields to be `int's.
      Remove all void-pointer arithmetic.

   Jakub Narebski:
      Move gitweb style to gitweb.css
      gitweb: safely output binary files for 'blob_plain' action
      gitweb: text files for 'blob_plain' action without charset by default
      Fix gitweb stylesheet
      Make CSS file gitweb/gitweb.css more readable
      gitweb: add type="text/css" to stylesheet link
      Fix: Support for the standard mime.types map in gitweb
      gitweb: A couple of page title tweaking
      gitweb: style done with stylesheet
      gitweb: whitespace cleanup
      Add git version to gitweb output
      Move $gitbin earlier in gitweb.cgi
      gitweb: Make use of $PATH_INFO for project parameter
      gitweb: whitespace cleanup around '='

   Johannes Schindelin:
      diff options: add --color
      Initialize lock_file struct to all zero.
      Fix setting config variables with an alternative GIT_CONFIG
      Read configuration also from $HOME/.gitconfig
      repo-config: Fix late-night bug
      git_config: access() returns 0 on success, not > 0

   Junio C Hamano:
      read-tree: --prefix=<path>/ option.
      write-tree: --prefix=<path>
      read-tree: reorganize bind_merge code.
      fetch-pack: give up after getting too many "ack continue"
      shared repository: optionally allow reading to "others".
      fix rfc2047 formatter.
      xdiff: minor changes to match libxdiff-0.21
      Restore SIGCHLD to SIG_DFL where we care about waitpid().
      checkout -f: do not leave untracked working tree files.
      upload-pack: avoid sending an incomplete pack upon failure
      upload-pack: prepare for sideband message support.
      Retire git-clone-pack
      upload-pack/fetch-pack: support side-band communication
      Add renaming-rebase test.
      daemon: send stderr to /dev/null instead of closing.
      rebase --merge: fix for rebasing more than 7 commits.
      Makefile: do not force unneeded recompilation upon GIT_VERSION changes

   Linus Torvalds:
      Shrink "struct object" a bit
      Move "void *util" from "struct object" into "struct commit"
      Some more memory leak avoidance
      Remove "refs" field from "struct object"
      Add specialized object allocator
      Add "named object array" concept
      Fix grow_refs_hash()

   Lukas Sandström:
      Make git-write-tree a builtin
      Make git-mailsplit a builtin
      Make git-mailinfo a builtin
      Make git-stripspace a builtin
      Make git-update-index a builtin
      Make git-update-ref a builtin

   Paul Eggert:
      date.c: improve guess between timezone offset and year.

   Paul Mackerras:
      Fix PPC SHA1 routine for large input buffers

   Petr Baudis:
      Support for extracting configuration from different files
      Support for the standard mime.types map in gitweb

   Rene Scharfe:
      git-tar-tree: Simplify write_trailer()
      git-tar-tree: documentation update
      git-tar-tree: no more void pointer arithmetic
      Make release tarballs friendlier to older tar versions

   Timo Hirvonen:
      gitweb: Use $hash_base as $search_hash if possible

   Uwe Zeisberger:
      Fix possible out-of-bounds array access

   Yakov Lerner:
      auto-detect changed prefix and/or changed build flags
      Pass -DDEFAULT_GIT_TEMPLATE_DIR only where actually used.


* The 'pu' branch, in addition, has these.

   Johannes Schindelin:
      Teach diff about -b and -w flags

   Lukas Sandström:
      Make it possible to call cmd_apply multiple times
      Make git-am a builtin

Re: What's in git.git and announcing v1.4.1-rc1

[Junio C Hamano]

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

> * The 'pu' branch, in addition, has these.
>
>    Johannes Schindelin:
>       Teach diff about -b and -w flags

I am hoping to coordinate the inclusion of this upstream first
and have this hopefully in the real 1.4.1 release.

>    Lukas Sandström:
>       Make it possible to call cmd_apply multiple times
>       Make git-am a builtin

Last time I tried this, it did not work for me, so I am putting
it on hold.  I feel, however, "am" is a high-enough-level tool
that we would prefer to keep it scriptable for quick tweaks.

If it is hurting portability because it is written in shell,
maybe this can be moved to all Perl (especially when Pasky's
Git.pm is ready) or Python.  Personally I think Windows minded
folks who cannot stand command-line interface Cygwin port gives
would not be satisfied anyway, until somebody writes a native
drag-this-mail-and-drop-on-that-brach tool, so porting the
command out of shell may not be even worth doing.  I dunno.

Re: What's in git.git and announcing v1.4.1-rc1

[Paolo Ciarrocchi]

On 6/22/06, Junio C Hamano <junkio@cox.net> wrote:
> I've merged quite a bit of stuff and tagged the tip of "master"
> as GIT 1.4.1-rc1.


Pulled and installed.

When I fire up gitk I see the following error messages, even if gitk
seems to be working fine:
paolo@Italia:~/git$ gitk
invalid command name ".ctop.cdet.left.ctext"
    while executing
"$ctext conf -state normal"
    (procedure "dispneartags" line 7)
    invoked from within
"dispneartags"
    (procedure "restartatags" line 28)
    invoked from within
"restartatags 869"
    ("after" script)


-- 
Paolo
http://paolociarrocchi.googlepages.com
http://picasaweb.google.com/paolo.ciarrocchi

Re: What's in git.git and announcing v1.4.1-rc1

[Linus Torvalds]

On Thu, 22 Jun 2006, Junio C Hamano wrote:
> 
>  - diff --color (Johannes).

I like colorized diffs, but let's face it, those particular color choices 
will make most people decide to pick out their eyes with a fondue fork.

And that's not good. Digging in your eye-sockets with a fondue fork is 
strictly considered to be bad for your health, and seven out of nine 
optometrists are dead set against the practice.

So in order to avoid a lot of blind git users, please apply this patch.

This patch does:

 - always reset the color _before_ printing out the newline.

   This is actually important. You (and Johannes) didn't see it, because 
   it only matters if you set the background, but if you don't do this, 
   you get some random and funky behaviour if you pick a color with a 
   non-default background (which still potentially has problems with tabs 
   etc, but less so).

 - allow people to have a different color for the "file headers" 
   (DIFF_METAINFO) and for the "fragment header" (DIFF_FRAGINFO). Also, 
   make a difference between "normal color" and "reset colors"

 - default to red/green for old/new lines. That's the norm, I'd think.

 - instead of that eye-popping (and eye-ball-with-a-fondue-fork-popping) 
   purple color for metadata, use bold-face for file headers, and cyan for 
   the frag headers. I actually prefer the "gray background" for that, but 
   it only works well in xterms, so COLOR_CYAN it is..

Hmm?

		Linus
---
 diff.c |   99 +++++++++++++++++++++++++++++++++++++---------------------------
 1 files changed, 58 insertions(+), 41 deletions(-)

diff --git a/diff.c b/diff.c
index 22b643c..07e9d56 100644
--- a/diff.c
+++ b/diff.c
@@ -26,17 +26,41 @@ int git_diff_config(const char *var, con
 }
 
 enum color_diff {
-	DIFF_PLAIN = 0,
-	DIFF_METAINFO = 1,
-	DIFF_FILE_OLD = 2,
-	DIFF_FILE_NEW = 3,
+	DIFF_RESET = 0,
+	DIFF_PLAIN = 1,
+	DIFF_METAINFO = 2,
+	DIFF_FRAGINFO = 3,
+	DIFF_FILE_OLD = 4,
+	DIFF_FILE_NEW = 5,
 };
 
+#define COLOR_NORMAL  ""
+#define COLOR_BOLD    "\033[1m"
+#define COLOR_DIM     "\033[2m"
+#define COLOR_UL      "\033[4m"
+#define COLOR_BLINK   "\033[5m"
+#define COLOR_REVERSE "\033[7m"
+#define COLOR_RESET   "\033[m"
+
+#define COLOR_BLACK   "\033[30m"
+#define COLOR_RED     "\033[31m"
+#define COLOR_GREEN   "\033[32m"
+#define COLOR_YELLOW  "\033[33m"
+#define COLOR_BLUE    "\033[34m"
+#define COLOR_MAGENTA "\033[35m"
+#define COLOR_CYAN    "\033[36m"
+#define COLOR_WHITE   "\033[37m"
+
+#define COLOR_CYANBG  "\033[46m"
+#define COLOR_GRAYBG  "\033[47m"	// Good for xterm
+
 static const char *diff_colors[] = {
-	"\033[0;0m",
-	"\033[1;35m",
-	"\033[1;31m",
-	"\033[1;34m",
+	[DIFF_RESET]    = COLOR_RESET,
+	[DIFF_PLAIN]    = COLOR_NORMAL,
+	[DIFF_METAINFO] = COLOR_BOLD,
+	[DIFF_FRAGINFO] = COLOR_CYAN,
+	[DIFF_FILE_OLD] = COLOR_RED,
+	[DIFF_FILE_NEW] = COLOR_GREEN,
 };
 
 static char *quote_one(const char *str)
@@ -196,22 +220,23 @@ struct emit_callback {
 	const char **label_path;
 };
 
-static inline void color_diff(int diff_use_color, enum color_diff ix)
+static inline const char *get_color(int diff_use_color, enum color_diff ix)
 {
 	if (diff_use_color)
-		fputs(diff_colors[ix], stdout);
+		return diff_colors[ix];
+	return "";
 }
 
 static void fn_out_consume(void *priv, char *line, unsigned long len)
 {
 	int i;
 	struct emit_callback *ecbdata = priv;
+	const char *set = get_color(ecbdata->color_diff, DIFF_METAINFO);
+	const char *reset = get_color(ecbdata->color_diff, DIFF_RESET);	
 
 	if (ecbdata->label_path[0]) {
-		color_diff(ecbdata->color_diff, DIFF_METAINFO);
-		printf("--- %s\n", ecbdata->label_path[0]);
-		color_diff(ecbdata->color_diff, DIFF_METAINFO);
-		printf("+++ %s\n", ecbdata->label_path[1]);
+		printf("%s--- %s%s\n", set, ecbdata->label_path[0], reset);
+		printf("%s+++ %s%s\n", set, ecbdata->label_path[1], reset);
 		ecbdata->label_path[0] = ecbdata->label_path[1] = NULL;
 	}
 
@@ -222,10 +247,10 @@ static void fn_out_consume(void *priv, c
 		;
 	if (2 <= i && i < len && line[i] == ' ') {
 		ecbdata->nparents = i - 1;
-		color_diff(ecbdata->color_diff, DIFF_METAINFO);
+		set = get_color(ecbdata->color_diff, DIFF_FRAGINFO);
 	}
 	else if (len < ecbdata->nparents)
-		color_diff(ecbdata->color_diff, DIFF_PLAIN);
+		set = reset;
 	else {
 		int nparents = ecbdata->nparents;
 		int color = DIFF_PLAIN;
@@ -235,10 +260,11 @@ static void fn_out_consume(void *priv, c
 			else if (line[i] == '+')
 				color = DIFF_FILE_NEW;
 		}
-		color_diff(ecbdata->color_diff, color);
+		set = get_color(ecbdata->color_diff, color);
 	}
-	fwrite(line, len, 1, stdout);
-	color_diff(ecbdata->color_diff, DIFF_PLAIN);
+	if (len > 0 && line[len-1] == '\n')
+		len--;
+	printf("%s%.*s%s\n", set, (int) len, line, reset);
 }
 
 static char *pprint_rename(const char *a, const char *b)
@@ -589,40 +615,32 @@ static void builtin_diff(const char *nam
 	mmfile_t mf1, mf2;
 	const char *lbl[2];
 	char *a_one, *b_two;
+	const char *set = get_color(o->color_diff, DIFF_METAINFO);
+	const char *reset = get_color(o->color_diff, DIFF_PLAIN);
 
 	a_one = quote_two("a/", name_a);
 	b_two = quote_two("b/", name_b);
 	lbl[0] = DIFF_FILE_VALID(one) ? a_one : "/dev/null";
 	lbl[1] = DIFF_FILE_VALID(two) ? b_two : "/dev/null";
-	color_diff(o->color_diff, DIFF_METAINFO);
-	printf("diff --git %s %s\n", a_one, b_two);
+	printf("%sdiff --git %s %s%s\n", set, a_one, b_two, reset);
 	if (lbl[0][0] == '/') {
 		/* /dev/null */
-		color_diff(o->color_diff, DIFF_METAINFO);
-		printf("new file mode %06o\n", two->mode);
-		if (xfrm_msg && xfrm_msg[0]) {
-			color_diff(o->color_diff, DIFF_METAINFO);
-			puts(xfrm_msg);
-		}
+		printf("%snew file mode %06o%s\n", set, two->mode, reset);
+		if (xfrm_msg && xfrm_msg[0])
+			printf("%s%s%s\n", set, xfrm_msg, reset);
 	}
 	else if (lbl[1][0] == '/') {
-		printf("deleted file mode %06o\n", one->mode);
-		if (xfrm_msg && xfrm_msg[0]) {
-			color_diff(o->color_diff, DIFF_METAINFO);
-			puts(xfrm_msg);
-		}
+		printf("%sdeleted file mode %06o%s\n", set, one->mode, reset);
+		if (xfrm_msg && xfrm_msg[0])
+			printf("%s%s%s\n", set, xfrm_msg, reset);
 	}
 	else {
 		if (one->mode != two->mode) {
-			color_diff(o->color_diff, DIFF_METAINFO);
-			printf("old mode %06o\n", one->mode);
-			color_diff(o->color_diff, DIFF_METAINFO);
-			printf("new mode %06o\n", two->mode);
-		}
-		if (xfrm_msg && xfrm_msg[0]) {
-			color_diff(o->color_diff, DIFF_METAINFO);
-			puts(xfrm_msg);
+			printf("%sold mode %06o%s\n", set, one->mode, reset);
+			printf("%snew mode %06o%s\n", set, two->mode, reset);
 		}
+		if (xfrm_msg && xfrm_msg[0])
+			printf("%s%s%s\n", set, xfrm_msg, reset);
 		/*
 		 * we do not run diff between different kind
 		 * of objects.
@@ -630,7 +648,6 @@ static void builtin_diff(const char *nam
 		if ((one->mode ^ two->mode) & S_IFMT)
 			goto free_ab_and_return;
 		if (complete_rewrite) {
-			color_diff(o->color_diff, DIFF_PLAIN);
 			emit_rewrite_diff(name_a, name_b, one, two);
 			goto free_ab_and_return;
 		}

Re: What's in git.git and announcing v1.4.1-rc1

[Petr Baudis]

Dear diary, on Thu, Jun 22, 2006 at 10:53:31PM CEST, I got a letter
where Linus Torvalds <torvalds@osdl.org> said that...
> So in order to avoid a lot of blind git users, please apply this patch.

Great, since this also seems to make git diff more or less consistent
with cg diff in the colors choice.

>  enum color_diff {
> -	DIFF_PLAIN = 0,
> -	DIFF_METAINFO = 1,
> -	DIFF_FILE_OLD = 2,
> -	DIFF_FILE_NEW = 3,
> +	DIFF_RESET = 0,
> +	DIFF_PLAIN = 1,
> +	DIFF_METAINFO = 2,
> +	DIFF_FRAGINFO = 3,
> +	DIFF_FILE_OLD = 4,
> +	DIFF_FILE_NEW = 5,
>  };

Isn't manually numbering the enum choices somewhat pointless, though?
(Actually makes it more difficult to do changes in it later.)

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
A person is just about as big as the things that make them angry.

Re: What's in git.git and announcing v1.4.1-rc1

[Linus Torvalds]

On Thu, 22 Jun 2006, Petr Baudis wrote:
> 
> Isn't manually numbering the enum choices somewhat pointless, though?
> (Actually makes it more difficult to do changes in it later.)

Yeah, I just mindlessly followed Johannes' original scheme. 

		Linus

Re: What's in git.git and announcing v1.4.1-rc1

[Jakub Narebski]

Linus Torvalds wrote:

> 
> 
> On Thu, 22 Jun 2006, Petr Baudis wrote:
>> 
>> Isn't manually numbering the enum choices somewhat pointless, though?
>> (Actually makes it more difficult to do changes in it later.)
> 
> Yeah, I just mindlessly followed Johannes' original scheme. 

You might want to start at 0, just in case...

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: What's in git.git and announcing v1.4.1-rc1

[Petr Baudis]

> >> Isn't manually numbering the enum choices somewhat pointless, though?
> >> (Actually makes it more difficult to do changes in it later.)
> > 
> > Yeah, I just mindlessly followed Johannes' original scheme. 
> 
> You might want to start at 0, just in case...

C99 (6.7.2.2) guarantees the enumeration constants start at 0 if not
specified otherwise.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
A person is just about as big as the things that make them angry.

Re: What's in git.git and announcing v1.4.1-rc1

[Junio C Hamano]

Linus Torvalds <torvalds@osdl.org> writes:

> On Thu, 22 Jun 2006, Junio C Hamano wrote:
>> 
>>  - diff --color (Johannes).
>
> I like colorized diffs, but let's face it, those particular color choices 
> will make most people decide to pick out their eyes with a fondue fork.

Well, I admit I do not use colorized diffs myself.  As a matter
of fact, I use specialized terminfo to disable coloring on my
terminal session, since fontifying in GNUS otherwise gives me
unreadable screen and I am too lazy to figure out how to turn it
off.

I do however usually test colored stuff with at least white and
black backgrounds,

> This patch does:
>
>  - always reset the color _before_ printing out the newline.

Sorry, although I did notice this (interrupting a long diff, or
running it with "less -r" and quitting it would leave the
terminal in funny color), I did not bother to fix it.

>  - default to red/green for old/new lines. That's the norm, I'd think.

OK.

>  - instead of that eye-popping (and eye-ball-with-a-fondue-fork-popping) 
>    purple color for metadata, use bold-face for file headers, and cyan for 
>    the frag headers. I actually prefer the "gray background" for that, but 
>    it only works well in xterms, so COLOR_CYAN it is..

Replacing it with COLOR_GRAYBG did not work out too well with
either xterm nor kterm for me, although it did work under
gnome-terminal.

Cyan foreground color is unreadable on white background and that
was why I did magenta in my original patch, but it may be just
that I am color challenged in that spectrum.

Re: What's in git.git and announcing v1.4.1-rc1

[Junio C Hamano]

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

> Well, I admit I do not use colorized diffs myself.  As a matter
> of fact, I use specialized terminfo to disable coloring on my
> terminal session, since fontifying in GNUS otherwise gives me
> unreadable screen and I am too lazy to figure out how to turn it
> off.
>
> I do however usually test colored stuff with at least white and
> black backgrounds,

By the way, in the ancient history, in commit 3443546 you did:

--- a/Makefile
+++ b/Makefile
@@ -544,12 +545,18 @@ init-db.o: init-db.c
                -DDEFAULT_GIT_TEMPLATE_DIR='"$(template_dir_SQ)"' $*.c

 $(LIB_OBJS): $(LIB_H)
-$(patsubst git-%$X,%.o,$(PROGRAMS)): $(LIB_H)
+$(patsubst git-%$X,%.o,$(PROGRAMS)): $(LIBS)
 $(DIFF_OBJS): diffcore.h

 $(LIB_FILE): $(LIB_OBJS)
        $(AR) rcs $@ $(LIB_OBJS)

which we kept until today.  This causes checkout-index.o and
friends to be recompiled when we touch diff.c (I do not mind
relinking git-checkout-index because libgit.a has changed, but
recompiling checkout-index.c is unneeded).  I think this was
done to make sure anything that includes xdiff/*.h files via
"xdiff-interface.h" are recompiled when xdiff/*.h are changed,
so I am thinking about loosening it a bit to depend on our
headers and xdiff/*.h headers, perhaps like this:

diff --git a/Makefile b/Makefile
index a5b6784..e29e3fa 100644
--- a/Makefile
+++ b/Makefile
@@ -582,7 +582,7 @@ git-http-push$X: revision.o http.o http-
 		$(LIBS) $(CURL_LIBCURL) $(EXPAT_LIBEXPAT)
 
 $(LIB_OBJS) $(BUILTIN_OBJS): $(LIB_H)
-$(patsubst git-%$X,%.o,$(PROGRAMS)): $(GITLIBS)
+$(patsubst git-%$X,%.o,$(PROGRAMS)): $(LIB_H) $(wildcard */*.h)
 $(DIFF_OBJS): diffcore.h
 
 $(LIB_FILE): $(LIB_OBJS)
diff --git a/diff.c b/diff.c
diff --git a/xdiff/xdiff.h b/xdiff/xdiff.h

Re: What's in git.git and announcing v1.4.1-rc1

[Johannes Schindelin]

Hi,

On Thu, 22 Jun 2006, Linus Torvalds wrote:

> On Thu, 22 Jun 2006, Junio C Hamano wrote:
> > 
> >  - diff --color (Johannes).
> 
>  - default to red/green for old/new lines. That's the norm, I'd think.

... and which happens to be useless for 10% of the male population (and 
even more if you look specifically at Asian people). But then, I just 
pasted that part from somewhere else.

Besides, I rarely have a fondue fork handy when I sit in front of the 
computer. I actually do not own one. And when I am sitting in front of the 
computer, shops typically are closed (yeah, I am living in Germany, but we 
_do_ have cars...). So at least for 100% of the writers of this email, 
your warning just does not apply.

Ciao,
Dscho

Re: What's in git.git and announcing v1.4.1-rc1

[Johannes Schindelin]

Hi,

On Thu, 22 Jun 2006, Linus Torvalds wrote:

> On Thu, 22 Jun 2006, Petr Baudis wrote:
> > 
> > Isn't manually numbering the enum choices somewhat pointless, though?
> > (Actually makes it more difficult to do changes in it later.)
> 
> Yeah, I just mindlessly followed Johannes' original scheme. 

... which wasn't his, to begin with ...

Re: What's in git.git and announcing v1.4.1-rc1

[Pádraig Brady]

Johannes Schindelin wrote:
> Hi,
> 
> On Thu, 22 Jun 2006, Linus Torvalds wrote:
> 
> 
>>On Thu, 22 Jun 2006, Junio C Hamano wrote:
>>
>>> - diff --color (Johannes).
>>
>> - default to red/green for old/new lines. That's the norm, I'd think.
> 
> 
> ... and which happens to be useless for 10% of the male population (and 
> even more if you look specifically at Asian people). But then, I just 
> pasted that part from somewhere else.

:)

So 10% of the male population need to learn
traffic light positions rather than colours?

I'm red/green colour blind which means I can't
distinguish _subtley_ different shades of red and green.

vim is another fondue fork offender as it merges
syntax highlighting and diff colours in diff mode (vimdiff).
I put the following in ~/.vimrc to disable that madness:

if &diff
    "I'm only interested in diff colours
    syntax off
endif

Pádraig.

Re: What's in git.git and announcing v1.4.1-rc1

[Johannes Schindelin]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 376 bytes --]

Hi,

On Fri, 23 Jun 2006, Pádraig Brady wrote:

> So 10% of the male population need to learn traffic light positions 
> rather than colours?

A friend of mine was at the military and had to check new recruits for 
color-blindness. Only after the 20th color-blind man in a row he realized 
for the first time in hist life that it was _him_, being the color-blind.

Ciao,
Dscho

Re: What's in git.git and announcing v1.4.1-rc1

[Linus Torvalds]

On Fri, 23 Jun 2006, Johannes Schindelin wrote:
> > 
> >  - default to red/green for old/new lines. That's the norm, I'd think.
> 
> ... and which happens to be useless for 10% of the male population (and 
> even more if you look specifically at Asian people). But then, I just 
> pasted that part from somewhere else.

Sure. 

(Although I think it's 7% in general, and more in certain populations, 
some Western European countries included)

Which just means that we should have some way to let people set their own 
colors.

The _default_ should be the one people expect, though.

		Linus

[PATCH] diff --color: use $GIT_DIR/config

[Junio C Hamano]

This lets you use something like this in your $GIT_DIR/config
file.

	[diff]
		color = auto

	[diff.color]
		new = blue
		old = yellow
		frag = reverse

When diff.color is set to "auto", colored diff is enabled when
the standard output is the terminal.  Other choices are "always",
and "never".  Usual boolean true/false can also be used.

The colormap entries can specify colors for the following slots:

	plain	- lines that appear in both old and new file (context)
	meta	- diff --git header and extended git diff headers
	frag	- @@ -n,m +l,k @@ lines (hunk header)
	old	- lines deleted from old file
	new	- lines added to new file

The following color names can be used:

	normal, bold, dim, l, blink, reverse, reset,
	black, red, green, yellow, blue, magenta, cyan,
	white

Signed-off-by: Junio C Hamano <junkio@cox.net>

---

 Linus Torvalds <torvalds@osdl.org> writes:

 > Which just means that we should have some way to let people set their own 
 > colors.

 At the source level it is easy to specify color and attribute
 combinations (e.g. "bold|red") by having the preprocessor
 concatenate string literals, but I was too lazy to allow that
 from the configuration level.  People might want to have that,
 though.

 BTW, while doing this, I noticed that the patch does not do the
 color output for combined diffs.  Care to look into it after
 Timo's output format series settles?

 cache.h |    1 -
 diff.c  |   94 ++++++++++++++++++++++++++++++++++++++++++++++++++++++---------
 2 files changed, 80 insertions(+), 15 deletions(-)

diff --git a/cache.h b/cache.h
index efeafea..3502fee 100644
--- a/cache.h
+++ b/cache.h
@@ -181,7 +181,6 @@ extern int assume_unchanged;
 extern int prefer_symlink_refs;
 extern int log_all_ref_updates;
 extern int warn_ambiguous_refs;
-extern int diff_rename_limit_default;
 extern int shared_repository;
 extern const char *apply_default_whitespace;
 
diff --git a/diff.c b/diff.c
index 1db0285..33c8c57 100644
--- a/diff.c
+++ b/diff.c
@@ -13,17 +13,8 @@ #include "xdiff-interface.h"
 
 static int use_size_cache;
 
-int diff_rename_limit_default = -1;
-
-int git_diff_config(const char *var, const char *value)
-{
-	if (!strcmp(var, "diff.renamelimit")) {
-		diff_rename_limit_default = git_config_int(var, value);
-		return 0;
-	}
-
-	return git_default_config(var, value);
-}
+static int diff_rename_limit_default = -1;
+static int diff_use_color_default = 0;
 
 enum color_diff {
 	DIFF_RESET = 0,
@@ -51,9 +42,6 @@ #define COLOR_MAGENTA "\033[35m"
 #define COLOR_CYAN    "\033[36m"
 #define COLOR_WHITE   "\033[37m"
 
-#define COLOR_CYANBG  "\033[46m"
-#define COLOR_GRAYBG  "\033[47m"	// Good for xterm
-
 static const char *diff_colors[] = {
 	[DIFF_RESET]    = COLOR_RESET,
 	[DIFF_PLAIN]    = COLOR_NORMAL,
@@ -63,6 +51,83 @@ static const char *diff_colors[] = {
 	[DIFF_FILE_NEW] = COLOR_GREEN,
 };
 
+static int parse_diff_color_slot(const char *var, int ofs)
+{
+	if (!strcasecmp(var+ofs, "plain"))
+		return DIFF_PLAIN;
+	if (!strcasecmp(var+ofs, "meta"))
+		return DIFF_METAINFO;
+	if (!strcasecmp(var+ofs, "frag"))
+		return DIFF_FRAGINFO;
+	if (!strcasecmp(var+ofs, "old"))
+		return DIFF_FILE_OLD;
+	if (!strcasecmp(var+ofs, "new"))
+		return DIFF_FILE_NEW;
+	die("bad config variable '%s'", var);
+}
+
+static const char *parse_diff_color_value(const char *value, const char *var)
+{
+	if (!strcasecmp(value, "normal"))
+		return COLOR_NORMAL;
+	if (!strcasecmp(value, "bold"))
+		return COLOR_BOLD;
+	if (!strcasecmp(value, "dim"))
+		return COLOR_DIM;
+	if (!strcasecmp(value, "ul"))
+		return COLOR_UL;
+	if (!strcasecmp(value, "blink"))
+		return COLOR_BLINK;
+	if (!strcasecmp(value, "reverse"))
+		return COLOR_REVERSE;
+	if (!strcasecmp(value, "reset"))
+		return COLOR_RESET;
+	if (!strcasecmp(value, "black"))
+		return COLOR_BLACK;
+	if (!strcasecmp(value, "red"))
+		return COLOR_RED;
+	if (!strcasecmp(value, "green"))
+		return COLOR_GREEN;
+	if (!strcasecmp(value, "yellow"))
+		return COLOR_YELLOW;
+	if (!strcasecmp(value, "blue"))
+		return COLOR_BLUE;
+	if (!strcasecmp(value, "magenta"))
+		return COLOR_MAGENTA;
+	if (!strcasecmp(value, "cyan"))
+		return COLOR_CYAN;
+	if (!strcasecmp(value, "white"))
+		return COLOR_WHITE;
+	die("bad config value '%s' for variable '%s'", value, var);
+}
+
+int git_diff_config(const char *var, const char *value)
+{
+	if (!strcmp(var, "diff.renamelimit")) {
+		diff_rename_limit_default = git_config_int(var, value);
+		return 0;
+	}
+	if (!strcmp(var, "diff.color")) {
+		if (!value)
+			diff_use_color_default = 1; /* bool */
+		else if (!strcasecmp(value, "auto"))
+			diff_use_color_default = isatty(1);
+		else if (!strcasecmp(value, "never"))
+			diff_use_color_default = 0;
+		else if (!strcasecmp(value, "always"))
+			diff_use_color_default = 1;
+		else
+			diff_use_color_default = git_config_bool(var, value);
+		return 0;
+	}
+	if (!strncmp(var, "diff.color.", 11)) {
+		int slot = parse_diff_color_slot(var, 11);
+		diff_colors[slot] = parse_diff_color_value(value, var);
+		return 0;
+	}
+	return git_default_config(var, value);
+}
+
 static char *quote_one(const char *str)
 {
 	int needlen;
@@ -1362,6 +1427,7 @@ void diff_setup(struct diff_options *opt
 
 	options->change = diff_change;
 	options->add_remove = diff_addremove;
+	options->color_diff = diff_use_color_default;
 }
 
 int diff_setup_done(struct diff_options *options)
-- 
1.4.1.rc1.ga77b7

[PATCH] diff --color: use reset sequence when we mean reset.

[Junio C Hamano]

Signed-off-by: Junio C Hamano <junkio@cox.net>
---

 Linus Torvalds <torvalds@osdl.org> writes:

 >  - always reset the color _before_ printing out the newline.
 >
 >    This is actually important. You (and Johannes) didn't see it, because 
 >    it only matters if you set the background, but if you don't do this, 
 >    you get some random and funky behaviour if you pick a color with a 
 >    non-default background (which still potentially has problems with tabs 
 >    etc, but less so).

 Doh.

 I think you did not see it until you tried "git diff" with
 a stat-dirty but otherwise unmodified file.

 diff.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/diff.c b/diff.c
index 33c8c57..549f4e0 100644
--- a/diff.c
+++ b/diff.c
@@ -681,7 +681,7 @@ static void builtin_diff(const char *nam
 	const char *lbl[2];
 	char *a_one, *b_two;
 	const char *set = get_color(o->color_diff, DIFF_METAINFO);
-	const char *reset = get_color(o->color_diff, DIFF_PLAIN);
+	const char *reset = get_color(o->color_diff, DIFF_RESET);
 
 	a_one = quote_two("a/", name_a);
 	b_two = quote_two("b/", name_b);
-- 
1.4.1.rc1.ga77b7

Re: [PATCH] diff --color: use $GIT_DIR/config

[Johannes Schindelin]

Hi,

On Sat, 24 Jun 2006, Junio C Hamano wrote:

>  BTW, while doing this, I noticed that the patch does not do the
>  color output for combined diffs.  Care to look into it after
>  Timo's output format series settles?

You mean just copying the relevant parts from your patch, which I missed, 
and do minimal testing? Sure ;-)

But first, by way of thanks to Martin, I have to reintroduce into 
format-patch the check for patches which are already upstream.

Ciao,
Dscho