The latest maintenance release GIT 1.4.4.3 is available at the
usual places:
http://www.kernel.org/pub/software/scm/git/
git-1.4.4.3.tar.{gz,bz2} (tarball)
git-htmldocs-1.4.4.3.tar.{gz,bz2} (preformatted docs)
git-manpages-1.4.4.3.tar.{gz,bz2} (preformatted docs)
RPMS/$arch/git-*-1.4.4.3-1.$arch.rpm (RPM)
This release contains merge-recursive corner case fix; it also
fixes git-cvsserver (when used with newer Perl) and Mac OS build
(when you use config.mak), among other things.
To let people who only follow the 'maint' releases know what's
happening in the larger picture...
We have just started talking about the next feature release
v1.5.0 on the 'master' branch side. If we are lucky we could do
a -rc1 around Christmas, emperor's birthday in Japan, or perhaps
emperor's birthday in the Penguin land, but in any case the real
release is not expected to happen by mid January.
The new release will have many end-user level changes since the
last feature release v1.4.4, both at the UI level and at the
documentation level, based on previous discussions on the list.
It is strongly encouraged and very much appreciated to review
and to fill gaps you would find in today's 'master' and what's
cooking in 'next', if you were involved in the discussions
and/or if you are interested in the theme of v1.5.0: "usability
and teachability".
Thanks.
-jc.
----------------------------------------------------------------
* The 'maint' branch is at v1.4.4.3 and has these fixes since
v1.4.4.2:
Alex Riesen (1):
Clarify fetch error for missing objects.
Brian Gernhardt (1):
Move Fink and Ports check to after config file
Chris Wright (1):
no need to install manpages as executable
Eric Wong (2):
git-svn: exit with status 1 for test failures
git-svn: correctly display fatal() error messages
Jim Meyering (1):
Don't use memcpy when source and dest. buffers may overlap
Junio C Hamano (1):
GIT 1.4.4.3
Martin Langhoff (1):
cvsserver: Avoid miscounting bytes in Perl v5.8.x
Shawn Pearce (2):
Make sure the empty tree exists when needed in merge-recursive.
Bypass expensive content comparsion during rename detection.
* The 'master' branch has these since the last announcement.
They are NOT in 1.4.4.3.
Aneesh Kumar K.V (1):
Add config example with respect to branch
Brian Gernhardt (2):
Add documentation for show-branch --topics
Remove COLLISION_CHECK from Makefile since it's not used.
Eric Wong (1):
git-cvsserver: fix breakage when calling git merge-file
Jeff King (1):
vim syntax: follow recent changes to commit template
Junio C Hamano (8):
parse-remote::expand_refs_wildcard()
show-ref: fix --exclude-existing
racy-git: documentation updates.
rerere: fix breakage of resolving.
fix populate-filespec
config_rename_section: fix FILE* leak
simplify inclusion of system header files.
GIT 1.4.4.3
Nicolas Pitre (4):
make patch_delta() error cases a bit more verbose
make git a bit less cryptic on fetch errors
index-pack usage of mmap() is unacceptably slower on many OSes
other than Linux
clarify some error messages wrt unknown object types
Robert Fitzsimons (1):
gitweb: Show '...' links in "summary" view only if there are more items
On Wed, 20 Dec 2006, Randal L. Schwartz wrote:
>
> Is this really in master? I'm still seeing one-hour times on
> my Mac, using 8336afa563fbeff35e531396273065161181f04c.
Master right now is at 54851157ac.
But I use the master site of kernel.org, and the public site mirrors
probably haven't mirrored out yet.
Sometimes it can be worth it trying "git2.kernel.org" rather than
"git.kernel.org", because the way the DNS round-robin works (badly), git1
seems to get a lot more load than git2, so sometimes git2 gets updated
before git1 does.
Linus
On Wed, 20 Dec 2006, Randal L. Schwartz wrote:
> >>>>> "Junio" == Junio C Hamano <[email protected]> writes:
>
> Junio> * The 'master' branch has these since the last announcement.
> Junio> They are NOT in 1.4.4.3.
>
> Junio> index-pack usage of mmap() is unacceptably slower on many OSes
> Junio> other than Linux
>
> Is this really in master? I'm still seeing one-hour times on
> my Mac, using 8336afa563fbeff35e531396273065161181f04c.
It is in current master, but not in 8336afa563fbeff35e5313...
To be sure you have it just open index-pack.c and make sure "mmap" is
not found there anymore.
Nicolas
>>>>> "Linus" == Linus Torvalds <[email protected]> writes:
>> Is this really in master? I'm still seeing one-hour times on
>> my Mac, using 8336afa563fbeff35e531396273065161181f04c.
Linus> Master right now is at 54851157ac.
Yeah, 54 objects just pulled down. Here we go. Time for a test...
Nope... can't compile:
gcc -o daemon.o -c -g -O2 -Wall -I/sw/include -I/opt/local/include -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY daemon.c
daemon.c: In function 'parse_extra_args':
daemon.c:414: warning: implicit declaration of function 'strncasecmp'
daemon.c: In function 'socksetup':
daemon.c:766: error: 'NI_MAXSERV' undeclared (first use in this function)
daemon.c:766: error: (Each undeclared identifier is reported only once
daemon.c:766: error: for each function it appears in.)
daemon.c:766: warning: unused variable 'pbuf'
daemon.c: In function 'serve':
daemon.c:970: warning: implicit declaration of function 'initgroups'
make: *** [daemon.o] Error 1
This smells like we've seen this before. Regression introduced with
some of the cleanup?
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[email protected]> <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!
>>>>> "Junio" == Junio C Hamano <[email protected]> writes:
Junio> * The 'master' branch has these since the last announcement.
Junio> They are NOT in 1.4.4.3.
Junio> index-pack usage of mmap() is unacceptably slower on many OSes
Junio> other than Linux
Is this really in master? I'm still seeing one-hour times on
my Mac, using 8336afa563fbeff35e531396273065161181f04c.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[email protected]> <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!
[email protected] (Randal L. Schwartz) writes:
> Nope... can't compile:
> ...
> daemon.c:970: warning: implicit declaration of function 'initgroups'
> make: *** [daemon.o] Error 1
>
> This smells like we've seen this before. Regression introduced with
> some of the cleanup?
Most likely. You were CC'ed on these messages:
<[email protected]>
<[email protected]>
>>>>> "Junio" == Junio C Hamano <[email protected]> writes:
Junio> [email protected] (Randal L. Schwartz) writes:
>> Nope... can't compile:
>> ...
>> daemon.c:970: warning: implicit declaration of function 'initgroups'
>> make: *** [daemon.o] Error 1
>>
>> This smells like we've seen this before. Regression introduced with
>> some of the cleanup?
Junio> Most likely. You were CC'ed on these messages:
Junio> <[email protected]>
Junio> <[email protected]>
I see in 979e32fa1483a32faa4ec331e29b357e5eb5ef25 that I had to change
some things for OpenBSD... I bet those are generic BSD things.
Lemme see if it breaks on OpenBSD as well.
Oddly enough - it didn't. :)
running "git version 1.4.4.3.g5485" on my openbsd box, but I can't get
there on my OSX box.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[email protected]> <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!
[email protected] (Randal L. Schwartz) writes:
> Lemme see if it breaks on OpenBSD as well.
>
> Oddly enough - it didn't. :)
Of course it didn't. I was a bit more careful than usual with
this and fired up an OpenBSD bochs on my wife's machine to test
it before pushing out.
> running "git version 1.4.4.3.g5485" on my openbsd box, but I can't get
> there on my OSX box.
Sorry, I cannot be of immediate help -- I do not have one.
On Wed, 20 Dec 2006, Randal L. Schwartz wrote:
>
> According to my headers, "strncasecmp" is defined in <string.h>,
> "NI_MAXSERV" is defined in <netdb.h>, and "initgrps" is defined
> in "unistd.h". So this patch works (just verified on OSX), but I
> don't know what damage it does elsehwere:
Look at "cache.h": the first thing it does is to include
"git-compat-util.h". And THAT in turn does include ALL the headers you
added (string.h, netdb.h and unistd.h).
So it would appear that for OS X, the
#define _XOPEN_SOURCE_EXTENDED 1 /* AIX 5.3L needs this */
#define _GNU_SOURCE
#define _BSD_SOURCE
sequence actually _disables_ those things.
Some googling finds a python source diff:
# On Mac OS X 10.4, defining _POSIX_C_SOURCE or _XOPEN_SOURCE
# disables platform specific features beyond repair.
- Darwin/8.*)
+ Darwin/8.*|Darwin/7.*)
define_xopen_source=no
;;
(and Ruby shows up as well in the google)
Can you try to grovel around in the OS X headers, and see what the magic
is to enable all the compatibility crud on OS X?
Linus
>>>>> "Linus" == Linus Torvalds <[email protected]> writes:
Linus> #define _XOPEN_SOURCE_EXTENDED 1 /* AIX 5.3L needs this */
Linus> #define _GNU_SOURCE
Linus> #define _BSD_SOURCE
Well, _GNU_SOURCE and _BSD_SOURCE only get defined, and only by some
oddballs that aren't relevant here.
Linus> sequence actually _disables_ those things.
Linus> Some googling finds a python source diff:
Linus> # On Mac OS X 10.4, defining _POSIX_C_SOURCE or _XOPEN_SOURCE
Linus> # disables platform specific features beyond repair.
Linus> - Darwin/8.*)
Linus> + Darwin/8.*|Darwin/7.*)
Linus> define_xopen_source=no
Linus> ;;
Linus> (and Ruby shows up as well in the google)
Linus> Can you try to grovel around in the OS X headers, and see what the magic
Linus> is to enable all the compatibility crud on OS X?
But yes, _XOPEN_SOURCE_EXTENDED definitely does some damage to
curses.h. However, I don't see how that's relevant to strings.h
or the others I need. There's no "config" for "compatibility".
Welcome to Linux vs Unix. :)
What I do know is (a) it worked before the header changes and (b)
the patch I just gave you works. If the patch doesn't break others,
can we just leave it in?
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[email protected]> <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!
[email protected] (Randal L. Schwartz) writes:
> But yes, _XOPEN_SOURCE_EXTENDED definitely does some damage to
> curses.h. However, I don't see how that's relevant to strings.h
> or the others I need. There's no "config" for "compatibility".
> Welcome to Linux vs Unix. :)
>
> What I do know is (a) it worked before the header changes and (b)
> the patch I just gave you works. If the patch doesn't break others,
> can we just leave it in?
That would lead to maintenance nightmare in the longer term. We
cannot do that unless we know more or less what is going on.
Including only some system headers in a random order before
feature macros are defined, and doing so in only some source
files randomly until it starts compiling, is not a solution
maintainable in the longer term.
The _EXTENDED stuff is minimally commented that AIX wants it;
otherwise we would have been tempted to say, "remove it, if it
breaks OSX" without thinking, and would have ended up breaking
AIX.
No matter what we do, I would really want a clear description of
in what way OSX headers are broken and what needs to be done to
avoid the breakage in git-compat-util.h where it sets up feature
macros and includes system headers.
On Wed, 20 Dec 2006, Randal L. Schwartz wrote:
>
> What I do know is (a) it worked before the header changes and (b)
> the patch I just gave you works. If the patch doesn't break others,
> can we just leave it in?
Well, at some point it probably _will_ break on other systems, exactly
because other systems want to have the extended declarations.
It would be much better to have all the weird system dependencies solved
in ONE place, rather than have each file (depending on just what they
happen to need) have their own hacks for each weird system header file
situation.
So it really would be a hell of a lot better to figure out _why_ strings.h
doesn't "just work" when _XOPEN_SOURCE_EXTENDED is set. Or if there are
better alternatives that work on HP-UX..
Does adding a
#define _SVID_SOURCE 1
help? Also, we should probably make the _GNU_SOURCE and _BSD_SOURCE
defines define to 1 (which is the way they'd be if we used -D_GNU_SOURCE
on the compiler command line)
IOW, the appended ...
The really sad part is that this seems to be an OS X _bug_.
"strncasecmp()" is part of the standard Open UNIX definitions, it's not
something that should be shut off by _XOPEN_SOURCE, afaik.
There were apparently some OS X developers on the git list, mind
commenting on this?
Linus
---
diff --git a/git-compat-util.h b/git-compat-util.h
index bc296b3..1400905 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -13,8 +13,9 @@
#define _XOPEN_SOURCE 600 /* glibc2 and AIX 5.3L need 500, OpenBSD needs 600 for S_ISLNK() */
#define _XOPEN_SOURCE_EXTENDED 1 /* AIX 5.3L needs this */
-#define _GNU_SOURCE
-#define _BSD_SOURCE
+#define _GNU_SOURCE 1
+#define _BSD_SOURCE 1
+#define _SVID_SOURCE 1
#include <unistd.h>
#include <stdio.h>
>>>>> "Linus" == Linus Torvalds <[email protected]> writes:
Linus> Master right now is at 54851157ac.
On a more positive note, with my local (unacceptable) changes to muck with
headers, the 54 release does in fact make git-index-pack take
under a minute for 313037 objects on OSX. Yeay!
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[email protected]> <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!