What's in git.git

What's in git.git

[Junio C Hamano]

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

 - git-svn updates (Eric Wong)
 - git-blame knows about renames (Fredrik Kuivinen)
 - imap-send (Mike McCormack with fixes from Johannes Schindelin
   and Marco Roeland)
 - cvsimport only updates tracking branch (Matthias Urlichs)
 - repo-config fix (Jonas Fonseca)
 - fmt-merge-msg cleanup (Linus Torvalds)
 - format-patch attachments enhancements (Mike McCormack)
 - delitifier cleanup and performance fix (Nicolas Pitre)
 - remove end-of-line period from git-pull message (Olaf Hering)
 - http-push and fetch updates (Nick Hengeveld)
 - rev-list and revision walker performance fix (Matthias Urlichs)
 - annotate RPM packaging workaround (sean)
 - assorted doc fixes (Francis Daly, Fredrik Kuivinen)
 - assorted test fixes (Mark Wooding, me)
 - improve git wrapper --help output (Fredrik Kuivinen)
 - checkout-index --temp (Shawn Pearce)
 - no more --standalone to fsck-objects
 - rev-list path limiter fix at boundary
 - git-diff: -p disables rename detection

As you can see from the above, the core part does not have
drastic changes these days anymore.  Just some boring fixes with
a handful new and interesting developments.

In the "next" branch is the "insanely fast rename detection".
I've done some minor fixups to its hash function to be usable on
both 32-bit and 64-bit machines but otherwise it is what was
posted by Linus to the list.  It completes the rename detection
between v2.6.12 and v2.6.14 kernel source under 5 seconds on my
Duron 750 with slow disks, where the current "master" branch
version takes about 60 seconds.

Also I've been keeping ls-{tree,files} --abbrev patches and
refs/remotes patch from Eric Wong in 'next' and 'pu'.  I haven't
seen anybody jumps up and down to have them merged to "master",
nor have been asked to push them out sooner so that a widely
used Porcelain or two can take advantage of them, and that's the
only reason why they are not in "master".  In other words, while
I do not have much against them, it would be nicer to have a
convincing argument why they are must-have's or even
better-have's before they graduate.

[patch] fix imap-send for OSX

[Randal L. Schwartz]

This patch works... I've been using it to stay current.

---

 imap-send.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

ba458b49b860488c25cf57dabbb5db97f12e41f2
diff --git a/imap-send.c b/imap-send.c
index 1b38b3a..e33c78b 100644
--- a/imap-send.c
+++ b/imap-send.c
@@ -372,7 +372,7 @@ free_generic_messages( message_t *msgs )
 }
 
 static int
-vasprintf( char **strp, const char *fmt, va_list ap )
+git_vasprintf( char **strp, const char *fmt, va_list ap )
 {
 	int len;
 	char tmp[1024];
@@ -402,7 +402,7 @@ nfsnprintf( char *buf, int blen, const c
 static int
 nfvasprintf( char **str, const char *fmt, va_list va )
 {
-	int ret = vasprintf( str, fmt, va );
+	int ret = git_vasprintf( str, fmt, va );
 	if (ret < 0)
 		die( "Fatal: Out of memory\n");
 	return ret;
-- 
1.2.4.g5593



-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

Re: [patch] fix imap-send for OSX

[Junio C Hamano]

Thanks.

How much would we care about non GNU libc I wonder.  We could
just lose that private definition, and say 

	#define _GNU_SOURCE
        #include <stdio.h>

instead, in git-compat-util.h.

But let's leave that to later rounds.