* What's cooking in git.git (topics)
From: Junio C Hamano @ 2006-12-20 21:21 UTC (permalink / raw)
To: git; +Cc: Eric Wong, Jakub Narebski
Here are the topics that have been cooking. Commits prefixed
with '-' are only in 'pu' while commits prefixed with '+' are
in 'next'. The topics list the commits in reverse chronological
order.
* js/rerere (Wed Dec 20 17:39:41 2006 +0100) 3 commits
- Make git-rerere a builtin
- Add a test for git-rerere
- move read_mmfile() into xdiff-interface
Rewrite of rerere in C by Johannes; this is supposed to contain
no feature change, and I should be able to merge it anytime when
it is shown to be correct. We'll see.
* jc/skip-count (Tue Dec 19 18:25:32 2006 -0800) 1 commit
+ revision: --skip=<n>
This could help gitweb, but otherwise no strong reason to merge
to 'master' yet.
* jc/leftright (Tue Dec 19 02:28:16 2006 -0800) 4 commits
+ Revert "Make left-right automatic."
+ Make left-right automatic.
+ Teach all of log family --left-right output.
+ rev-list --left-right
Since I reverted the 'automatic' bits, this is ready to be
merged to 'master'. Perhaps in v1.5.0.
* jc/fsck-reflog (Tue Dec 19 00:23:12 2006 -0800) 6 commits
- git reflog expire
- Move in_merge_bases() to commit.c
- reflog: fix warning message.
- Teach git-repack to preserve objects referred to by reflog
entries.
- Protect commits recorded in reflog from pruning.
- add for_each_reflog_ent() iterator
Because reflogs are enabled by default in end user repositories
now, this series will be needed sooner or later. The earlier
ones prevent commits lost by reset/rebase from getting pruned
while reflogs point at them, while the latter ones allow reflogs
to be pruned. Earlier parts cannot be merged without the expiry
mechanism in the later ones, because doing so would mean crufts
will accumulate not just in reflogs but in object database,
without an easy way to prune them.
* jc/clone (Tue Dec 19 01:39:07 2006 +0100) 10 commits
+ Move "no merge candidate" warning into git-pull
+ Use preprocessor constants for environment variable names.
+ Do not create $GIT_DIR/remotes/ directory anymore.
+ Introduce GIT_TEMPLATE_DIR
+ Revert "fix testsuite: make sure they use templates freshly built
from the source"
+ fix testsuite: make sure they use templates freshly built from the
source
+ git-clone: lose the traditional 'no-separate-remote' layout
+ git-clone: lose the artificial "first" fetch refspec
+ git-pull: refuse default merge without branch.*.merge
+ git-clone: use wildcard specification for tracking branches
This is to conclude the move of the default repository layout
created by git-clone to separate-remote layout. I think this is
ready and the next push would include this in the 'master'.
* jc/branch-remove-remote (Tue Dec 19 09:42:16 2006 +1100) 2 commits
+ git-branch -d: do not stop at the first failure.
+ Teach git-branch to delete tracking branches with -r -d
Will merge.
* jc/blame (Mon Dec 18 14:04:38 2006 -0800) 1 commit
+ blame: -b (blame.blankboundary) and --root (blame.showroot)
Will merge.
* jn/web (Sat Dec 16 17:12:55 2006 +0100) 1 commit
- gitweb: Add some mod_perl specific support
On hold, Jakub's call.
* 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.
* jc/git-add--interactive (Wed Dec 20 13:06:46 2006 -0800) 3 commits
. git-add: error out when given no arguments.
+ git-add --interactive: hunk splitting
+ git-add --interactive
This is a bit too young and I am not sure how useful it is in
practice. I might cherry-pick its tip to 'master' first without
adding the --interactive bits.
* jc/explain (Mon Dec 4 19:35:04 2006 -0800) 1 commit
- git-explain
Probably not in v1.5.0.
* jc/3way (Wed Nov 29 18:53:13 2006 -0800) 1 commit
+ git-merge: preserve and merge local changes when doing fast
forward
Not in v1.5.0.
* js/shallow (Fri Nov 24 16:00:13 2006 +0100) 15 commits
+ fetch-pack: Do not fetch tags for shallow clones.
+ get_shallow_commits: Avoid memory leak if a commit has been
reached already.
+ git-fetch: Reset shallow_depth before auto-following tags.
+ upload-pack: Check for NOT_SHALLOW flag before sending a shallow
to the client.
+ fetch-pack: Properly remove the shallow file when it becomes
empty.
+ shallow clone: unparse and reparse an unshallowed commit
+ Why didn't we mark want_obj as ~UNINTERESTING in the old code?
+ Why does it mean we do not have to register shallow if we have
one?
+ We should make sure that the protocol is still extensible.
+ add tests for shallow stuff
+ Shallow clone: do not ignore shallowness when following tags
+ allow deepening of a shallow repository
+ allow cloning a repository "shallowly"
+ support fetching into a shallow repository
+ upload-pack: no longer call rev-list
Post v1.5.0.
* jc/web (Wed Nov 8 14:54:09 2006 -0800) 1 commit
- gitweb: steal loadavg throttle from kernel.org
* jc/pickaxe (Sun Nov 5 11:52:43 2006 -0800) 1 commit
- blame: --show-stats for easier optimization work.
* jc/diff (Mon Sep 25 23:03:34 2006 -0700) 1 commit
- para-walk: walk n trees, index and working tree in parallel
* jc/diff-apply-patch (Fri Sep 22 16:17:58 2006 -0700) 1 commit
+ git-diff/git-apply: make diff output a bit friendlier to GNU patch
(part 2)
The above four are on hold.
^ permalink raw reply
* warning merge message
From: Luben Tuikov @ 2006-12-20 21:22 UTC (permalink / raw)
To: git
Hi,
Can we please eliminate this f@#$ing message:
Warning: No merge candidate found because value of config option
"branch.master.merge" does not match any remote branch fetched.
This message simply means:
Warning: you're not conforming to some merge policy that I've
set forth in such and such of my patches committed to git.
If the default behavior is the old, current, well established
behavior, then I see no reason for this "scary" f@#$ing message
to be printed, "warning" me of some "problem".
Thanks!
Luben
^ permalink raw reply
* Re: warning merge message
From: Luben Tuikov @ 2006-12-20 21:34 UTC (permalink / raw)
To: git
Furthermore, isn't the local origin fast forwarded to the
remote master, and then the local origin merged into the
local master and then the master checked out (presumably
the user hasn't edited contents of their master branch).
This "warning" message is confusing and the branch.<branch>.merge
config option poorly documented.
Can someone clarify these things to me please?
Thanks,
Luben
^ permalink raw reply
* Re: [PATCH] index-pack usage of mmap() is unacceptably slower on many OSes other than Linux
From: Junio C Hamano @ 2006-12-20 21:52 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jeff Garzik, Nicolas Pitre, Randal L. Schwartz, git
In-Reply-To: <Pine.LNX.4.64.0612201243490.3576@woody.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Wed, 20 Dec 2006, Junio C Hamano wrote:
>>
>> I needed to fix the changes to git-compat-util.h a bit from the
>> version I sent earlier to make OpenBSD happy (sys/types.h there
>> did not expose u_int unless _BSD_SOURCE was set, and
>> netinet/in.h was duplicated by mistake).
>
> Please don't use "u_int" in the first place. It's an abomination of a
> type. It should never be used.
I did not want to touch imported sources in compat/, but
> The only user in git seems to have been copied from a source that is
> insane. It does
>
> u_int words[NS_IN6ADDRSZ / NS_INT16SZ];
>
> which is just insane. It actually seems to want to use "uint16_t", which
> at least would make sense, and be a type that has some _point_ to it.
the above argument makes 100% sense. Will fix.
However, on sane platforms we do not even compile that file.
The problem I observed was that <include/netinet/tcp.h> on
OpenBSD uses u_int wants the source code that uses that header
file to first include <sys/types.h> to get u_int, which in turn
requires __BSD_VISIBLE to be in effect.
Unfortunately I think _BSD_SOURCE needs to stay for this reason.
^ permalink raw reply
* Re: What's in git.git (stable), and Announcing GIT 1.4.4.3
From: Randal L. Schwartz @ 2006-12-20 22:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, linux-kernel
In-Reply-To: <7vmz5ib8eu.fsf@assigned-by-dhcp.cox.net>
>>>>> "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.
^ permalink raw reply
* Re: [PATCH] index-pack usage of mmap() is unacceptably slower on many OSes other than Linux
From: Nikolai Weibull @ 2006-12-20 22:13 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Nicolas Pitre, Junio C Hamano, Randal L. Schwartz, git
In-Reply-To: <Pine.LNX.4.64.0612191148270.3483@woody.osdl.org>
On 12/19/06, Linus Torvalds <torvalds@osdl.org> wrote:
> It's the C++ people who tend to have sucky compile times.
Always looking for a way to bash on C++, eh?
^ permalink raw reply
* Re: What's in git.git (stable), and Announcing GIT 1.4.4.3
From: Linus Torvalds @ 2006-12-20 22:14 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: Junio C Hamano, git, linux-kernel
In-Reply-To: <86vek6z0k2.fsf@blue.stonehenge.com>
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.
^ permalink raw reply
* Re: What's in git.git (stable), and Announcing GIT 1.4.4.3
From: Junio C Hamano @ 2006-12-20 22:17 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git
In-Reply-To: <86vek6z0k2.fsf@blue.stonehenge.com>
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.
^ permalink raw reply
* Re: What's in git.git (stable), and Announcing GIT 1.4.4.3
From: Nicolas Pitre @ 2006-12-20 22:19 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: Junio C Hamano, git, linux-kernel
In-Reply-To: <86vek6z0k2.fsf@blue.stonehenge.com>
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.
^ permalink raw reply
* [BUG] daemon.c blows up on OSX (was Re: What's in git.git (stable), and Announcing GIT 1.4.4.3)
From: Randal L. Schwartz @ 2006-12-20 22:20 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:
>> 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.
^ permalink raw reply
* Re: [BUG] daemon.c blows up on OSX
From: Junio C Hamano @ 2006-12-20 22:25 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: Junio C Hamano, git, linux-kernel
In-Reply-To: <86irg6yzt1.fsf_-_@blue.stonehenge.com>
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>
^ permalink raw reply
* Re: GIT - error: no such remote ref refs/heads/TestBranch
From: Carl Worth @ 2006-12-20 22:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v64c7pmlw.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 965 bytes --]
On Tue, 19 Dec 2006 14:06:03 -0800, Junio C Hamano wrote:
> "Sean Kelley" <sean.v.kelley@gmail.com> writes:
> > error: no such remote ref refs/heads/TestBranch
> > Fetch failure: git+ssh://git.example.com/data/git/proj/kernel/mh.git
> > kelleys@oifig:~/Work/kernel$
> >
> > Any ideas how to correct this?
>
> If you know remote does not have it, then probably not fetching
> from it would be a good idea.
I think a common case is just wanting to track the upstream contents,
whether branches appear or disappear, and being able to do that
without manually maintaining a local configuration file listing the
current remote branches.
Presumably the recently added globbing support would provide that
ability, correct?
Is there any plan to make git-clone take advantage of this capability
so that one can track an upstream that has branches that get
added/remove without having to learn how to manually maintain the
current list of branches in .git/config ?
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [BUG] daemon.c blows up on OSX
From: Randal L. Schwartz @ 2006-12-20 22:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, linux-kernel
In-Reply-To: <7vr6uu6w8e.fsf@assigned-by-dhcp.cox.net>
>>>>> "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.
^ permalink raw reply
* Re: GIT - error: no such remote ref refs/heads/TestBranch
From: Junio C Hamano @ 2006-12-20 22:36 UTC (permalink / raw)
To: Carl Worth; +Cc: git
In-Reply-To: <87wt4m2o99.wl%cworth@cworth.org>
Carl Worth <cworth@cworth.org> writes:
> Is there any plan to make git-clone take advantage of this capability
> so that one can track an upstream that has branches that get
> added/remove without having to learn how to manually maintain the
> current list of branches in .git/config ?
Could you check "log master..next" and see if you like what has
been cooking, please?
The next batch of 'master' updates will have jc/clone topic (see
the latest issue of "What's cooking" message on the list) which
will include what has been cooking in 'next' around this area.
^ permalink raw reply
* Re: [BUG] daemon.c blows up on OSX
From: Junio C Hamano @ 2006-12-20 22:44 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git, linux-kernel
In-Reply-To: <86ejquyz4v.fsf@blue.stonehenge.com>
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.
^ permalink raw reply
* Re: [BUG] daemon.c blows up on OSX
From: Randal L. Schwartz @ 2006-12-20 22:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, linux-kernel
In-Reply-To: <86ejquyz4v.fsf@blue.stonehenge.com>
[-- 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!
^ permalink raw reply related
* UI nitpick
From: Han-Wen Nienhuys @ 2006-12-20 22:55 UTC (permalink / raw)
To: git
Hi,
git-reset is really neat when you messed something up, but it
spews messages.
[lilydev@haring lilypond]$ git-reset HEAD
lily/accidental-engraver.cc: needs update
lily/lyric-combine-music-iterator.cc: needs update
this makes me think that the reset was unsuccesful.
After a few more experiments with
git-reset <stuff> HEAD^
I started noticing that the list grew longer and longer.
It would be nice if git-reset printed
HEAD is now <sha1> - <excerpt of commit message>
--
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
^ permalink raw reply
* Re: GIT - error: no such remote ref refs/heads/TestBranch
From: Carl Worth @ 2006-12-20 22:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmz5i6vqb.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 1229 bytes --]
On Wed, 20 Dec 2006 14:36:12 -0800, Junio C Hamano wrote:
> Carl Worth <cworth@cworth.org> writes:
>
> > Is there any plan to make git-clone take advantage of this capability
> > so that one can track an upstream that has branches that get
> > added/remove without having to learn how to manually maintain the
> > current list of branches in .git/config ?
>
> Could you check "log master..next" and see if you like what has
> been cooking, please?
Oh, yes, there it is. (I had skimmed the log for master..next but had
missed it---I guess that I also searched for "glob" instead of
"wildcard" didn't help).
Anyway, yes, the description of the new stuff there looks very
interesting, and I'll maybe I'll start running from next a bit to see
how this stuff all works.
I guess the big reason I wrote was that I was surprised to see your
reply instructing Sean on how to update the config file without also
saying something like, "by the way, this need to update the config
file like this will be going away with new work on git-clone that is
being done now and is expected to be in the upcoming git 1.5".
I thought that was the case, but didn't want to say it without
confirming it first. Thanks for confirming it for me.
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [BUG] daemon.c blows up on OSX
From: Junio C Hamano @ 2006-12-20 23:03 UTC (permalink / raw)
To: git
In-Reply-To: <86ac1iyyla.fsf@blue.stonehenge.com>
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).
^ permalink raw reply
* Re: [BUG] daemon.c blows up on OSX
From: Linus Torvalds @ 2006-12-20 23:07 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: Junio C Hamano, git, linux-kernel
In-Reply-To: <86ac1iyyla.fsf@blue.stonehenge.com>
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?
^ permalink raw reply
* Re: [BUG] daemon.c blows up on OSX
From: Randal L. Schwartz @ 2006-12-20 23:17 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git, linux-kernel
In-Reply-To: <Pine.LNX.4.64.0612201502090.3576@woody.osdl.org>
>>>>> "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.
^ permalink raw reply
* Re: [BUG] daemon.c blows up on OSX
From: Junio C Hamano @ 2006-12-20 23:30 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: Junio C Hamano, git, linux-kernel
In-Reply-To: <86wt4mximh.fsf@blue.stonehenge.com>
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.
^ permalink raw reply
* Re: GIT - error: no such remote ref refs/heads/TestBranch
From: Junio C Hamano @ 2006-12-20 23:36 UTC (permalink / raw)
To: Carl Worth; +Cc: git
In-Reply-To: <87vek62n1k.wl%cworth@cworth.org>
Carl Worth <cworth@cworth.org> writes:
> Anyway, yes, the description of the new stuff there looks very
> interesting, and I'll maybe I'll start running from next a bit to see
> how this stuff all works.
Good.
Do you have comments on recent changes (both on 'master' and
some parts of 'next') from teachability point of view? I think
you are "the guilty guy" who defined the theme for v1.5.0 to be
"usability and teachability" ;-).
^ permalink raw reply
* Re: [BUG] daemon.c blows up on OSX
From: Linus Torvalds @ 2006-12-20 23:41 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: Junio C Hamano, git, linux-kernel
In-Reply-To: <86wt4mximh.fsf@blue.stonehenge.com>
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>
^ permalink raw reply related
* 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
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