* Re: What's cooking in git.git (topics)
From: Eric Wong @ 2006-12-20 23:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Sam Vilain
In-Reply-To: <7vejqu8dqv.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> * ew/svn-pm (Fri Dec 15 23:58:08 2006 -0800) 3 commits
> + git-svn: rename 'commit' command to 'set-tree'
> + git-svn: remove support for the svn command-line client
> + git-svn: convert to using Git.pm
>
> I've heard a few comments that renaming 'commit' to 'set-tree'
> are received favorably by users, so this might be ready to be
> merged. Eric's call, but I am not in the rush.
Yes, please merge these for 1.5.0. I have more on the way that depend
on these patches. The coming changes to git-svn should make life easier
for Sam's svm/svk patches, too.
--
^ permalink raw reply
* git-svn throwing assertion on old svn tracking branch
From: Nicolas Vilz @ 2006-12-20 23:55 UTC (permalink / raw)
To: git
hello guys,
it has been a while, i tried git in conjunction with svn... i got a nice
history, when working with it. This Work is now a year old.
Now I wanted to get on working and got following error message while
fetching from one specific svn tracking branch:
$ git-svn fetch -i svn_master
perl: subversion/libsvn_subr/path.c:343: svn_path_remove_component:
Assertion `is_canonical(path->data, path->len)' failed.
Aborted
I checked the svn working copy, it is uptodate now (although i had to
search for it, i havent been using this repository for one year...)
the output of gitk --all looks good, too. So i wonder if that error
message above is only an alternative to say "more work? i ask because i
am finished and have nothing else todo.."
It is only happening to this old repository...
Any help is appreciated. If possible, i would like to keep my development
history for this repository.
I almost forgot, i use git version 1.4.4.3.g545b
Sincerly
Nicolas
^ permalink raw reply
* Re: [BUG] daemon.c blows up on OSX
From: Terje Sten Bjerkseth @ 2006-12-21 0:36 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: Linus Torvalds, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0612201524230.3576@woody.osdl.org>
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
^ permalink raw reply related
* [ANNOUNCE] cgit 0.1
From: Lars Hjemli @ 2006-12-21 0:37 UTC (permalink / raw)
To: Git Mailing List
cgit - cgi for git, running on libgit.a
I've pushed out a rather usable release of cgit, available for cloning at
git://hjemli.net/pub/git/cgit
and for (re)viewing at
http://hjemli.net/git/cgit/
Current features:
Page cache
Repository listing
Branch listing
Log view
Commit view
File diff view
Tree view
Blob view
Todo:
Tag list
Snapshots
Usability
Enjoy!
--
^ permalink raw reply
* Re: [BUG] daemon.c blows up on OSX
From: Junio C Hamano @ 2006-12-21 0:44 UTC (permalink / raw)
To: Terje Sten Bjerkseth; +Cc: Linus Torvalds, Junio C Hamano, git
In-Reply-To: <caf068570612201636g75180138r223aef7c42f69a50@mail.gmail.com>
"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?
^ permalink raw reply
* Re: [BUG] daemon.c blows up on OSX
From: Linus Torvalds @ 2006-12-21 0:44 UTC (permalink / raw)
To: Terje Sten Bjerkseth; +Cc: Randal L. Schwartz, Junio C Hamano, git
In-Reply-To: <caf068570612201636g75180138r223aef7c42f69a50@mail.gmail.com>
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.
^ permalink raw reply
* Re: [BUG] daemon.c blows up on OSX
From: Terje Sten Bjerkseth @ 2006-12-21 0:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git
In-Reply-To: <7vtzzq3wo6.fsf@assigned-by-dhcp.cox.net>
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
^ permalink raw reply
* Re: [BUG] daemon.c blows up on OSX
From: Junio C Hamano @ 2006-12-21 1:00 UTC (permalink / raw)
To: Terje Sten Bjerkseth; +Cc: Linus Torvalds, git
In-Reply-To: <caf068570612201654s3949202cl55bd21307ca59453@mail.gmail.com>
"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.
^ permalink raw reply
* Re: [BUG] daemon.c blows up on OSX
From: Brian Gernhardt @ 2006-12-21 0:56 UTC (permalink / raw)
To: Junio C Hamano
(I originally forgot to send this to the list. Oops. Difference
between "Reply" and "Reply All" is small, but important.)
On Dec 20, 2006, at 7:44 PM, 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?
Apple CC == gcc, as far as I can tell. And the definition of
_POSIX_C_SOURCE, which seems to disable too much stuff, is in /usr/
include/sys/cdefs.h:
/* 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
Why _POSIX_C_SOURCE disables strncasecmp, I don't know. It makes me
sad.
Yours,
^ permalink raw reply
* Re: git-svn throwing assertion on old svn tracking branch
From: Eric Wong @ 2006-12-21 1:05 UTC (permalink / raw)
To: Nicolas Vilz; +Cc: git
In-Reply-To: <20061220235551.GA2974@hermes.lan.home.vilz.de>
Nicolas Vilz <niv@iaglans.de> wrote:
> hello guys,
>
> it has been a while, i tried git in conjunction with svn... i got a nice
> history, when working with it. This Work is now a year old.
>
> Now I wanted to get on working and got following error message while
> fetching from one specific svn tracking branch:
>
> $ git-svn fetch -i svn_master
> perl: subversion/libsvn_subr/path.c:343: svn_path_remove_component:
> Assertion `is_canonical(path->data, path->len)' failed.
> Aborted
I don't recall seeing that error before.
Are you using the command-line client or the perl SVN libraries? If
you're using the command-line client, you may want to try:
rm -rf .git/svn/svn_master/tree && git-svn rebuild -i svn_master
> I checked the svn working copy, it is uptodate now (although i had to
> search for it, i havent been using this repository for one year...)
Does the directory you're tracking the the repository still
exist? If it disappeared, git-svn could have some issues with it
(regardless of command-line or SVN libraries).
--
^ permalink raw reply
* Re: [BUG] daemon.c blows up on OSX
From: Randal L. Schwartz @ 2006-12-21 1:07 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Terje Sten Bjerkseth, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0612201643520.3576@woody.osdl.org>
>>>>> "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.
^ permalink raw reply
* Re: [BUG] daemon.c blows up on OSX
From: Randal L. Schwartz @ 2006-12-21 1:08 UTC (permalink / raw)
To: Terje Sten Bjerkseth; +Cc: Linus Torvalds, Junio C Hamano, git
In-Reply-To: <caf068570612201636g75180138r223aef7c42f69a50@mail.gmail.com>
>>>>> "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.
^ permalink raw reply
* Re: [BUG] daemon.c blows up on OSX
From: Junio C Hamano @ 2006-12-21 1:13 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: Terje Sten Bjerkseth, Junio C Hamano, git
In-Reply-To: <86ac1ixdic.fsf@blue.stonehenge.com>
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?
^ permalink raw reply
* Re: [BUG] daemon.c blows up on OSX
From: Randal L. Schwartz @ 2006-12-20 23:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1wmu6ugr.fsf@assigned-by-dhcp.cox.net>
>>>>> "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.
^ permalink raw reply
* Re: [BUG] daemon.c blows up on OSX
From: Randal L. Schwartz @ 2006-12-21 1:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Terje Sten Bjerkseth, Linus Torvalds, git
In-Reply-To: <7vodpy3vxi.fsf@assigned-by-dhcp.cox.net>
>>>>> "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.
^ permalink raw reply
* Re: [BUG] daemon.c blows up on OSX
From: Junio C Hamano @ 2006-12-21 1:29 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git
In-Reply-To: <86vek6vyc7.fsf@blue.stonehenge.com>
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.
^ permalink raw reply
* Re: [BUG] daemon.c blows up on OSX
From: Terje Sten Bjerkseth @ 2006-12-21 1:35 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: Junio C Hamano, Linus Torvalds, git
In-Reply-To: <86vek6vyc7.fsf@blue.stonehenge.com>
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.)
^ permalink raw reply
* Re: [BUG] daemon.c blows up on OSX
From: Randal L. Schwartz @ 2006-12-21 1:35 UTC (permalink / raw)
To: Brian Gernhardt; +Cc: Terje Sten Bjerkseth, Linus Torvalds, Junio C Hamano, git
In-Reply-To: <24BF45E9-DD98-4609-9D65-B01EAA30CCA8@silverinsanity.com>
[-- 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
^ permalink raw reply related
* Re: [BUG] daemon.c blows up on OSX
From: Junio C Hamano @ 2006-12-21 1:48 UTC (permalink / raw)
To: Randal L. Schwartz
Cc: Terje Sten Bjerkseth, Linus Torvalds, Junio C Hamano, git
In-Reply-To: <86psaevxo3.fsf@blue.stonehenge.com>
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
^ permalink raw reply
* Re: [BUG] daemon.c blows up on OSX
From: Randal L. Schwartz @ 2006-12-21 1:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Terje Sten Bjerkseth, Linus Torvalds, git
In-Reply-To: <7v64c63tol.fsf@assigned-by-dhcp.cox.net>
>>>>> "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!
^ permalink raw reply
* Re: [BUG] daemon.c blows up on OSX
From: Randal L. Schwartz @ 2006-12-20 23:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <86r6uuxi8o.fsf@blue.stonehenge.com>
>>>>> "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!
^ permalink raw reply
* Re: What's in git.git (stable), and Announcing GIT 1.4.4.3
From: Randal L. Schwartz @ 2006-12-20 23:58 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git, linux-kernel
In-Reply-To: <Pine.LNX.4.64.0612201412250.3576@woody.osdl.org>
>>>>> "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!
^ permalink raw reply
* Re: [BUG] daemon.c blows up on OSX
From: Junio C Hamano @ 2006-12-21 1:57 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: Terje Sten Bjerkseth, Linus Torvalds, git
In-Reply-To: <86hcvqvwyd.fsf@blue.stonehenge.com>
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".
^ permalink raw reply
* Re: Re: [BUG] daemon.c blows up on OSX
From: Stefan Pfetzing @ 2006-12-21 2:04 UTC (permalink / raw)
To: git
In-Reply-To: <86irg6xht8.fsf@blue.stonehenge.com>
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.
^ permalink raw reply
* Re: [BUG] daemon.c blows up on OSX
From: Albert Cahalan @ 2006-12-21 2:52 UTC (permalink / raw)
To: junkio, merlyn, git, linux-kernel
Linus Torvalds writes:
> 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.
Yes, of course. The odd one here is glibc.
Normal systems enable everything by default. As soon as you
specify a feature define, you get ONLY what you asked for.
I'm not sure why glibc is broken, but I suspect that somebody
wants to make everyone declare their code to be GNU source.
(despite many "GNU" things not working on the HURD at all)
Define _APPLE_C_SOURCE to make MacOS X give you everything.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox