What's in git.git (stable), and Announcing GIT 1.4.4.3

What's in git.git (stable), and Announcing GIT 1.4.4.3

[Junio C Hamano]

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

Re: What's in git.git (stable), and Announcing GIT 1.4.4.3

[Randal L. Schwartz]

>>>>> "Junio" == Junio C Hamano <junkio@cox.net> 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
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.

Re: What's in git.git (stable), and Announcing GIT 1.4.4.3

[Linus Torvalds]

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.

Re: What's in git.git (stable), and Announcing GIT 1.4.4.3

[Junio C Hamano]

merlyn@stonehenge.com (Randal L. Schwartz) writes:

> Is this really in master?  I'm still seeing one-hour times on
> my Mac, using 8336afa563fbeff35e531396273065161181f04c.

I think you are behind rsync mirroring lag.

Look for X-master-at: header in my message to see if you have
that commit, please.

Re: What's in git.git (stable), and Announcing GIT 1.4.4.3

[Nicolas Pitre]

On Wed, 20 Dec 2006, Randal L. Schwartz wrote:

> >>>>> "Junio" == Junio C Hamano <junkio@cox.net> 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.

[BUG] daemon.c blows up on OSX (was Re: What's in git.git (stable), and Announcing GIT 1.4.4.3)

[Randal L. Schwartz]

>>>>> "Linus" == Linus Torvalds <torvalds@osdl.org> 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
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.

Re: [BUG] daemon.c blows up on OSX

[Junio C Hamano]

merlyn@stonehenge.com (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:

	<7v7iwnnzed.fsf@assigned-by-dhcp.cox.net>
	<7vbqlye2zz.fsf@assigned-by-dhcp.cox.net>

Re: [BUG] daemon.c blows up on OSX

[Randal L. Schwartz]

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

Junio> merlyn@stonehenge.com (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> 	<7v7iwnnzed.fsf@assigned-by-dhcp.cox.net>
Junio> 	<7vbqlye2zz.fsf@assigned-by-dhcp.cox.net>

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
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.

Re: [BUG] daemon.c blows up on OSX

[Junio C Hamano]

merlyn@stonehenge.com (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.

Re: [BUG] daemon.c blows up on OSX

[Randal L. Schwartz]

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

>>>>> "Randal" == Randal L Schwartz <merlyn@stonehenge.com> writes:

Randal> running "git version 1.4.4.3.g5485" on my openbsd box, but I can't get
Randal> there on my OSX box.

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:

diff --git a/daemon.c b/daemon.c
index b129b83..5ce73ed 100644
--- a/daemon.c
+++ b/daemon.c
@@ -1,3 +1,7 @@
+#include <string.h>
+#include <netdb.h>
+#include <unistd.h>
+
 #include "cache.h"
 #include "pkt-line.h"
 #include "exec_cmd.h"

However, now imap-send.o blows up:

imap-send.c: In function 'imap_open_store':
imap-send.c:908: error: 'AF_LOCAL' undeclared (first use in this function)
imap-send.c:908: error: (Each undeclared identifier is reported only once
imap-send.c:908: error: for each function it appears in.)
imap-send.c:990: warning: implicit declaration of function 'getpass'
imap-send.c:990: warning: assignment makes pointer from integer without a cast
make: *** [imap-send.o] Error 1

and finding "getpass" wants me to add "unistd.h" there too.

Hmm.  Let's see if I can use git-format-patch as Linus intended.


[-- Attachment #2: patch for osx --]
[-- Type: text/plain, Size: 852 bytes --]

From 1549561dc68a1ea71f137c40109c90d33c0f9887 Mon Sep 17 00:00:00 2001
From: Randal L. Schwartz <merlyn@4.sub-70-192-166.myvzw.com>
Date: Wed, 20 Dec 2006 14:45:49 -0800
Subject: [PATCH] patch for osx

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

diff --git a/daemon.c b/daemon.c
index b129b83..5ce73ed 100644
--- a/daemon.c
+++ b/daemon.c
@@ -1,3 +1,7 @@
+#include <string.h>
+#include <netdb.h>
+#include <unistd.h>
+
 #include "cache.h"
 #include "pkt-line.h"
 #include "exec_cmd.h"
diff --git a/imap-send.c b/imap-send.c
index 894cbbd..afd7447 100644
--- a/imap-send.c
+++ b/imap-send.c
@@ -22,6 +22,8 @@
  *  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
  */
 
+#include <unistd.h>
+
 #include "cache.h"
 
 typedef struct store_conf {
-- 
1.4.4.3.g5485-dirty


[-- Attachment #3: Type: text/plain, Size: 291 bytes --]


-- 
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: [BUG] daemon.c blows up on OSX

[Junio C Hamano]

merlyn@stonehenge.com (Randal L. Schwartz) writes:

>>>>>> "Randal" == Randal L Schwartz <merlyn@stonehenge.com> writes:
>
> Randal> running "git version 1.4.4.3.g5485" on my openbsd box, but I can't get
> Randal> there on my OSX box.
>
> 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:
>
> diff --git a/daemon.c b/daemon.c
> index b129b83..5ce73ed 100644
> --- a/daemon.c
> +++ b/daemon.c
> @@ -1,3 +1,7 @@
> +#include <string.h>
> +#include <netdb.h>
> +#include <unistd.h>
> +
>  #include "cache.h"

This unfortunately violates the "all common system headers in
git-compat-util.h" rule, which is needed to define _XOPEN_SOURCE
and friends before including the system header files.

And string.h, netdb.h and unistd.h are already included there,
so there is something deeper going on on OSX.

Is the declaration of strncasecmp in <string.h> on OSX
conditional to some macro (and the same question about other
symbols you did not get)?  We need to find out what feature
macros are expected on that platform and define them as needed.

For example, on OpenBSD, <sys/types.h> does not expose u_int
without __BSD_VISIBLE, and its <netinet/tcp.h> header uses that
type.  The source files (user programs, that's us) are expected
to include sys/types.h before including netinet/tcp.h *AND*
expected to somehow cause __BSD_VISIBLE be defined before
including sys/types.h.  That's why we have _BSD_SOURCE in our
git-compat-util.h header file (_XOPEN_SOURCE and _GNU_SOURCE
serve similar purposes for various other systems).

Re: [BUG] daemon.c blows up on OSX

[Linus Torvalds]

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?

Re: [BUG] daemon.c blows up on OSX

[Randal L. Schwartz]

>>>>> "Linus" == Linus Torvalds <torvalds@osdl.org> 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
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.

Re: [BUG] daemon.c blows up on OSX

[Randal L. Schwartz]

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

Junio> This unfortunately violates the "all common system headers in
Junio> git-compat-util.h" rule, which is needed to define _XOPEN_SOURCE
Junio> and friends before including the system header files.

Junio> And string.h, netdb.h and unistd.h are already included there,
Junio> so there is something deeper going on on OSX.

Junio> Is the declaration of strncasecmp in <string.h> on OSX
Junio> conditional to some macro (and the same question about other
Junio> symbols you did not get)?  We need to find out what feature
Junio> macros are expected on that platform and define them as needed.

If one of those defines _POSIX_C_SOURCE (or _ANSI_SOURCE),
then <string.h> does *not* define "strncasecmp", because it has those
under a comment of "Nonstandard routines".

Is anything earlier defining one of these?

And yes, netdb.h also has a lot of those depending on _POSIX_C_SOURCE,
and so does unistd.h

So that's your culprit.  You're defining _POSIX_C_SOURCE when you're
not really proper _POSIX_C compliant.  Can you just remove that?

And sys/cdefs.h for darwin has this:

    /* Deal with various X/Open Portability Guides and Single UNIX Spec. */
    #ifdef _XOPEN_SOURCE
    #if _XOPEN_SOURCE - 0L >= 600L
    #undef _POSIX_C_SOURCE
    #define _POSIX_C_SOURCE         200112L
    #elif _XOPEN_SOURCE - 0L >= 500L
    #undef _POSIX_C_SOURCE
    #define _POSIX_C_SOURCE         199506L
    #endif
    #endif

So that's likely how _POSIX_C_SOURCE is getting defined for the rest.

-- 
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.

Re: [BUG] daemon.c blows up on OSX

[Junio C Hamano]

merlyn@stonehenge.com (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.

Re: [BUG] daemon.c blows up on OSX

[Randal L. Schwartz]

>>>>> "Randal" == Randal L Schwartz <merlyn@stonehenge.com> writes:

Randal> So that's likely how _POSIX_C_SOURCE is getting defined for the rest.

Unfortunately, just deleting the two _XOPEN_SOURCE entries in
git-compat-util.h doesn't do it, even for OSX.  So something more convoluted
here is going on.

-- 
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: [BUG] daemon.c blows up on OSX

[Linus Torvalds]

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>

Re: What's in git.git (stable), and Announcing GIT 1.4.4.3

[Randal L. Schwartz]

>>>>> "Linus" == Linus Torvalds <torvalds@osdl.org> 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
<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: [BUG] daemon.c blows up on OSX

[Terje Sten Bjerkseth]

On 12/21/06, Linus Torvalds <torvalds@osdl.org> wrote:
> 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 ...

For Mac OS X 10.4, _XOPEN_SOURCE seems to define _POSIX_C_SOURCE which
causes the NI_MAXSERV problem in netdb.h. The appended seems to make
it work.

--
diff --git a/git-compat-util.h b/git-compat-util.h
index bc296b3..41fa7f6 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -11,8 +11,10 @@

 #define ARRAY_SIZE(x) (sizeof(x)/sizeof(x[0]))

+#ifndef __APPLE_CC__
 #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 */
+#endif
 #define _GNU_SOURCE

Re: [BUG] daemon.c blows up on OSX

[Junio C Hamano]

"Terje Sten Bjerkseth" <terje@bjerkseth.org> writes:

> On 12/21/06, Linus Torvalds <torvalds@osdl.org> wrote:
>> 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 ...
>
> For Mac OS X 10.4, _XOPEN_SOURCE seems to define _POSIX_C_SOURCE which
> causes the NI_MAXSERV problem in netdb.h. The appended seems to make
> it work.
>
> --
> diff --git a/git-compat-util.h b/git-compat-util.h
> index bc296b3..41fa7f6 100644
> --- a/git-compat-util.h
> +++ b/git-compat-util.h
> @@ -11,8 +11,10 @@
>
> #define ARRAY_SIZE(x) (sizeof(x)/sizeof(x[0]))
>
> +#ifndef __APPLE_CC__
> #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 */
> +#endif
> #define _GNU_SOURCE
> #define _BSD_SOURCE

Thanks.  While this is in a better direction than randomly
including the headers in the source, it is still sad.

Does everybody use Apple CC on OSX?  Is the symbol defined even
with GCC?  Or Gcc fixes headers well enough and makes this a
non-issue?

Re: [BUG] daemon.c blows up on OSX

[Linus Torvalds]

On Thu, 21 Dec 2006, Terje Sten Bjerkseth wrote:
> 
> For Mac OS X 10.4, _XOPEN_SOURCE seems to define _POSIX_C_SOURCE which
> causes the NI_MAXSERV problem in netdb.h. The appended seems to make
> it work.

Ok, that's probably the best we can do. Along with perhaps cursing at 
apple a bit.

Your patch is whitespace-damaged, btw.

Re: [BUG] daemon.c blows up on OSX

[Terje Sten Bjerkseth]

On 12/21/06, Junio C Hamano <junkio@cox.net> wrote:
> Thanks.  While this is in a better direction than randomly
> including the headers in the source, it is still sad.
>
> Does everybody use Apple CC on OSX?  Is the symbol defined even
> with GCC?  Or Gcc fixes headers well enough and makes this a
> non-issue?

I'm not sure about everybody, but at least the Apple CC *is* GCC:

~/src/git terjesb$ cc --version
i686-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc. build 5367)
Copyright (C) 2005 Free Software Foundation, Inc.

so this is probably a non-issue for default setups. (Sorry about the

Re: [BUG] daemon.c blows up on OSX

[Junio C Hamano]

"Terje Sten Bjerkseth" <terje@bjerkseth.org> writes:

> On 12/21/06, Junio C Hamano <junkio@cox.net> wrote:
>> Thanks.  While this is in a better direction than randomly
>> including the headers in the source, it is still sad.
>>
>> Does everybody use Apple CC on OSX?  Is the symbol defined even
>> with GCC?  Or Gcc fixes headers well enough and makes this a
>> non-issue?
>
> I'm not sure about everybody, but at least the Apple CC *is* GCC:

Thanks for clarifying this; will apply.

Re: [BUG] daemon.c blows up on OSX

[Randal L. Schwartz]

>>>>> "Linus" == Linus Torvalds <torvalds@osdl.org> writes:

Linus> Your patch is whitespace-damaged, btw.

The version as an attachment shouldn't have been.

The cut-n-paste might have been.

-- 
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.

Re: [BUG] daemon.c blows up on OSX

[Randal L. Schwartz]

>>>>> "Terje" == Terje Sten Bjerkseth <terje@bjerkseth.org> writes:


Terje> +#ifndef __APPLE_CC__
Terje>  #define _XOPEN_SOURCE 600 /* glibc2 and AIX 5.3L need 500, OpenBSD
Terje> needs 600 for S_ISLNK() */
Terje>  #define _XOPEN_SOURCE_EXTENDED 1 /* AIX 5.3L needs this */
Terje> +#endif
Terje>  #define _GNU_SOURCE
Terje>  #define _BSD_SOURCE
Terje> -

I tried the moral equivalent of that, and it failed to compile many
other things then.  So that's not it.

-- 
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.

Re: [BUG] daemon.c blows up on OSX

[Junio C Hamano]

merlyn@stonehenge.com (Randal L. Schwartz) writes:

>>>>>> "Linus" == Linus Torvalds <torvalds@osdl.org> writes:
>
> Linus> Your patch is whitespace-damaged, btw.
>
> The version as an attachment shouldn't have been.
>
> The cut-n-paste might have been.

While I do not have a clue on what point you are trying to make,
I have a more important question for you.

Does Terje's patch fix it for you?

Re: [BUG] daemon.c blows up on OSX

[Randal L. Schwartz]

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

Junio> "Terje Sten Bjerkseth" <terje@bjerkseth.org> writes:
>> On 12/21/06, Junio C Hamano <junkio@cox.net> wrote:
>>> Thanks.  While this is in a better direction than randomly
>>> including the headers in the source, it is still sad.
>>> 
>>> Does everybody use Apple CC on OSX?  Is the symbol defined even
>>> with GCC?  Or Gcc fixes headers well enough and makes this a
>>> non-issue?
>> 
>> I'm not sure about everybody, but at least the Apple CC *is* GCC:

Junio> Thanks for clarifying this; will apply.

But don't because it doesn't help. :(

-- 
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.

Re: [BUG] daemon.c blows up on OSX

[Junio C Hamano]

merlyn@stonehenge.com (Randal L. Schwartz) writes:

>>> I'm not sure about everybody, but at least the Apple CC *is* GCC:
>
> Junio> Thanks for clarifying this; will apply.
>
> But don't because it doesn't help. :(

Won't; thanks for catching me soon enough.

Re: [BUG] daemon.c blows up on OSX

[Terje Sten Bjerkseth]

On 20 Dec 2006 17:20:40 -0800, Randal L. Schwartz <merlyn@stonehenge.com> wrote:
> >>>>> "Junio" == Junio C Hamano <junkio@cox.net> writes:
> Junio> Thanks for clarifying this; will apply.
>
> But don't because it doesn't help. :(

It definitely works here with it. This is on Mac OS X 10.4.8 (Intel)
with default GCC 4.0.1 from Developer Tools.

Which version are you using? Does it work if you change from testing
__APPLE_CC__ to just __APPLE__? That also works here, and is probably
better anyway. (Perhaps you are using an earlier version and the
former define was introduced with gcc 4.0 to separate gcc compiler
versions.)

Re: [BUG] daemon.c blows up on OSX

[Randal L. Schwartz]

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

>>>>> "Brian" == Brian Gernhardt <benji@silverinsanity.com> writes:

Brian> On Dec 20, 2006, at 8:08 PM, Randal L. Schwartz wrote:

>>>>>>> "Terje" == Terje Sten Bjerkseth <terje@bjerkseth.org> writes:
>> 
>> 
Terje> +#ifndef __APPLE_CC__
Terje> #define _XOPEN_SOURCE 600 /* glibc2 and AIX 5.3L need 500,  OpenBSD
Terje> needs 600 for S_ISLNK() */
Terje> #define _XOPEN_SOURCE_EXTENDED 1 /* AIX 5.3L needs this */
Terje> +#endif
Terje> #define _GNU_SOURCE
Terje> #define _BSD_SOURCE
Terje> -
>> 
>> I tried the moral equivalent of that, and it failed to compile many
>> other things then.  So that's not it.

Brian> Well, it seems to work for me as is (although I applied it manually  instead
Brian> of dealing with copy/paste with a patch).

I did it with #if 0 / #end instead of the __APPLE_CC__ symbol.
But, weirdly, now that I used the symbol, I get a good compile.

Does #if 0 not work? :)

Sorry for being objectionable earlier then.  I've attached the precise
patch I used and works and verified.

-- 
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!

[-- Attachment #2: 0001-patch-from-email.txt --]
[-- Type: text/plain, Size: 727 bytes --]

>From 9e3f88df3f6b17804f53fb497202f0879ea5e5f3 Mon Sep 17 00:00:00 2001
From: Randal L. Schwartz <merlyn@stonehenge.com>
Date: Wed, 20 Dec 2006 17:32:21 -0800
Subject: [PATCH] patch-from-email

---
 git-compat-util.h |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/git-compat-util.h b/git-compat-util.h
index bc296b3..41fa7f6 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -11,8 +11,10 @@
 
 #define ARRAY_SIZE(x) (sizeof(x)/sizeof(x[0]))
 
+#ifndef __APPLE_CC__
 #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 */
+#endif
 #define _GNU_SOURCE
 #define _BSD_SOURCE
 
-- 
1.4.4.3.g9e3f8

Re: [BUG] daemon.c blows up on OSX

[Junio C Hamano]

merlyn@stonehenge.com (Randal L. Schwartz) writes:

>>> I tried the moral equivalent of that, and it failed to compile many
>>> other things then.  So that's not it.
> ...
> I did it with #if 0 / #end instead of the __APPLE_CC__ symbol.
> But, weirdly, now that I used the symbol, I get a good compile.
> ...
> Sorry for being objectionable earlier then.  I've attached the precise
> patch I used and works and verified.

Just to make sure... the attached looks exactly what Terje's
patch would have been before the whitespace damage.  Can I take
this as confirmation that the patch works for you and Terje?

I wonder what the earlier failure you got from "the moral
equivalent" was -- I hope it is not an indication that we have a
dependency bug in our Makefile somewhere.

Thanks.

> diff --git a/git-compat-util.h b/git-compat-util.h
> index bc296b3..41fa7f6 100644
> --- a/git-compat-util.h
> +++ b/git-compat-util.h
> @@ -11,8 +11,10 @@
>  
>  #define ARRAY_SIZE(x) (sizeof(x)/sizeof(x[0]))
>  
> +#ifndef __APPLE_CC__
>  #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 */
> +#endif
>  #define _GNU_SOURCE
>  #define _BSD_SOURCE
>  
> -- 
> 1.4.4.3.g9e3f8

Re: [BUG] daemon.c blows up on OSX

[Randal L. Schwartz]

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

Junio> Just to make sure... the attached looks exactly what Terje's
Junio> patch would have been before the whitespace damage.  Can I take
Junio> this as confirmation that the patch works for you and Terje?

The patch I uploaded should be character-equivalent to Terje's.
I don't know what "whitespace damage" you're referencing.

Junio> I wonder what the earlier failure you got from "the moral
Junio> equivalent" was -- I hope it is not an indication that we have a
Junio> dependency bug in our Makefile somewhere.

Yeah, I'm not sure why

#if 0
those two defines
#end

doesn't do the same thing.  Oh well, shrug.

-- 
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: [BUG] daemon.c blows up on OSX

[Junio C Hamano]

merlyn@stonehenge.com (Randal L. Schwartz) writes:

> The patch I uploaded should be character-equivalent to Terje's.

Thanks.

> I don't know what "whitespace damage" you're referencing.

Aha, it was undamaged but rendered as if it were, because it was
of "content-type: text/plain; format=flawed".

Re: Re: [BUG] daemon.c blows up on OSX

[Stefan Pfetzing]

Hi,

20 Dec 2006 15:34:43 -0800, Randal L. Schwartz <merlyn@stonehenge.com>:
>
> Unfortunately, just deleting the two _XOPEN_SOURCE entries in
> git-compat-util.h doesn't do it, even for OSX.  So something more convoluted
> here is going on.

Hm, very strange - for me the patch mentioned here works fine. (Mac OS
X 10.4.8 on an Intel Mac)

bye

dreamind

-- 
       http://www.dreamind.de/
Oroborus and Debian GNU/Linux Developer.

Re: What's in git.git (stable), and Announcing GIT 1.4.4.3

[Johannes Schindelin]

Hi,

On Wed, 20 Dec 2006, Junio C Hamano wrote:

> Look for X-master-at: header in my message to see if you have that 
> commit, please.

Nice!

Ciao,
Dscho

Re: What's in git.git (stable), and Announcing GIT 1.4.4.3

[Junio C Hamano]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> Hi,
>
> On Wed, 20 Dec 2006, Junio C Hamano wrote:
>
>> Look for X-master-at: header in my message to see if you have that 
>> commit, please.
>
> Nice!

Sorry for not advertising.  The header has been there for a long
time.

[PATCH] Do not define _XOPEN_SOURCE on MacOSX as it is too restricting there

[Marco Roeland]

Defining _XOPEN_SOURCE on Darwin always leads to a restricted set of
available functions and symbols. This can not be cured by adding extra
defines in any way. So there really is only the choice between _not_
defining this symbol on Mac OS X or restricting our usage of functions
and symbols to the POSIX sets that are in term implied by _XOPEN_SOURCE.
The first seems better.

Note the last three lines from this following literal code snippet in
/usr/include/sys/cdefs.h from the Apple Darwin sources:

 * By default newly complied code will actually get the same symbols
 * that the old code did.  Defining any of _APPLE_C_SOURCE, _XOPEN_SOURCE,
 * or _POSIX_C_SOURCE will give you the new symbols.  Defining _XOPEN_SOURCE
 * or _POSIX_C_SOURCE also restricts the avilable symbols to a subset of
 * Apple's APIs.

We want our symbols "avilable" so lets not use _XOPEN_SOURCE on Darwin!

The preferred way of checking specific Apple specific issues is by using
the __APPLE__ predefined macro.

The extra define _XOPEN_SOURCE_EXTENDED does only affect some headers
(like the /usr/include/curses.h header) and can stay.

Patch from Terje Sten Bjerkseth, only added a comment.

diff --git a/git-compat-util.h b/git-compat-util.h
index bc296b3..f056d20 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -11,7 +11,11 @@
 
 #define ARRAY_SIZE(x) (sizeof(x)/sizeof(x[0]))
 
+#if !defined __APPLE__
 #define _XOPEN_SOURCE 600 /* glibc2 and AIX 5.3L need 500, OpenBSD needs 600 for S_ISLNK() */
+#else
+			/* On Darwin defining _XOPEN_SOURCE always restricts available functions */
+#endif
 #define _XOPEN_SOURCE_EXTENDED 1 /* AIX 5.3L needs this */
 #define _GNU_SOURCE
 #define _BSD_SOURCE

[PATCH] Don't define _XOPEN_SOURCE on MacOSX and FreeBSD as it is too restricting

[Marco Roeland]

Defining _XOPEN_SOURCE on Darwin always leads to a restricted set of
available functions and symbols. This can not be cured by adding extra
defines in any way. So there really is only the choice between _not_
defining this symbol on Mac OS X or restricting our usage of functions
and symbols to the POSIX sets that are in term implied by _XOPEN_SOURCE.
The first seems better.

Note the last three lines from this following literal code snippet in
/usr/include/sys/cdefs.h from the Apple Darwin sources:

 * By default newly complied code will actually get the same symbols
 * that the old code did.  Defining any of _APPLE_C_SOURCE, _XOPEN_SOURCE,
 * or _POSIX_C_SOURCE will give you the new symbols.  Defining _XOPEN_SOURCE
 * or _POSIX_C_SOURCE also restricts the avilable symbols to a subset of
 * Apple's APIs.

We want our symbols "avilable" so lets not use _XOPEN_SOURCE on Darwin!

The preferred way of checking specific Apple specific issues is by using
the __APPLE__ predefined macro.

The extra define _XOPEN_SOURCE_EXTENDED does only affect some headers
(like the /usr/include/curses.h header) and can stay.

FreeBSD 6 requires the __BSD_VISIBLE flag for fchmod(), IPPROTO_IPV6 and
more which is only properly set by <sys/cdefs.h> if _POSIX_C_SOURCE
isn't present. However, _POSIX_C_SOURCE is defined if _XOPEN_SOURCE is
defined and >=500.

As a solution, simply don't define _XOPEN_SOURCE for FreeBSD and continue
with its defaults.

Author: Terje Sten Bjerkseth <terje@bjerkseth.org>
Signed-off-by: Rocco Rutte <pdmef@gmx.net>
Signed-off-by: Marco Roeland <marco.roeland@xs4all.nl>
---
 git-compat-util.h |    7 +++++++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/git-compat-util.h b/git-compat-util.h
index bc296b3..6f46f36 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -11,7 +11,14 @@
 
 #define ARRAY_SIZE(x) (sizeof(x)/sizeof(x[0]))
 
+#if !defined(__APPLE__) && !defined(__FreeBSD)
 #define _XOPEN_SOURCE 600 /* glibc2 and AIX 5.3L need 500, OpenBSD needs 600 for S_ISLNK() */
+#else
+			/*
+			 * On Darwin and FreeBSD defining _XOPEN_SOURCE always restricts available
+			 * functions and symbols.
+			 */
+#endif
 #define _XOPEN_SOURCE_EXTENDED 1 /* AIX 5.3L needs this */
 #define _GNU_SOURCE
 #define _BSD_SOURCE
-- 
1.4.4.2.g81597-dirty

Re: What's in git.git (stable), and Announcing GIT 1.4.4.3

[Johannes Schindelin]

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

Hi,

On Wed, 20 Dec 2006, Junio C Hamano wrote:

>    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

I assume that this line is indented manually, but ...

>       clarify some error messages wrt unknown object types
> 
>    Robert Fitzsimons (1):
>       gitweb: Show '...' links in "summary" view only if there are more items

this is not, in spite of being longer than 76 characters (Do I remember 
correctly that this supposed to be the maximum length for lines in 
emails?).

FWIW, I hacked a half-serious patch to wrap the lines automatically:

-- snipsnap --
[FWOT] shortlog: wrap long lines

If a oneline is longer than 76 characters, wrap it and indent with
9 instead of 6 spaces.

For the heck of it, assume UTF-8, and fall back to single-byte
encodings when finding that it cannot be UTF-8. (Not that it makes
a difference if you stick to ASCII.)
---
 builtin-shortlog.c  |   61 ++++++++++++++++++++++++++++++++++++++++++++++++++-
 t/t4201-shortlog.sh |   44 ++++++++++++++++++++++++++++++++++++
 2 files changed, 104 insertions(+), 1 deletions(-)

diff --git a/builtin-shortlog.c b/builtin-shortlog.c
index edb4042..be5691e 100644
--- a/builtin-shortlog.c
+++ b/builtin-shortlog.c
@@ -276,6 +276,64 @@ static void get_from_rev(struct rev_info *rev, struct path_list *list)
 
 }
 
+/* Wrap the text, if necessary. */
+static void print_oneline(const char *oneline, int indent, int indent2, int len)
+{
+	int i, count, count_utf8, last_space = -1, assume_utf8 = 1;
+
+	count = count_utf8 = 0;
+
+	for (;;) {
+		unsigned char c = (unsigned char)oneline[count++];
+		if (!c || isspace(c)) {
+			int cur = indent
+				+ (assume_utf8 ? count_utf8 : count - 1);
+			if (cur < len || last_space < 0) {
+//printf("(%d)", cur);
+				if (last_space > 0)
+					putchar(' ');
+				else
+					for (i = 0; i < indent; i++)
+						putchar(' ');
+				for (i = last_space + 1; i < count - 1; i++)
+					putchar(oneline[i]);
+				if (!c) {
+					putchar('\n');
+					return;
+				}
+				last_space = count - 1;
+				count_utf8++;
+			} else {
+				putchar('\n');
+				for (oneline += last_space + 1;
+						isspace(*oneline); oneline++)
+					; /* do nothing */
+				indent = indent2;
+				last_space = -1;
+				count = count_utf8 = 0;
+			}
+			continue;
+		}
+		if (assume_utf8 && c > 0x7f) {
+			int multi_byte_count = 1;
+			if ((c & 0xe0) == 0xc0)
+				multi_byte_count = 2;
+			else if ((c & 0xf0) == 0xe0)
+				multi_byte_count = 3;
+			else if ((c & 0xf8) == 0xf0)
+				multi_byte_count = 4;
+			else
+				assume_utf8 = 0;
+			for (i = 0; i < multi_byte_count - 1; i++)
+				if (!oneline[count + i])
+					assume_utf8 = 0;
+			if (assume_utf8)
+				count += multi_byte_count - 1;
+		}
+		count_utf8++;
+	}
+}
+
 int cmd_shortlog(int argc, const char **argv, const char *prefix)
 {
 	struct rev_info rev;
@@ -321,7 +379,8 @@ int cmd_shortlog(int argc, const char **argv, const char *prefix)
 		} else {
 			printf("%s (%d):\n", list.items[i].path, onelines->nr);
 			for (j = onelines->nr - 1; j >= 0; j--)
-				printf("      %s\n", onelines->items[j].path);
+				print_oneline(onelines->items[j].path,
+					6, 9, 76);
 			printf("\n");
 		}
 
diff --git a/t/t4201-shortlog.sh b/t/t4201-shortlog.sh
new file mode 100644
index 0000000..86a2295
--- /dev/null
+++ b/t/t4201-shortlog.sh
@@ -0,0 +1,44 @@
+#!/bin/sh
+#
+# Copyright (c) 2006 Johannes E. Schindelin
+#
+
+test_description='git-shortlog
+'
+
+. ./test-lib.sh
+
+echo 1 > a1
+git add a1
+tree=$(git write-tree)
+commit=$((echo "Test"; echo) | git commit-tree $tree)
+git update-ref HEAD $commit 
+
+echo 2 > a1
+git commit -m "This is a very, very long first line for the commit message to see if it is wrapped correctly" a1
+
+# test if the wrapping is still valid when replacing all i's by treble clefs.
+echo 3 > a1
+git commit -m "$(echo "This is a very, very long first line for the commit message to see if it is wrapped correctly" | sed "s/i/1234/g" | tr 1234 '\360\235\204\236')" a1
+
+# now fsck up the utf8
+echo 4 > a1
+git commit -m "$(echo "This is a very, very long first line for the commit message to see if it is wrapped correctly" | sed "s/i/1234/g" | tr 1234 '\370\235\204\236')" a1
+
+git shortlog HEAD > out
+
+cat > expect << EOF
+A U Thor (4):
+      Test
+      This is a very, very long first line for the commit message to see if
+         it is wrapped correctly
+      Th𝄞s 𝄞s a very, very long f𝄞rst l𝄞ne for the comm𝄞t message to see 𝄞f
+         𝄞t 𝄞s wrapped correctly
+      Thø„žs ø„žs a very, very long fø„žrst lø„žne for the commø„žt
+         message to see ø„žf ø„žt ø„žs wrapped correctly
+
+EOF
+
+test_expect_success 'shortlog wrapping' 'diff -u expect out'
+
+test_done
-- 
1.4.4.3.g610c-dirty

Re: [PATCH] Don't define _XOPEN_SOURCE on MacOSX and FreeBSD as it is too restricting

[Junio C Hamano]

Marco Roeland <marco.roeland@xs4all.nl> writes:

> We want our symbols "avilable" so lets not use _XOPEN_SOURCE on Darwin!

Personally, I think hiding interfaces such as strXXX and memXXX
based on _XOPEN_SOURCE level is already a bug in the system
header implementation.  The symbols that begin with str are
already reserved by the standard and I do not see any point
in the system headers to try avoiding namespace contamination.

But we are not in the business of fixing the system headers.

> The preferred way of checking specific Apple specific issues is by using
> the __APPLE__ predefined macro.
>
> diff --git a/git-compat-util.h b/git-compat-util.h
> index bc296b3..6f46f36 100644
> --- a/git-compat-util.h
> +++ b/git-compat-util.h
> @@ -11,7 +11,14 @@
>  
>  #define ARRAY_SIZE(x) (sizeof(x)/sizeof(x[0]))
>  
> +#if !defined(__APPLE__) && !defined(__FreeBSD)
>  #define _XOPEN_SOURCE 600 /* glibc2 and AIX 5.3L need 500, OpenBSD needs 600 for S_ISLNK() */
> +#else
> +			/*
> +			 * On Darwin and FreeBSD defining _XOPEN_SOURCE always restricts available
> +			 * functions and symbols.
> +			 */
> +#endif
>  #define _XOPEN_SOURCE_EXTENDED 1 /* AIX 5.3L needs this */
>  #define _GNU_SOURCE
>  #define _BSD_SOURCE

Two and half questions.

 #0.5 Have you checked the tip of 'master' that has Terje's
      patch?  It was reported to work yesterday and that is what
      was committed already.

 #1   __APPLE__ vs __APPLE_CC__ is not something I can decide (I
      do not run a Mac).  If MaxOS is derived from FreeBSD, does
      it by chance define __FreeBSD as well?

 #2   Terje's patch excludes _XOPEN_SOURCE_EXTENDED as well on a
      Mac, but yours doesn't.  Is there a reason that you would
      want '#define _XOPEN_SOURCE_EXTENDED 1'?  Do both FreeBSD
      and Mac behave well with it defined?

Re: [PATCH] Don't define _XOPEN_SOURCE on MacOSX and FreeBSD as it is too restricting

[Shawn Pearce]

Junio C Hamano <junkio@cox.net> wrote:
>  #0.5 Have you checked the tip of 'master' that has Terje's
>       patch?  It was reported to work yesterday and that is what
>       was committed already.

OK, but that isn't applied in next for some reason.  I'm still
carrying around my own version of Terje's patch.  :-(
 
>  #1   __APPLE__ vs __APPLE_CC__ is not something I can decide (I
>       do not run a Mac).  If MaxOS is derived from FreeBSD, does
>       it by chance define __FreeBSD as well?

__FreeBSD doesn't work here on my Mac.

-- 
Shawn.

Re: [PATCH] Don't define _XOPEN_SOURCE on MacOSX and FreeBSD as it is too restricting

[Rocco Rutte]

Hi,

* Junio C Hamano [06-12-21 16:52:52 -0800] wrote:
>Marco Roeland <marco.roeland@xs4all.nl> writes:

>> We want our symbols "avilable" so lets not use _XOPEN_SOURCE on Darwin!

>Personally, I think hiding interfaces such as strXXX and memXXX
>based on _XOPEN_SOURCE level is already a bug in the system
>header implementation.  The symbols that begin with str are
>already reserved by the standard and I do not see any point
>in the system headers to try avoiding namespace contamination.

Well, it depends, I'd say. Different strXXX functions may be introduced 
by different versions of standards and with _POSIX_C_SOURCE one can, for 
example, define to be compile for a specific standard version only.

>Two and half questions.

> #1   __APPLE__ vs __APPLE_CC__ is not something I can decide (I
>      do not run a Mac).  If MaxOS is derived from FreeBSD, does
>      it by chance define __FreeBSD as well?

> #2   Terje's patch excludes _XOPEN_SOURCE_EXTENDED as well on a
>      Mac, but yours doesn't.  Is there a reason that you would
>      want '#define _XOPEN_SOURCE_EXTENDED 1'?  Do both FreeBSD
>      and Mac behave well with it defined?

First of all, the combined patch posted is wrong since __FreeBSD doesn't 
work on FreeBSD, but __FreeBSD__ does.

Second, a grep over the FreeBSD headers in /usr/include shows that 
_XOPEN_SOURCE_EXTENDED only affects 2 curses header files, so it's safe 
to exclude it, i.e. define it for FreeBSD.

   bye, Rocco
-- 
:wq!

Re: [PATCH] Don't define _XOPEN_SOURCE on MacOSX and FreeBSD as it is too restricting

[Marco Roeland]

On Thursday December 21st 2006 at 16:52 Junio C Hamano wrote:

> Personally, I think hiding interfaces such as strXXX and memXXX
> based on _XOPEN_SOURCE level is already a bug in the system
> header implementation.  The symbols that begin with str are
> already reserved by the standard and I do not see any point
> in the system headers to try avoiding namespace contamination.
> 
> But we are not in the business of fixing the system headers.

;-)

Perhaps the idea behind this might be that it allows you to easier
develop software that really only uses interfaces strictly defined in
some "standards" to be always available on compliant platforms. That's
all I could think of why you ever would want to do it like this yes.

> Two and half questions.
> 
>  #0.5 Have you checked the tip of 'master' that has Terje's
>       patch?  It was reported to work yesterday and that is what
>       was committed already.

For some reason a normal "pull" didn't show this one here yet. But I can
see it by merging. The commit "c902c9a" that I now see from Terje does
indeed work here. At any rate that one alone doesn't fix the (same)
FreeBSD issue as reported by Rocco Rutte who sent in an almost identical
patch but with the __FreeBSD__ define.

>  #1   __APPLE__ vs __APPLE_CC__ is not something I can decide (I
>       do not run a Mac).  If MaxOS is derived from FreeBSD, does
>       it by chance define __FreeBSD as well?

As far as I know __APPLE__ is the preferred way of finding out we're
running for a Darwin target. Someone mentioned that __APPLE_CC__ was not
introduced until Apple OS X 10.4. It's value here ('5367') is the build
version of the Apple gcc compiler, doesn't seem very standardized. The
__APPLE__ macro is defined as '1'.

Unfortunately no there is _not_ any "BSD" like macro defined here, so no
__FreeBSD or something. And interesting enough we already know that
OpenBSD specifically needs the _XOPEN_SOURCE define. Anyone out there
with a NetBSD box so we can fix that as well? ;-)

>  #2   Terje's patch excludes _XOPEN_SOURCE_EXTENDED as well on a
>       Mac, but yours doesn't.  Is there a reason that you would
>       want '#define _XOPEN_SOURCE_EXTENDED 1'?  Do both FreeBSD
>       and Mac behave well with it defined?

On Apple compiling git works fine both with and without
_XOPEN_SOURCES_EXTENDED. But looking in the headers, in contrast to the
_XOPEN_SOURCE define which restricts functionality to some predefined
set, the _XOPEN_SOURCES_EXTENDED only adds functionality and doesn't
remove it. So I thought it might be best to keep as much symbols as
possible to be the same for all platforms for future expandibility.

Probably FreeBSD behaves the same with respect to
_XOPEN_SOURCE_EXTENDED. Will check later today.

I don't know if the "Apple Public Source License" allows me to put the
Darwin system headers in a publicly accessable place, so I won't do
that, but if people are interested I can of course privately provide the
system headers and predefined symbols for anyone interested.
-- 
Marco Roeland

Re: [PATCH] Don't define _XOPEN_SOURCE on MacOSX and FreeBSD as it is too restricting

[Junio C Hamano]

Marco Roeland <marco.roeland@xs4all.nl> writes:

> On Thursday December 21st 2006 at 16:52 Junio C Hamano wrote:
>
>> Personally, I think hiding interfaces such as strXXX and memXXX
>> based on _XOPEN_SOURCE level is already a bug in the system
>> header implementation.  The symbols that begin with str are
>> already reserved by the standard and I do not see any point
>> in the system headers to try avoiding namespace contamination.
>> 
>> But we are not in the business of fixing the system headers.
>
> ;-)
>
> Perhaps the idea behind this might be that it allows you to easier
> develop software that really only uses interfaces strictly defined in
> some "standards" to be always available on compliant platforms. That's
> all I could think of why you ever would want to do it like this yes.

(offtopic) Yeah, but my point was that ANSI C reserves _all_
symbols that begin with str ("Names reserved for expansion"),
not just a specific set of functions like strcmp, strcpy, etc.,
so if a program tries to be compliant with it, it cannot use,
for example, strncasecmp (was that the symbol we had trouble
with?)  for its own purpose anyway -- which means the system
header implementation should not have to worry about namespace
pollution.  I do not see any reason for them to hide
strncasecmp, for example.

> On Apple compiling git works fine both with and without
> _XOPEN_SOURCES_EXTENDED. But looking in the headers, in contrast to the
> _XOPEN_SOURCE define which restricts functionality to some predefined
> set, the _XOPEN_SOURCES_EXTENDED only adds functionality and doesn't
> remove it. So I thought it might be best to keep as much symbols as
> possible to be the same for all platforms for future expandibility.
>
> Probably FreeBSD behaves the same with respect to
> _XOPEN_SOURCE_EXTENDED. Will check later today.

Ok, thanks.

Re: [PATCH] Don't define _XOPEN_SOURCE on MacOSX and FreeBSD as it is too restricting

[Marco Roeland]

On Friday December 22nd 2006 at 00:37 Junio C Hamano wrote:

> (offtopic) Yeah, but my point was that ANSI C reserves _all_
> symbols that begin with str ("Names reserved for expansion"),
> not just a specific set of functions like strcmp, strcpy, etc.,
> so if a program tries to be compliant with it, it cannot use,
> for example, strncasecmp (was that the symbol we had trouble
> with?)  for its own purpose anyway -- which means the system
> header implementation should not have to worry about namespace
> pollution.  I do not see any reason for them to hide
> strncasecmp, for example.

(ontopic for offtopic, that makes it still offtopic probably) I think
the intention from Apple might have been to provide a strict least
common denominator environment for developing software that will run
on strictly standardized POSIX standards. Think of someone that has
to develop a program on Darwin and that should also run on OS/400. If
strcasestr(3) isn't in the libraries there it might make some sense to
not make it available in this strict compatibility mode (expose no less
but also no more environment). A sort of combination of '-pedantic' with
'-Werror' as it were. Note that I do not defend it, just trying to find
some sense of logic in it. ;-)

> > On Apple compiling git works fine both with and without
> > _XOPEN_SOURCES_EXTENDED. But looking in the headers, in contrast to the
> > _XOPEN_SOURCE define which restricts functionality to some predefined
> > set, the _XOPEN_SOURCES_EXTENDED only adds functionality and doesn't
> > remove it. So I thought it might be best to keep as much symbols as
> > possible to be the same for all platforms for future expandibility.
> >
> > Probably FreeBSD behaves the same with respect to
> > _XOPEN_SOURCE_EXTENDED. Will check later today.
> 
> Ok, thanks.

Checking for compilation with FreeBSD as target should have the macro
"__FreeBSD__" as value. No other value, as already pointed out by Rocco
Rutte.

The behaviour of _XOPEN_SOURCE_EXTENDED on FreeBSD is exactly like on
Apple. This means for git we can either include it or not, it won't make
a difference.

There is a subtle and interesting difference with respect to
the usage of _XOPEN_SOURCE on FreeBSD as compared to Darwin. The only
thing that I see on FreeBSD is that it (indirectly through yet another
macro __XSI_VISIBLE) influences some functions (amongst which
strcasestr(3) in daemon.c) to be declared in the system header
<strings.h> instead of in <string.h>. The FreeBSD header claim that this
should be the POSIX behaviour for _XOPEN_SOURCE. As we do not include
<strings.h> the compilation fails on FreeBSD.

In fact on FreeBSD the problem seems to be only that when _XOPEN_SOURCE
is defined, than the macro __BSD_VISIBLE is unset or 0. Adding just

#ifdef __FreeBSD__
#define __BSD_VISIBLE   1
#endif

before setting _XOPEN_SOURCE in also results in git compiling perfectly
on FreeBSD. In that case for example <string.h> automatically includes
<strings.h>.

So on top of Terjes patch in "master":

diff --git a/git-compat-util.h b/git-compat-util.h
index 41fa7f6..2303951 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -11,6 +11,10 @@
 
 #define ARRAY_SIZE(x) (sizeof(x)/sizeof(x[0]))
 
+#ifdef __FreeBSD__
+#define __BSD_VISIBLE	1	/* needed in combination with _XOPEN_SOURCE */
+#endif
+
 #ifndef __APPLE_CC__
 #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 */
-- 
Marco Roeland

Re: [PATCH] Don't define _XOPEN_SOURCE on MacOSX and FreeBSD as it is too restricting

[Rocco Rutte]

Hi,

* Marco Roeland [06-12-22 12:47:22 +0100] wrote:

>In fact on FreeBSD the problem seems to be only that when _XOPEN_SOURCE
>is defined, than the macro __BSD_VISIBLE is unset or 0. Adding just

>#ifdef __FreeBSD__
>#define __BSD_VISIBLE   1
>#endif

The first patch I sent in did exactly that via -D__BSD_VISIBLE set in 
the Makefile and Junio correctly complained that the __-prefix is meant 
to be for internal use only. I bet he'll say the same about this flavour 
of defining __BSD_VISIBLE. :)

I was just too lazy to recursively go through the #define/#ifdef parts 
of header files to find why __BSD_VISIBLE is needed.

Second, in <sys/cdefs.h> _XOPEN_SOURCE indirectly influences 
__BSD_VISIBLE through _POSIX_C_SOURCE. The latter is defined for values 
of >=500 for _XOPEN_SOURCE so that even

   #define _XOPEN_SOURCE 499

works fine on FreeBSD.

I'm still in favour of simply adding '!defined(__FreeBSD__)' to 
git-compat-util.h as soon as possible to push out a maintaince release 
that at least compiles (on FreeBSD)...

   bye, Rocco
-- 
:wq!

Re: [PATCH] Don't define _XOPEN_SOURCE on MacOSX and FreeBSD as it is too restricting

[Marco Roeland]

On Friday December 22nd 2006 at 12:55 Rocco Rutte wrote:

> I'm still in favour of simply adding '!defined(__FreeBSD__)' to 
> git-compat-util.h as soon as possible to push out a maintaince release 
> that at least compiles (on FreeBSD)...

Agreed. It's the more practical thing to do and Just Works (TM).

Perhaps in the long run we could create platform specific header files
to deal with whatever excentricities these provide or need, and include
in git-compat-util.h things like for every candidate that needs it:

#ifdef __CrappIX__
#include "compat/crappix.h"
#endif

For the _XOPEN_SOURCE specific things it might also be better to reverse
the logic, so not exclude it for a number of platforms but only include
it for the specific platforms that seem to need it.

So, again on top of Terjes patch in "master":

diff --git a/git-compat-util.h b/git-compat-util.h
index 41fa7f6..c7930d2 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -11,7 +11,7 @@
 
 #define ARRAY_SIZE(x) (sizeof(x)/sizeof(x[0]))
 
-#ifndef __APPLE_CC__
+#if !defined(__APPLE__) && !defined(__FreeBSD__)
 #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 */
 #endif
-- 
Marco Roeland

Re: [BUG] daemon.c blows up on OSX

[Andreas Ericsson]

Junio C Hamano wrote:
> 
> Does everybody use Apple CC on OSX?  Is the symbol defined even
> with GCC?  Or Gcc fixes headers well enough and makes this a
> non-issue?
> 

Just for future reference

http://predef.sourceforge.net/preos.html

holds a pretty complete list of identifying macros for more kinds of 
systems than I've had the questionable privilege of having to work with. 
I've used it pretty extensively when trying to write portable code, 
since I too have a hard time liking autoconf and friends.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231