What's in git.git (stable frozen)

What's in git.git (stable frozen)

[Junio C Hamano]

There are a good deal of bugfixes in 'master', the largest of
which is Brandon Casey's fix to builtin-commit and others'
misuse of lockfile API.  A tentative fix for the issue was
pushed out last night but the approach has known issues for our
Windowsy friends, and this attempts to address them.

We've been taking pride that the tip of 'master' is always,
without regression, more stable than any released version, but
today's one might have uncovered glitches.  Please help testing
it so that we do not have to leave it broken for a long time if
it indeed is.

I spent quite a lot of time trying to come up with a simple
reproduction recipe for the builtin-commit breakage, but I
couldn't.  I also wanted to apply the patch to remove the use
(but not implementation) of repo-config along with a removal
notice in the release notes but haven't got around to.

Aside from obviously correct trivial fixes that may come from
the list, what currently is not in 'master' but should be in the
rc4 are very minimal.  Brandon Casey's lockfile fix needs to be
tested for some time, repo-config deprecation notice needs to be
posted, and "\C-+" patch for gitk needs to be pulled from Paul.
I see French translation for git-gui in Shawn's repository, but
I do not know if it, along with other changes to git-gui, are
meant for 1.5.4 or not.  If they are, I'd like to include them
all before tagging rc4.

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

* The 'master' branch has these since the last announcement
  in addition to the above.

Bill Lear (1):
  Correct spelling in diff.c comment

Brandon Casey (3):
  close_lock_file(): new function in the lockfile API
  Improve use of lockfile API
  refs.c: rework ref_locks by abstracting from underlying struct lock_file

Dan McGee (2):
  Remove usage of git- (dash) commands from email hook
  cvsimport: remove last use of repo-config from git standard tools

Dave Peticolas (1):
  Documentation: fix and clarify grammar in git-merge docs.

Dmitry Potapov (1):
  treat any file with NUL as binary

Jean-Luc Herren (1):
  Make default pre-commit hook less noisy

Junio C Hamano (4):
  Revert "builtin-commit.c: remove useless check added by faulty cut and
    paste"
  Fix git-rerere documentation
  Squelch bogus progress output from git-rebase--interactive
  Document lockfile API

Kristian Høgsberg (1):
  git-commit: fix double close(2) that can close a wrong file descriptor

Linus Torvalds (3):
  Make builtin-commit.c more careful about parenthood
  Make 'git fsck' complain about non-commit branches
  Be more careful about updating refs

Mark Drago (1):
  hg-to-git: improve popen calls

Miklos Vajna (2):
  Add using merge subtree How-To
  ls-remote: add -t and -h options.

Re: What's in git.git (stable frozen)

[Johannes Sixt]

Junio C Hamano schrieb:
> There are a good deal of bugfixes in 'master', the largest of
> which is Brandon Casey's fix to builtin-commit and others'
> misuse of lockfile API.  A tentative fix for the issue was
> pushed out last night but the approach has known issues for our
> Windowsy friends, and this attempts to address them.
> 
> We've been taking pride that the tip of 'master' is always,
> without regression, more stable than any released version, but
> today's one might have uncovered glitches.  Please help testing
> it so that we do not have to leave it broken for a long time if
> it indeed is.

Except for the NO_MMAP issue introduced by c3b0dec509f that kills
git-fast-import in t9301* as discussed in a parallel thread, all tests
pass on Windows (MinGW port). This is a good sign since most, if not all,
issues around the lockfile API have been discovered by the test suite in
the past.

-- Hannes

[PATCH] fast-import.c: don't try to commit marks file if write failed

[Brandon Casey]

We also move the assignment of -1 to the lock file descriptor
up, so that rollback_lock_file() can be called safely after a
possible attempt to fclose(). This matches the contents of
the 'if' statement just above testing success of fdopen().

Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
---


Since we forget the lock file descriptor there is a chance
that we will leave the file open if a write error occurs. We'll
still delete the file. I don't think it's worth bending
over backwards to make sure the file is closed on this failure.

-brandon


 fast-import.c |   24 ++++++++++++++++--------
 1 files changed, 16 insertions(+), 8 deletions(-)

diff --git a/fast-import.c b/fast-import.c
index 3609c24..4cf5092 100644
--- a/fast-import.c
+++ b/fast-import.c
@@ -1545,19 +1545,27 @@ static void dump_marks(void)
 		return;
 	}
 
-	dump_marks_helper(f, 0, marks);
-	if (ferror(f) || fclose(f))
-		failure |= error("Unable to write marks file %s: %s",
-			mark_file, strerror(errno));
 	/*
-	 * Since the lock file was fdopen()'ed and then fclose()'ed above,
-	 * assign -1 to the lock file descriptor so that commit_lock_file()
+	 * Since the lock file was fdopen()'ed, it should not be close()'ed.
+	 * Assign -1 to the lock file descriptor so that commit_lock_file()
 	 * won't try to close() it.
 	 */
 	mark_lock.fd = -1;
-	if (commit_lock_file(&mark_lock))
-		failure |= error("Unable to write commit file %s: %s",
+
+	dump_marks_helper(f, 0, marks);
+	if (ferror(f) || fclose(f)) {
+		rollback_lock_file(&mark_lock);
+		failure |= error("Unable to write marks file %s: %s",
 			mark_file, strerror(errno));
+		return;
+	}
+
+	if (commit_lock_file(&mark_lock)) {
+		rollback_lock_file(&mark_lock);
+		failure |= error("Unable to commit marks file %s: %s",
+			mark_file, strerror(errno));
+		return;
+	}
 }
 
 static int read_next_command(void)
-- 
1.5.4.rc3.17.gb63a4

Re: What's in git.git (stable frozen)

[Brandon Casey]

In lockfile.c:commit_locked_index()

You didn't include the portion of your patch that
assigned NULL to alternate_index_output before
attempting to close and rename.

Should that be included?

-brandon



Junio C Hamano wrote:

@@ -185,9 +198,15 @@ void set_alternate_index_output(const char *name)
 int commit_locked_index(struct lock_file *lk)
 {
 	if (alternate_index_output) {
-		int result = rename(lk->filename, alternate_index_output);
-		lk->filename[0] = 0;
-		return result;
+		const char *newname = alternate_index_output;
+		alternate_index_output = NULL;

Re: What's in git.git (stable frozen)

[Junio C Hamano]

Brandon Casey <casey@nrlssc.navy.mil> writes:

> In lockfile.c:commit_locked_index()
>
> You didn't include the portion of your patch that
> assigned NULL to alternate_index_output before
> attempting to close and rename.
>
> Should that be included?

You are right, but that is a separate topic and should be a
separate patch, so I dropped the hunk from that commit.

Re: [PATCH] fast-import.c: don't try to commit marks file if write failed

[Junio C Hamano]

Brandon Casey <casey@nrlssc.navy.mil> writes:

> We also move the assignment of -1 to the lock file descriptor
> up, so that rollback_lock_file() can be called safely after a
> possible attempt to fclose(). This matches the contents of
> the 'if' statement just above testing success of fdopen().
>
> Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
> ---

Shawn, could you lend an extra set of eyeballs on this one
please?  It looks sane to me but obviously you are more familiar
with the code.

> Since we forget the lock file descriptor there is a chance
> that we will leave the file open if a write error occurs. We'll
> still delete the file. I don't think it's worth bending
> over backwards to make sure the file is closed on this failure.
>
> -brandon
>
>
>  fast-import.c |   24 ++++++++++++++++--------
>  1 files changed, 16 insertions(+), 8 deletions(-)
>
> diff --git a/fast-import.c b/fast-import.c
> index 3609c24..4cf5092 100644
> --- a/fast-import.c
> +++ b/fast-import.c
> @@ -1545,19 +1545,27 @@ static void dump_marks(void)
>  		return;
>  	}
>  
> -	dump_marks_helper(f, 0, marks);
> -	if (ferror(f) || fclose(f))
> -		failure |= error("Unable to write marks file %s: %s",
> -			mark_file, strerror(errno));
>  	/*
> -	 * Since the lock file was fdopen()'ed and then fclose()'ed above,
> -	 * assign -1 to the lock file descriptor so that commit_lock_file()
> +	 * Since the lock file was fdopen()'ed, it should not be close()'ed.
> +	 * Assign -1 to the lock file descriptor so that commit_lock_file()
>  	 * won't try to close() it.
>  	 */
>  	mark_lock.fd = -1;
> -	if (commit_lock_file(&mark_lock))
> -		failure |= error("Unable to write commit file %s: %s",
> +
> +	dump_marks_helper(f, 0, marks);
> +	if (ferror(f) || fclose(f)) {
> +		rollback_lock_file(&mark_lock);
> +		failure |= error("Unable to write marks file %s: %s",
>  			mark_file, strerror(errno));
> +		return;
> +	}
> +
> +	if (commit_lock_file(&mark_lock)) {
> +		rollback_lock_file(&mark_lock);
> +		failure |= error("Unable to commit marks file %s: %s",
> +			mark_file, strerror(errno));
> +		return;
> +	}
>  }
>  
>  static int read_next_command(void)
> -- 
> 1.5.4.rc3.17.gb63a4

Re: [PATCH] fast-import.c: don't try to commit marks file if write failed

[Shawn O. Pearce]

Junio C Hamano <gitster@pobox.com> wrote:
> Brandon Casey <casey@nrlssc.navy.mil> writes:
> 
> > We also move the assignment of -1 to the lock file descriptor
> > up, so that rollback_lock_file() can be called safely after a
> > possible attempt to fclose(). This matches the contents of
> > the 'if' statement just above testing success of fdopen().
> >
> > Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
> > ---
> 
> Shawn, could you lend an extra set of eyeballs on this one
> please?  It looks sane to me but obviously you are more familiar
> with the code.

I agree.

Acked-by: Shawn O. Pearce <spearce@spearce.org>
 
-- 
Shawn.

Re: What's in git.git (stable frozen)

[Shawn O. Pearce]

Junio C Hamano <gitster@pobox.com> wrote:
> I see French translation for git-gui in Shawn's repository, but
> I do not know if it, along with other changes to git-gui, are
> meant for 1.5.4 or not.  If they are, I'd like to include them
> all before tagging rc4.

I have a few changes queued for 0.9.2, which I'd like to get done
and included before 1.5.4, plus I'd like to get Mark Levedahl's
DESTDIR issue resolved before then too.


.... changes since 0.9.1 ....

Christian Couder (2):
      git-gui: Initial french translation
      git-gui: add french glossary: glossary/fr.po

Christian Stimming (4):
      git-gui: Update glossary: add term "hunk"
      git-gui: Update German translation
      git-gui: Fix broken revert confirmation.
      git-gui: Improve German translation.

Peter Karlsson (1):
      git-gui: Updated Swedish translation after mailing list review.

Shawn O. Pearce (2):
      git-gui: Allow 'Create New Repository' on existing directories
      git-gui: Refresh file status description after hunk application

-- 
Shawn.

What's in git.git (stable frozen)

[Junio C Hamano]

There shouldn't be anything eye-popping.  Hopefully we can do
the final soonish, perhaps this weekend.

I may have made small touch-ups to a few commits, so please
check them over.

Thanks.

* The 'master' branch has these since v1.5.4-rc5

Brandon Casey (1):
  git-relink: avoid hard linking in objects/info directory

Bruno Ribas (1):
  gitweb: Make use of the $git_dir variable at sub
    git_get_project_description

Christian Couder (3):
  Documentation: config: add "browser.<tool>.path".
  Documentation: help: specify supported html browsers.
  instaweb: use 'browser.<tool>.path' config option if it's set.

Jakub Narebski (1):
  gitweb: Add info about $projectroot and $projects_list to gitweb/README

Jeff King (1):
  t9001: add missing && operators

Jim Meyering (1):
  fix doc typos

Johannes Schindelin (1):
  Add test for rebase -i with commits that do not pass pre-commit

Junio C Hamano (1):
  reflog-expire: Avoid creating new files in a directory inside readdir(3)
    loop

Yasushi SHOJI (1):
  gitweb: Convert generated contents to utf8 in commitdiff_plain

Re: What's in git.git (stable frozen)

[Junio C Hamano]

Christian Stimming <stimming@tuhh.de> writes:

> Am Montag, 7. Januar 2008 22:58 schrieb Paul Mackerras:
>> I'd like you to do a pull from the gitk.git master branch, but it
>> looks to me like there will be a conflict on the Makefile.
>> Unfortunately the Makefile that Christian Stimming gave me along with
>> the i18n changes is quite different from the one you currently have in
>> the gitk-git subdirectory.  I'm not quite sure what to suggest since
>> it isn't clear to me exactly what Christian's Makefile (which doesn't
>> actually work) is trying to do.  
>
> The Makefile from me was merely a placeholder where the i18n programs should 
> work, but it was clear that the installation rules need to be defined 
> differently anyway.
>
>> I guess the best thing would be to 
>> copy your Makefile over and then add the i18n stuff.
>
> Yes. I've just sent you a patch that does exactly this - that was what I 
> thought, too.

Thanks both of you.

>> Apart from the i18n changes, there is one more commit (b039f0a6) that
>> improves the appearance slightly when running under Tk8.5.
>
> Are you going to release a i18n-enabled gitk sometime soon? If yes, you should 
> consider notifying the translator(s) a few days in advance so that they can 
> finalize their translations, in case they want to avoid a half-translated 
> program to be shipped. Thanks a lot.

If I understand correctly, what Paul told me to pull contains
the i18n stuff, so assuming your adjustment to gitk Makefile
makes things cleanly merge and build inside git.git repository,
upcoming 1.5.4-rc3 will ship with the infrastructure and
existing translations, and updates to po/ files can be made
between -rc3 and the final (I do not mean there won't be -rc4.
That is also "between -rc3 and final").

Re: What's in git.git (stable frozen)

[Christian Stimming]

Am Montag, 7. Januar 2008 22:58 schrieb Paul Mackerras:
> I'd like you to do a pull from the gitk.git master branch, but it
> looks to me like there will be a conflict on the Makefile.
> Unfortunately the Makefile that Christian Stimming gave me along with
> the i18n changes is quite different from the one you currently have in
> the gitk-git subdirectory.  I'm not quite sure what to suggest since
> it isn't clear to me exactly what Christian's Makefile (which doesn't
> actually work) is trying to do.  

The Makefile from me was merely a placeholder where the i18n programs should 
work, but it was clear that the installation rules need to be defined 
differently anyway.

> I guess the best thing would be to 
> copy your Makefile over and then add the i18n stuff.

Yes. I've just sent you a patch that does exactly this - that was what I 
thought, too.

> Apart from the i18n changes, there is one more commit (b039f0a6) that
> improves the appearance slightly when running under Tk8.5.

Are you going to release a i18n-enabled gitk sometime soon? If yes, you should 
consider notifying the translator(s) a few days in advance so that they can 
finalize their translations, in case they want to avoid a half-translated 
program to be shipped. Thanks a lot.

Christian

Re: What's in git.git (stable frozen)

[Paul Mackerras]

Junio C Hamano writes:

> Subsystem people (except Shawn, whose git-gui 0.9.1 is already
> in) are requested to tell me to pull from them, if they have
> accumulated changes that should be in the final release.  I am
> hoping that I can tag -rc3 in a few days (say by the end of my
> Wednesday).

I'd like you to do a pull from the gitk.git master branch, but it
looks to me like there will be a conflict on the Makefile.
Unfortunately the Makefile that Christian Stimming gave me along with
the i18n changes is quite different from the one you currently have in
the gitk-git subdirectory.  I'm not quite sure what to suggest since
it isn't clear to me exactly what Christian's Makefile (which doesn't
actually work) is trying to do.  I guess the best thing would be to
copy your Makefile over and then add the i18n stuff.

Apart from the i18n changes, there is one more commit (b039f0a6) that
improves the appearance slightly when running under Tk8.5.

Paul.

Re: What's in git.git (stable frozen)

[Junio C Hamano]

I've applied all the leftover bits I mentioned in yesterday's
message and 'master' tonight is pretty much where I want it to
be in 1.5.4-rc3 (and in 1.5.4 final).

Subsystem people (except Shawn, whose git-gui 0.9.1 is already
in) are requested to tell me to pull from them, if they have
accumulated changes that should be in the final release.  I am
hoping that I can tag -rc3 in a few days (say by the end of my
Wednesday).

Re: What's in git.git (stable frozen)

[Jeff King]

On Sun, Jan 06, 2008 at 01:22:57PM -0800, Junio C Hamano wrote:

> Yes, to a certain extent with Perl (I think if you make the same
> typo twice you won't get much help, and that is quite easy to
> trigger with variable name autocompletion and cut-and-paste).

Yes, and a static checking language would be a little less error-prone.
But who can live without "eval <STDIN>"? :)

> I suspect "if (!$menu_use_color)" might need to be refined in
> sub "highlight_prefix".  It should be tied with $prompt_color
> somehow (i.e. either it is undef or the "plain" color),
> shouldn't it?

I'm not sure. It avoids printing the brackets in "[p]atch". If you say
"use color, but make the color plain" does that mean you want brackets
or not (right now it will not show brackets)?

> But other than that the result looks quite nice.  I shuffled the
> patches around and the resulting series consists of three patches:

Great. That is the order I would have chosen as well (and hopefully I
gave you enough material in the commit messages to cut and paste
something sensible).

-Peff

Re: What's in git.git (stable frozen)

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> Yes, I considered making a %palette, as well, but it just seemed a
> little gratuitous (and the nice thing about using variables is that they
> catch typos better).

Yes, to a certain extent with Perl (I think if you make the same
typo twice you won't get much help, and that is quite easy to
trigger with variable name autocompletion and cut-and-paste).

I suspect "if (!$menu_use_color)" might need to be refined in
sub "highlight_prefix".  It should be tied with $prompt_color
somehow (i.e. either it is undef or the "plain" color),
shouldn't it?

But other than that the result looks quite nice.  I shuffled the
patches around and the resulting series consists of three patches:

 - "remove unused diff colors";

 - "color.diff" colors diff, "color.interactive" colors
   interaction (squashed the original with change to the "sub
   colored" to use palette setting instead of $use_color as the
   cue);

 - documentation update to redefine the color.interactive
   semantics;

Re: What's in git.git (stable frozen)

[Jeff King]

On Sun, Jan 06, 2008 at 04:32:15AM -0800, Junio C Hamano wrote:

> Yeah, I like that much better, especially the renaming of
> $use_color to more descriptive (but is it really about "menu", I
> wonder?).

I thought that, too, but I didn't know what better word to use
(something like "display" doesn't make it clear that it doesn't involve
the diff).

> I might consider rewriting this part
> 
> > +my $menu_use_color = $repo->get_colorbool('color.interactive');
> > +my ($prompt_color, $header_color, $help_color) =
> > +	$menu_use_color ? (
> > +		$repo->get_color('color.interactive.prompt', 'bold blue'),
> > +		$repo->get_color('color.interactive.header', 'bold'),
> > +		$repo->get_color('color.interactive.help', 'red bold'),
> > +	) : ();
> 
> like this:
> 
> 	my ($prompt_color, $header_color, $help_color, $fraginfo_color);
>         if ($colored_prompt) {
>         	$prompt_color = ...;
>                 $header_color = ...;
>         }
> 	if ($colored_diff) {
>         	$fraginfo_color = ...;
> 	}

Actually, that's more or less how it's written before my patch (in fact,
you could eliminate that part of my patch and just move $normal_color
outside of the conditional). However I didn't like having the
declaration and the assignment so far apart (and duplicated). But I will
admit my version is a little nested. Please feel free to switch it when
you apply.

> or even like this:
> 
> 	my (%palette);
>         if ($colored_prompt) {
> 		my %default = (
>                 	prompt => 'bold blue',
>                         header => 'bold',
>                         ...
> 		);
>                 while (my ($k,$v) = each %default) {
>                     $palette{$k} = $repo->get_color("color.interactive.$k",$v);
> 		}
> 	}
> 
> But I realize that's going overboard.  Certainly the last one is
> doing unnecessary generalization for generalization's sake.

Yes, I considered making a %palette, as well, but it just seemed a
little gratuitous (and the nice thing about using variables is that they
catch typos better).

-Peff

Re: What's in git.git (stable frozen)

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> Something like this (instead of my last patch):

Yeah, I like that much better, especially the renaming of
$use_color to more descriptive (but is it really about "menu", I
wonder?).

I might consider rewriting this part

> +my $menu_use_color = $repo->get_colorbool('color.interactive');
> +my ($prompt_color, $header_color, $help_color) =
> +	$menu_use_color ? (
> +		$repo->get_color('color.interactive.prompt', 'bold blue'),
> +		$repo->get_color('color.interactive.header', 'bold'),
> +		$repo->get_color('color.interactive.help', 'red bold'),
> +	) : ();

like this:

	my ($prompt_color, $header_color, $help_color, $fraginfo_color);
        if ($colored_prompt) {
        	$prompt_color = ...;
                $header_color = ...;
        }
	if ($colored_diff) {
        	$fraginfo_color = ...;
	}

or even like this:

	my (%palette);
        if ($colored_prompt) {
		my %default = (
                	prompt => 'bold blue',
                        header => 'bold',
                        ...
		);
                while (my ($k,$v) = each %default) {
                    $palette{$k} = $repo->get_color("color.interactive.$k",$v);
		}
	}

But I realize that's going overboard.  Certainly the last one is
doing unnecessary generalization for generalization's sake.

Re: What's in git.git (stable frozen)

[Jeff King]

On Sun, Jan 06, 2008 at 02:51:24AM -0800, Junio C Hamano wrote:

> It may make more sense to:
> 
>  * unset $prompt_color and friends when color.interactive says
>    "not to color the menus";
> 
>  * unset $fraginfo_color and diff related ones when color.diff
>    says "diff is monochrome";
> 
> upfront, and then change "sub colored" to just check if $color
> is unset, instead of checking $use_color.

Something like this (instead of my last patch):

-- >8 --
add--interactive: fix "colored" function semantics

Since color.interactive is just for the menus, the "colored"
function can't use it to determine whether to show colors
(this was visible as a bug in which the headers of split
hunks were not colored if color.diff was set but
color.interactive was not).

The new semantics are:

  - colors which are unused are set to undef; the "colored"
    function knows not to do anything with them

  - menu colors are set only when color.interactive is true

  - diff colors are set only when color.diff is true

Signed-off-by: Jeff King <peff@peff.net>
---
 git-add--interactive.perl |   39 +++++++++++++++------------------------
 1 files changed, 15 insertions(+), 24 deletions(-)

diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index 5bdcca8..17ca5b8 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -3,38 +3,29 @@
 use strict;
 use Git;
 
-# Prompt colors:
-my ($prompt_color, $header_color, $help_color, $normal_color);
-# Diff colors:
-my ($fraginfo_color);
-
-my ($use_color, $diff_use_color);
 my $repo = Git->repository();
 
-$use_color = $repo->get_colorbool('color.interactive');
-
-if ($use_color) {
-	# Set interactive colors:
+my $menu_use_color = $repo->get_colorbool('color.interactive');
+my ($prompt_color, $header_color, $help_color) =
+	$menu_use_color ? (
+		$repo->get_color('color.interactive.prompt', 'bold blue'),
+		$repo->get_color('color.interactive.header', 'bold'),
+		$repo->get_color('color.interactive.help', 'red bold'),
+	) : ();
 
-	# Grab the 3 main colors in git color string format, with sane
-	# (visible) defaults:
-	$prompt_color = $repo->get_color("color.interactive.prompt", "bold blue");
-	$header_color = $repo->get_color("color.interactive.header", "bold");
-	$help_color = $repo->get_color("color.interactive.help", "red bold");
-	$normal_color = $repo->get_color("", "reset");
-}
+my $diff_use_color = $repo->get_colorbool('color.diff');
+my ($fraginfo_color) =
+	$diff_use_color ? (
+		$repo->get_color('color.diff.frag', 'cyan'),
+	) : ();
 
-# Do we also set diff colors?
-$diff_use_color = $repo->get_colorbool('color.diff');
-if ($diff_use_color) {
-	$fraginfo_color = $repo->get_color("color.diff.frag", "cyan");
-}
+my $normal_color = $repo->get_color("", "reset");
 
 sub colored {
 	my $color = shift;
 	my $string = join("", @_);
 
-	if ($use_color) {
+	if (defined $color) {
 		# Put a color code at the beginning of each line, a reset at the end
 		# color after newlines that are not at the end of the string
 		$string =~ s/(\n+)(.)/$1$color$2/g;
@@ -300,7 +291,7 @@ sub highlight_prefix {
 		return "$prefix$remainder";
 	}
 
-	if (!$use_color) {
+	if (!$menu_use_color) {
 		return "[$prefix]$remainder";
 	}
 
-- 
1.5.4.rc2.1148.gf9fe3-dirty

Re: What's in git.git (stable frozen)

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> This is a little uglier than it could be because the "colored" function
> does two things: correctly colorize a string, and check the global
> $use_color.

That fallout is a logical consequence of the semantics change of
color.interactive, which used to color the whole user experience
but now only covers about menus and stuff.  $use_color is still
tied to the former semantics.

It may make more sense to:

 * unset $prompt_color and friends when color.interactive says
   "not to color the menus";

 * unset $fraginfo_color and diff related ones when color.diff
   says "diff is monochrome";

upfront, and then change "sub colored" to just check if $color
is unset, instead of checking $use_color.

Re: What's in git.git (stable frozen)

[Junio C Hamano]

"Dan McGee" <dpmcgee@gmail.com> writes:

>> Ah, I spoke too fast.  I think I need to first do a clean-up
>> patch to fix "gitlink::foobar[1]" that should have been spelled
>> as "gitlink:foobar[1]" in a few places, and your change is good.
>
> It looks like I still blew it and forgot the changes in asciidoc.conf
> in the second patch, sorry about that. Let me know if you need
> anything more,...

I think I got all of what you wanted to do now, although my tree
still is not in a shape I can push it out yet (I have to whip
other parts that does not have anything to do with this
documentation fix into shape first).

Thanks.

Re: What's in git.git (stable frozen)

[Jeff King]

On Sat, Jan 05, 2008 at 11:24:09PM -0500, Jeff King wrote:

> >  * Jeff's git-add--interactive change to always honor color.diff
> >    regardless of color.interactive.
> > 
> >    I'd probably apply this, along with the patch to redefine
> >    what color.interactive means.  "git am -i" could also learn
> >    to use colors in the future.
> 
> Here is the palette cleanup patch, on top of my others (it should still

And while tracking down the $fraginfo usage, I noticed that my original
patches introduce a bug. Fix is below (it is on top of palette cleanup).

I can also resubmit these in a more sensible order (palette cleanup,
then the other three squashed together) if you prefer.

-- >8 --
add--interactive: colorize split hunk fragment headers

The only diff element which we still color in perl is the
"fraginfo" for the split hunks. When honoring color.diff
without color.interactive, we were failing to actually color
this because the "colored" function checks for interactive
color. Instead, let's just color it by hand (the simple
approach is OK because we know we have a single line
string).

Signed-off-by: Jeff King <peff@peff.net>
---
This is a little uglier than it could be because the "colored" function
does two things: correctly colorize a string, and check the global
$use_color. We could do something like:

  local $use_color = 1;
  $display_head = colored($fraginfo_color, $head);

which is arguably less ugly. Or we could refactor "colored", which is a
larger change.

 git-add--interactive.perl |    5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index 5bdcca8..76dc4e6 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -21,8 +21,8 @@ if ($use_color) {
 	$prompt_color = $repo->get_color("color.interactive.prompt", "bold blue");
 	$header_color = $repo->get_color("color.interactive.header", "bold");
 	$help_color = $repo->get_color("color.interactive.help", "red bold");
-	$normal_color = $repo->get_color("", "reset");
 }
+$normal_color = $repo->get_color("", "reset");
 
 # Do we also set diff colors?
 $diff_use_color = $repo->get_colorbool('color.diff');
@@ -648,7 +648,8 @@ sub split_hunk {
 		my $display_head = $head;
 		unshift @{$hunk->{TEXT}}, $head;
 		if ($diff_use_color) {
-			$display_head = colored($fraginfo_color, $head);
+			$display_head = join('', $fraginfo_color, $head,
+				$normal_color, "\n");
 		}
 		unshift @{$hunk->{DISPLAY}}, $display_head;
 	}
-- 
1.5.4.rc2.1147.gaecdf-dirty

Re: What's in git.git (stable frozen)

[Jeff King]

On Sat, Jan 05, 2008 at 02:46:07AM -0800, Junio C Hamano wrote:

>  * Jeff's git-add--interactive change to always honor color.diff
>    regardless of color.interactive.
> 
>    I'd probably apply this, along with the patch to redefine
>    what color.interactive means.  "git am -i" could also learn
>    to use colors in the future.
> 
>    Incidentally I noticed that many of the color.diff.* palette
>    options are read by "git-add -i" but never used by the
>    script.  We might want to fix this while we are at it.

Here is the palette cleanup patch, on top of my others (it should still
be done even if the other patches aren't taken, but backporting it
should be fairly obvious).

-- >8 --
add--interactive: remove unused diff colors

When color support was added, we colored the diffs
ourselves. However, 4af756f3 changed this to simply run
"git diff-files" twice, keeping the colored output
separately.

This makes the internal diff color variables obsolete with
one exception: when splitting hunks, we have to manually
recreate the fragment for each part of the split. Thus we
keep $fraginfo_color around to do that correctly.

Signed-off-by: Jeff King <peff@peff.net>
---
 git-add--interactive.perl |    6 +-----
 1 files changed, 1 insertions(+), 5 deletions(-)

diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index aaa9b24..5bdcca8 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -6,7 +6,7 @@ use Git;
 # Prompt colors:
 my ($prompt_color, $header_color, $help_color, $normal_color);
 # Diff colors:
-my ($new_color, $old_color, $fraginfo_color, $metainfo_color, $whitespace_color);
+my ($fraginfo_color);
 
 my ($use_color, $diff_use_color);
 my $repo = Git->repository();
@@ -27,11 +27,7 @@ if ($use_color) {
 # Do we also set diff colors?
 $diff_use_color = $repo->get_colorbool('color.diff');
 if ($diff_use_color) {
-	$new_color = $repo->get_color("color.diff.new", "green");
-	$old_color = $repo->get_color("color.diff.old", "red");
 	$fraginfo_color = $repo->get_color("color.diff.frag", "cyan");
-	$metainfo_color = $repo->get_color("color.diff.meta", "bold");
-	$whitespace_color = $repo->get_color("color.diff.whitespace", "normal red");
 }
 
 sub colored {
-- 
1.5.4.rc2.1147.gaecdf-dirty

Re: What's in git.git (stable frozen)

[Dan McGee]

On Jan 5, 2008 9:06 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
> >> I've updated the patch a bit as I noticed I completely missed the
> >> user-manual.txt and a handful of other files that weren't named
> >> git-*.txt. The new version is attached (gzipped).
> >
> > The asciidoc.conf change I resurrected from the earlier one but
> > it appears this breaks build with asciidoc 7.1.2 for some reason
> > (I haven't looked into that myself yet, and I won't be for the
> > next 12 hours or so).
>
> Ah, I spoke too fast.  I think I need to first do a clean-up
> patch to fix "gitlink::foobar[1]" that should have been spelled
> as "gitlink:foobar[1]" in a few places, and your change is good.

It looks like I still blew it and forgot the changes in asciidoc.conf
in the second patch, sorry about that. Let me know if you need
anything more, although this patch is pretty straightforward (once I
spent 3 hours trying to figure out why it was broken in the first
place and attempting to find a more sane way around it).

-Dan

Re: What's in git.git (stable frozen)

[Junio C Hamano]

Junio C Hamano <gitster@pobox.com> writes:

>> I've updated the patch a bit as I noticed I completely missed the
>> user-manual.txt and a handful of other files that weren't named
>> git-*.txt. The new version is attached (gzipped).
>
> The asciidoc.conf change I resurrected from the earlier one but
> it appears this breaks build with asciidoc 7.1.2 for some reason
> (I haven't looked into that myself yet, and I won't be for the
> next 12 hours or so).

Ah, I spoke too fast.  I think I need to first do a clean-up
patch to fix "gitlink::foobar[1]" that should have been spelled
as "gitlink:foobar[1]" in a few places, and your change is good.

Re: What's in git.git (stable frozen)

[Junio C Hamano]

"Dan McGee" <dpmcgee@gmail.com> writes:

> On Jan 5, 2008 4:46 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> We are not at -rc3 yet, but we will be soon.  What we have
>> accumulated in 'master' are mostly fixes, and the official
>> git-gui 0.9.1 is also included tonight.
>>  * Dan McGee's workaround to breakage caused by changes in
>>    AsciiDoc 8.2.3.
>>
>>    I have to do my usual "before-and-after comparison" with
>>    copies of AsciiDoc versions that should not be affected by
>>    the breakage, which I did not have time to do so far.  But
>>    this is probably a must-have before the release.
>
> I've updated the patch a bit as I noticed I completely missed the
> user-manual.txt and a handful of other files that weren't named
> git-*.txt. The new version is attached (gzipped).

The asciidoc.conf change I resurrected from the earlier one but
it appears this breaks build with asciidoc 7.1.2 for some reason
(I haven't looked into that myself yet, and I won't be for the
next 12 hours or so).

Re: What's in git.git (stable frozen)

[Junio C Hamano]

"Marco Costalba" <mcostalba@gmail.com> writes:

> I understand the patch series is too intrusive now, but if you want I
> can send a simplified one that just fixes the off by one bug for now.

How about the one that fixes first and see how bad the remainder
looks again?  I recall that Réne were not entirely unhappy with
his last round.  And I do not think that change does not have to
be "a series" but can be a single change.  At least it did not
look so complicated, but I may be misremembering it.

Re: What's in git.git (stable frozen)

[Dan McGee]

[-- Attachment #1: Type: text/plain, Size: 943 bytes --]

On Jan 5, 2008 4:46 AM, Junio C Hamano <gitster@pobox.com> wrote:
> We are not at -rc3 yet, but we will be soon.  What we have
> accumulated in 'master' are mostly fixes, and the official
> git-gui 0.9.1 is also included tonight.
>  * Dan McGee's workaround to breakage caused by changes in
>    AsciiDoc 8.2.3.
>
>    I have to do my usual "before-and-after comparison" with
>    copies of AsciiDoc versions that should not be affected by
>    the breakage, which I did not have time to do so far.  But
>    this is probably a must-have before the release.

I've updated the patch a bit as I noticed I completely missed the
user-manual.txt and a handful of other files that weren't named
git-*.txt. The new version is attached (gzipped). I also included
instructions on how to regenerate it in the commit message, which may
be a wise idea to ensure no Documentation changes add a gitlink: call
between now and when you apply the patch.

-Dan

[-- Attachment #2: 0001-Documentation-rename-gitlink-macro-to-linkgit.patch.gz --]
[-- Type: application/x-gzip, Size: 50243 bytes --]

What's in git.git (stable frozen)

[Junio C Hamano]

We are not at -rc3 yet, but we will be soon.  What we have
accumulated in 'master' are mostly fixes, and the official
git-gui 0.9.1 is also included tonight.

I have to apologize that tonight I got a bit carried away
enjoying arguing for the sake of arguing.  Some patches that
might be worthy even though they are late in the cycle are not
in tonight's 'master', mostly because I have to sleep on them,
and partly because I am running out of time tonight.

 * Tsugikazu Shibata's git-diff hunk header change.

   I have a counterproposal that I think is more in line with
   the other parts of the system.  As the kernel project has
   ja_JP, ko_KR and zh_CN directories under Documentation these
   days, the issue this patch addresses is already real, and we
   would want to have a solution in 1.5.4, even though the topic
   was raised too late in the cycle.  I think my first two
   patches could be a good starting point for that.  I'd exclude
   the last patch in the series that acts on gitattributes for
   now.

 * Marco's git-stash changes to output to stdout.

   I'd probably apply this, with a slightly toned down commit
   log message.  Marco says some practice is standard, I
   disagreed, but that is not a reason to say "this practice is
   nonstandard and bad".  Simply saying "some do this and it is
   better to be helpful to them because there is no strong
   reason not to" would be good enough.

 * Jeff's git-add--interactive change to always honor color.diff
   regardless of color.interactive.

   I'd probably apply this, along with the patch to redefine
   what color.interactive means.  "git am -i" could also learn
   to use colors in the future.

   Incidentally I noticed that many of the color.diff.* palette
   options are read by "git-add -i" but never used by the
   script.  We might want to fix this while we are at it.

 * Dan McGee's workaround to breakage caused by changes in
   AsciiDoc 8.2.3.

   I have to do my usual "before-and-after comparison" with
   copies of AsciiDoc versions that should not be affected by
   the breakage, which I did not have time to do so far.  But
   this is probably a must-have before the release.

 * My patch to error out "git stash clear foobar".

   This should be applied; it is a good safety measure
   regardless of where that "git stash drop" thing would go.

An issue worth addressing before the release is still in limbo.

 * Dmitry's git-filter-branch fix to disambiguate the refs being
   rewritten.

   Addition of "git-rev-parse --symbolic-full" may solve this
   more cleanly than the patches in the discussion, but we
   haven't reached the conclusion of this thread yet.

Anything I missed?

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

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

Alex Riesen (1):
  Allow selection of different cleanup modes for commit messages

Arjen Laarhoven (1):
  Fix "git log --diff-filter" bug

Bernt Hansen (1):
  git-gui: Make commit log messages end with a newline

Eric Wong (2):
  git-svn: allow dcommit --no-rebase to commit multiple, dependent changes
  git-svn: unlink index files that were globbed, too

Grégoire Barbier (1):
  Fix double-free() in http-push.c:remote_exists()

Gustaf Hendeby (2):
  shortlog manpage documentation: work around asciidoc markup issues
  Documentation/user-manual.txt: fix typo

J. Bruce Fields (1):
  Documentation: fix remote.<name>.skipDefaultUpdate description

Jeff King (6):
  cvsimport: die on cvsps errors
  config: handle lack of newline at end of file better
  git-reset: refuse to do hard reset in a bare repository
  add a "basic" diff config callback
  diff: load funcname patterns in "basic" config
  diff: remove lazy config loading

Jim Meyering (2):
  Fix grammar nits in documentation and in code comments.
  Don't access line[-1] for a zero-length "line" from fgets.

Johannes Schindelin (1):
  Optimize prefixcmp()

Johannes Sixt (1):
  git-gui: Move frequently used commands to the top of the context menu.

Junio C Hamano (20):
  t7005: do not exit inside test.
  builtin-commit: fix amending of the initial commit
  builtin-commit: avoid double-negation in the code.
  Fix documentation of --first-parent in git-log and copy it to
    git-rev-list
  combine-diff: Fix path quoting
  Fix rewrite_diff() name quoting.
  contrib: resurrect scripted git-revert.
  GIT 1.5.4-rc2
  Documentation/git-submodule.txt: typofix
  "git pull --tags": error out with a better message.
  git-rebase -i behaves better on commits with incomplete messages
  git-rebase -i: clean-up error check codepath.
  lock_any_ref_for_update(): reject wildcard return from check_ref_format
  Update callers of check_ref_format()
  Uninline prefixcmp()
  git-clean: make "Would remove ..." path relative to cwd again
  t/t7600: avoid GNUism in grep
  t/t{3600,3800,5401}: do not use egrep when grep would do
  t/t3800: do not use a temporary file to hold expected result.
  Update draft release notes for 1.5.4

Marco Costalba (1):
  Document git-reset defaults to HEAD if no commit is given

Mark Levedahl (1):
  git-gui: Unconditionally use absolute paths with Cygwin

Martin Koegler (2):
  receive-pack: check object type of sha1 before using them as commits
  receive-pack: reject invalid refnames

Michael Stefaniuc (1):
  git-am: Run git gc only once and not for every patch.

Miklos Vajna (2):
  git-sh-setup: document git_editor() and get_author_ident_from_commit()
  t/t7001: avoid unnecessary ERE when using grep

Peter Karlsson (1):
  Added Swedish translation.

René Scharfe (1):
  Make "--pretty=format" parser a bit more careful.

Shawn O. Pearce (2):
  git-gui: Handle file mode changes (644->755) in diff viewer
  Improve error messages when int/long cannot be parsed from config

What's in git.git (stable frozen)

[Junio C Hamano]

Stabilization cycle towards -rc2 continues.

The main point of -rc cycle is regression fixes and general
bugfixes, although a few new features managed to slip in.

 - diff.external configuration variable serves the same purpose
   as GIT_EXTERNAL_DIFF environment;

 - "git diff --src-prefix=l/ --dst-prefix=k/" can be used to
   change the usual prefix (i.e. a/foo vs. b/foo).

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

* The 'maint' branch has these fixes since the last announcement.

Jeff King (2):
  clone: correctly report http_fetch errors
  git-send-email: avoid duplicate message-ids


* The 'master' branch has these since the last announcement
  in addition to the above.

Charles Bailey (2):
  Fix git-instaweb breakage on MacOS X due to the limited sed functionality
  Remove old generated files from .gitignore.

Eric Wong (3):
  git-svn: avoid leaving leftover committer/author info in rebase
  git-svn: workaround a for broken symlinks in SVN
  git-svn: avoid warning when run without arguments

Finn Arne Gangstad (1):
  Improved submodule merge support

Gustaf Hendeby (1):
  Make git send-email accept $EDITOR with arguments

H.Merijn Brand (1):
  the use of 'tr' in the test suite isn't really portable

Jakub Narebski (1):
  gitweb: fix whitespace in config_to_multi (indent with tab)

Jeff King (2):
  test "git clone -o"
  clean up 1.5.4 release notes

Jim Meyering (2):
  git-filter-branch.sh: more portable tr usage: use \012, not \n.
  Don't dereference NULL upon lookup failure.

Johannes Schindelin (6):
  Support config variable diff.external
  Document diff.external and mergetool.<tool>.path
  rebase -p -i: handle "no changes" gracefully
  git show <tag>: show the tagger
  Teach diff machinery to display other prefixes than "a/" and "b/"
  Mention git-shell's "cvs" substitution in the RelNotes

Johannes Sixt (3):
  Plug a resource leak in threaded pack-objects code.
  Clean up documentation that references deprecated 'git peek-remote'.
  filter-branch: Remove broken and unnecessary summary of rewritten refs.

Junio C Hamano (8):
  builtin-blame.c: remove unneeded memclr()
  GIT 1.5.4-rc1
  t4024: fix test script to use simpler sed pattern
  fix git commit --amend -m "new message"
  shell-scripts usage(): consistently exit with non-zero
  Documentation: ls-files -v is about "assume unchanged".
  Fix $EDITOR regression introduced by rewrite in C.
  Documentation: describe 'union' low-level merge driver

Linus Torvalds (2):
  unpack-trees: FLEX_ARRAY fix
  Re(-re)*fix trim_common_tail()

Marco Roeland (1):
  clone: fix options '-o' and '--origin' to be recognised again

Miklos Vajna (1):
  everyday: replace 'prune' and 'repack' with 'gc'

Nicolas Pitre (2):
  fix style of a few comments in diff-delta.c
  make 'git describe --all --contains' work

Pierre Habouzit (4):
  Fix segfault in diff-delta.c when FLEX_ARRAY is 1
  git-tag: fix -l switch handling regression.
  Force the sticked form for options with optional arguments.
  parse-options: Add a gitcli(5) man page.

Ralf Wildenhues (1):
  Fix some documentation typos.

Sam Vilain (1):
  Clarify error response from 'git fetch' for bad responses

Sean Estabrooks (1):
  Fix interactive rebase to preserve author email address

Shawn O. Pearce (3):
  Avoid update hook during git-rebase --interactive
  Catch and handle git-commit failures in git-rebase --interactive
  Reallow git-rebase --interactive --continue if commit is unnecessary

Stefan Sperling (1):
  Small comment fix for git-cvsimport.

Wincent Colaiuta (1):
  Emit helpful status for accidental "git stash" save

Re: What's in git.git (stable frozen)

[Steffen Prohaska]

On Dec 13, 2007, at 3:47 AM, Junio C Hamano wrote:

> The tip of 'master' is now tagged as 1.5.4-rc0.  Tarballs are found in
> the usual places:

A fresh msysgit self-contained Windows setup is available from

http://msysgit.googlecode.com/files/Git-1.5.4-rc0-preview20071217.exe

	Steffen

What's in git.git (stable frozen)

[Junio C Hamano]

Sorry for the "\No newline at the end" brown paper bag bug, which
happened soon after -rc0 but now fixed.  Thanks Jeff.

"git diff --check" was inconsistent with the highlighting of whitespace
problems and was harder to use from scripts (which makes it a usability
bug).  Both have been fixed.  Thanks Wincent.

A handful "gitweb" fixes I forgot to apply earlier are now in.  Thanks
Jakub.

A "git commit" regression has been noticed --- the post-commit summary
was inconsistent with what is shown by git-status before making the
commit.  Thanks Daniel.

A workaround for massive commit that exceeds command line limit when
issuing "cvs status list-of-files" has been added.  Thanks Jeff.

Hopefully the final round of clean-up until 1.5.4 in whitespace area has
been applied.  Thanks Wincent and Bruce.

I am reasonably happy that we are finding and fixing bugs.  Please keep
the fixes, including documentation updates, flowing in.

 * "git -p ls-tree HEAD" in a bare repository is still not fixed.

   http://thread.gmane.org/gmane.comp.version-control.git/68209?focus=68221
   http://thread.gmane.org/gmane.comp.version-control.git/68209?focus=68338

 * Hannes says "thread pack-objects" improvements needs a follow-up
   patch; it hasn't been applied here yet.

 * option parser regression fix really needs to be in by -rc1, but I
   just applied the initial round of Pierre's patches today.  See
   "What's cooking" for the list.

I need to coordinate with subsystem people and pull in changes for
gitk, git-gui, user manual and git-svn.

----------------------------------------------------------------
* The 'master' branch has these since the last announcement
  in addition to the above.

Andy Whitcroft (1):
  git-svn: expand handling of From: and Signed-off-by:

Christian Couder (1):
  git-help: add "help.format" config variable.

David S. Miller (1):
  fast-import: fix unalinged allocation and access

Eric Wong (2):
  git-svn: unlink internal index files after operations
  git-svn: handle our top-level path being deleted and later re-added

J. Bruce Fields (8):
  whitespace: fix off-by-one error in non-space-in-indent checking
  whitespace: reorganize initial-indent check
  whitespace: minor cleanup
  whitespace: fix initial-indent checking
  whitespace: more accurate initial-indent highlighting
  whitespace: fix config.txt description of indent-with-non-tab
  builtin-apply: minor cleanup of whitespace detection
  builtin-apply: stronger indent-with-on-tab fixing

Jakub Narebski (2):
  gitweb: disambiguate heads and tags withs the same name
  gitweb: Teach "a=blob" action to be more lenient about blob/file mime
    type

Jeff King (4):
  cvsexportcommit: fix massive commits
  trim_common_tail: brown paper bag fix.
  teach bash completion to treat commands with "--" as a helper
  rename git-browse--help to git-help--browse

Johannes Sixt (1):
  threaded pack-objects: Use condition variables for thread communication.

Junio C Hamano (15):
  git-commit: squelch needless message during an empty merge
  xdl_diff: identify call sites.
  xdi_diff: trim common trailing lines
  diff --check: minor fixups
  xdiff tail trimming: use correct type.
  commit: allow --amend to reuse message from another commit
  remote: Fix bogus make_branch() call in configuration reader.
  Rename git-browse-help helper to git-browse--help
  Retire git-runstatus for real.
  Start preparing the API documents.
  Update draft release notes for 1.5.4
  Re-re-re-fix common tail optimization
  builtin-commit: fix summary output.
  builtin-commit: make summary output consistent with status
  Documentation/git-submodule: refer to gitmodules(5)

Kristian Høgsberg (1):
  Use a strbuf for building up section header and key/value pair strings.

Li Hong (1):
  Fix a memory leak

Mike Hommey (8):
  Fix some more memory leaks in http-push.c
  Fix random sha1 in error message in http-fetch and http-push
  Remove the default_headers variable from http-push.c
  Remove a CURLOPT_HTTPHEADER (un)setting
  Avoid redundant declaration of missing_target()
  Use strbuf in http code
  Fix various memory leaks in http-push.c and http-walker.c
  Move fetch_ref from http-push.c and http-walker.c to http.c

Nicolas Pitre (1):
  provide advance warning of some future pack default changes

Petr Baudis (1):
  gitweb: Make config_to_multi return [] instead of [undef]

Shawn Bohrer (1):
  Fix spelling mistakes in user manual

Wincent Colaiuta (6):
  "diff --check" should affect exit status
  Unify whitespace checking
  Make "diff --check" output match "git apply"
  Add tests for "git diff --check" with core.whitespace options
  Use shorter error messages for whitespace problems
  Test interaction between diff --check and --exit-code

anonymous (1):
  Documentation: describe pack idx v2

What's in git.git (stable frozen)

[Junio C Hamano]

The tip of 'master' is now tagged as 1.5.4-rc0.  Tarballs are found in
the usual places:

  http://www.kernel.org/pub/software/scm/git/

  git-1.5.4.rc0.tar.{gz,bz2}			(tarball)
  git-htmldocs-1.5.4.rc0.tar.{gz,bz2}		(preformatted docs)
  git-manpages-1.5.4.rc0.tar.{gz,bz2}		(preformatted docs)

I've also built a set of preview RPM packages.  They are found in:

  http://www.kernel.org/pub/software/scm/git/testing/

I am not an RPM person.  It would be really appreciated if experts help
out finding and fixing any bug in the packaging.  I do not want to
repeat the firefighting we needed with 1.5.3.1.

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

Alex Riesen (1):
  Fix git-fast-export for zero-sized blobs

Alexandre Julliard (1):
  git.el: Added a menu for git-status-mode.

Charles Bailey (1):
  Fix clone not to ignore depth when performing a local clone

Christian Couder (5):
  git-help: add -i|--info option to display info page.
  Documentation: describe -i/--info option to "git-help"
  git-help: add -w|--web option to display html man page in a browser.
  Use {web,instaweb,help}.browser config options.
  Documentation: describe -w/--web option to "git-help".

Daniel Barkalow (1):
  Add more checkout tests

Eric Wong (2):
  git-svn: replace .rev_db with a more space-efficient .rev_map format
  git-svn: reinstate old rev_db optimization in new rev_map

Eyvind Bernhardsen (1):
  Fix mis-markup of the -p, --patch option in git-add(1)

Gerrit Pape (1):
  Don't cache DESTDIR in perl/perl.mak.

Jakub Narebski (1):
  autoconf: Check asciidoc version to automatically set ASCIIDOC8

Jeff King (6):
  don't mention index refreshing side effect in git-status docs
  Add git-browse-help to .gitignore
  Support GIT_PAGER_IN_USE environment variable
  git-svn: get color config from --get-colorbool
  shortlog: document -e option
  git-clone: print an error message when trying to clone empty repo

Johannes Sixt (1):
  Fix a typo in checkout.sh and cleanup one-line help messages

Junio C Hamano (18):
  git-shortlog -e: show e-mail address as well
  Re-fix ls-remote
  Update draft Release Notes for 1.5.4
  Documentation: add gitman.info target
  git-help -i: invoke info with document and node name
  git-help -i: show info documentation from matching version of git
  send-email: do not muck with initial-reply-to when unset.
  commit: do not add extra LF at the end of the summary.
  Support a merge with conflicting gitlink change
  blame: drop blob data after passing blame to the parent
  shortlog: default to HEAD when the standard input is a tty
  git-diff --numstat -z: make it machine readable
  disable t9119 for now.
  Documentation: rename git.texi to user-manual.texi
  git.spec.in: remove python_path
  git-help -w: do not require to be in git repository
  RPM spec: Adjust htmldir
  GIT 1.5.4-rc0

Linus Torvalds (1):
  "git tag -u keyname" broken

Mike Hommey (4):
  git-send-email.perl: Really add angle brackets to In-Reply-To if
    necessary
  Cleanup variables in http.[ch]
  Fix small memory leaks induced by diff_tree_setup_paths
  Fix XML parser leaks in http-push

Nguyễn Thái Ngọc Duy (1):
  Remove repo version check from setup_git_directory

Nicolas Pitre (1):
  pack-objects: more threaded load balancing fix with often changed paths

Pierre Habouzit (1):
  Invert numbers and names in the git-shortlog summary mode.

Wincent Colaiuta (5):
  Interactive editor tests for commit-msg hook
  Style fixes for pre-commit hook tests
  Use "whitespace" consistently
  Documentation: minor grammar fix for "git apply"
  Fix "diff --check" whitespace detection