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

[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

[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

[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

[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