* Re: [PATCH] Trivial warning fix for imap-send.c
From: A Large Angry SCM @ 2006-03-12 19:20 UTC (permalink / raw)
To: Mark Wooding; +Cc: git
In-Reply-To: <slrne18of5.fr9.mdw@metalzone.distorted.org.uk>
Mark Wooding wrote:
> Linus Torvalds <torvalds@osdl.org> wrote:
>
>>So in modern C, using NULL at the end of a varargs array as a pointer is
>>perfectly sane, and the extra cast is just ugly and bowing to bad
>>programming practices and makes no sense to anybody who never saw the
>>horror that is K&R.
>
> No! You can still get bitten. You're lucky that on common platforms
> all pointers look the same, but if you find one where `char *' (and
> hence `void *') isn't the same as `struct foo *' then, under appropriate
> circumstances you /will/ unless you put the casts in.
Please explain how malloc() can work on such a platform. My reading of
the '89 ANSI C spec. finds that _ALL_ (non function) pointers _are_
cast-able to/from a void * and that NULL should be #defined as (void *).
See 3.2.2.3 and 4.1.5 if interested.
^ permalink raw reply
* Re: [BUG] imap-send.c fails to build on OSX
From: Randal L. Schwartz @ 2006-03-12 19:08 UTC (permalink / raw)
To: git
In-Reply-To: <863bhnlo3r.fsf@blue.stonehenge.com>
>>>>> "Randal" == Randal L Schwartz <merlyn@stonehenge.com> writes:
Randal> gcc -o imap-send.o -c -g -O2 -Wall -I/sw/include -I/opt/local/include -DSHA1_HEADER='<openssl/sha.h>' imap-send.c
Randal> imap-send.c:376: error: static declaration of 'vasprintf' follows non-static declaration
Randal> /usr/include/stdio.h:297: error: previous declaration of 'vasprintf' was here
Randal> make: *** [imap-send.o] Error 1
By the way, /usr/include/stdio.h near the line in question looks like:
int vasprintf(char **, const char *, va_list) __DARWIN_LDBL_COMPAT(vasprintf);
--
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: [PATCH] Use explicit pointers for execl...() sentinels.
From: Timo Hirvonen @ 2006-03-12 18:08 UTC (permalink / raw)
To: git; +Cc: git
In-Reply-To: <slrne18mq3.fr9.mdw@metalzone.distorted.org.uk>
On Sun, 12 Mar 2006 17:32:51 +0000 (UTC)
Mark Wooding <mdw@distorted.org.uk> wrote:
> Besides, (void *)0 fixes /this particular/ problem, because `void *' and
> `char *' have the same representation (6.2.5#27). This wouldn't help us
> with a putative function which takes an arbitrary number of `foo *'
> pointers, since nothing guarantees that `void *' and `foo *' have
> similar representations. You'd have to say `(foo *)0' or `(foo *)NULL'.
NULL pointer does not point to any data, it just says it's 'empty'. So
it doesn't need to be same type pointer as specified in the function
prototype. Pointers are just addresses, it doesn't matter from to code
generation point of view whether it is (char *)0 or (void *)0.
> Don't know: didn't look. 0L won't do the right thing with IL32LLP64, if
> anyone was actually crazy enough to specify such an ABI. The point is,
> there's not much
sizeof(unsigned long) is sizeof(void *) in real world.
> > How about fixing those systems instead of making the git source code
> > unreadable.
>
> Because, according to the C and POSIX specs, they're not wrong.
They didn't think of 64-bit architectures back then, I suppose.
> The right fix from the point of view of a C implementation would be to
> define NULL to be some weird __null_pointer token which the compiler
> could warn about whenever it was used in an untyped argument context.
In practice (void *)0 is good enough.
> (Besides, I don't find bare or casted `0' unreadable. Maybe I'm just
> strange.)
'ugly' would have been better word than 'unreadable'.
--
http://onion.dynserv.net/~timo/
^ permalink raw reply
* Re: [PATCH] Trivial warning fix for imap-send.c
From: Mark Wooding @ 2006-03-12 18:01 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0603120847500.3618@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> wrote:
> So in modern C, using NULL at the end of a varargs array as a pointer is
> perfectly sane, and the extra cast is just ugly and bowing to bad
> programming practices and makes no sense to anybody who never saw the
> horror that is K&R.
No! You can still get bitten. You're lucky that on common platforms
all pointers look the same, but if you find one where `char *' (and
hence `void *') isn't the same as `struct foo *' then, under appropriate
circumstances you /will/ unless you put the casts in.
Now, maybe we don't care for GIT. That's your (and Junio's) call. My
natural approach is to work as closely as I can to the specs (and then
throw in hacks for platforms which /still/ don't work), though, which is
why I brought the subject up.
-- [mdw]
^ permalink raw reply
* Re: [PATCH] Use explicit pointers for execl...() sentinels.
From: Mark Wooding @ 2006-03-12 17:32 UTC (permalink / raw)
To: git
In-Reply-To: <20060312171316.39d138f8.tihirvon@gmail.com>
Timo Hirvonen <tihirvon@gmail.com> wrote:
> NULL should always be ((void *)0).
Says who? I already gave chapter and verse for what NULL is required to
do.
Besides, (void *)0 fixes /this particular/ problem, because `void *' and
`char *' have the same representation (6.2.5#27). This wouldn't help us
with a putative function which takes an arbitrary number of `foo *'
pointers, since nothing guarantees that `void *' and `foo *' have
similar representations. You'd have to say `(foo *)0' or `(foo *)NULL'.
> What 64-bit systems declare NULL as plain 0 (not 0L)?
Don't know: didn't look. 0L won't do the right thing with IL32LLP64, if
anyone was actually crazy enough to specify such an ABI. The point is,
there's not much
> How about fixing those systems instead of making the git source code
> unreadable.
Because, according to the C and POSIX specs, they're not wrong.
The right fix from the point of view of a C implementation would be to
define NULL to be some weird __null_pointer token which the compiler
could warn about whenever it was used in an untyped argument context.
(Besides, I don't find bare or casted `0' unreadable. Maybe I'm just
strange.)
-- [mdw]
^ permalink raw reply
* Re: git-diff-tree -M performance regression in 'next'
From: Linus Torvalds @ 2006-03-12 17:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Fredrik Kuivinen, git
In-Reply-To: <7voe0bdeyr.fsf@assigned-by-dhcp.cox.net>
On Sun, 12 Mar 2006, Junio C Hamano wrote:
>
> On my otherwise idle Duron 750 with slow disks, I am getting
> something like these:
>
> 0.99.9m : 130m virtual, 40m resident, (0major+14205minor)
> 67.62user 0.08system 1:15.95elapsed
> master : 130m virtual, 40m resident, (0major+12510minor)
> 66.06user 0.07system 1:10.95elapsed
> "next" : 150m virtual, 65m resident, (0major+49858minor)
> 51.41user 0.45system 0.57.55elapsed
Any way to fix that "4 times as many page misses, and 70% bigger rss?"
thing? It looks like you're not very careful about your memory use.
I realize that git in general wants a lot of memory, but I see that as a
failure most of the time. I've got 2GB in most of my machines, but I
shouldn't _need_ to have it..
Linus
^ permalink raw reply
* Re: [PATCH] Trivial warning fix for imap-send.c
From: Linus Torvalds @ 2006-03-12 16:57 UTC (permalink / raw)
To: Mark Wooding; +Cc: git
In-Reply-To: <slrne17urp.fr9.mdw@metalzone.distorted.org.uk>
On Sun, 12 Mar 2006, Mark Wooding wrote:
> "Art Haas" <ahaas@airmail.net> wrote:
>
> > - execl( "/bin/sh", "sh", "-c", srvc->tunnel, 0 );
> > + execl( "/bin/sh", "sh", "-c", srvc->tunnel, NULL );
>
> This is not the right fix. NULL can be simply a #define for 0 (see
> 6.3.2.3#3 and 7.17). You need to write (char *)0 or (char *)NULL. I
> prefer to avoid the macro NULL entirely, since its misleading behaviour
> is precisely what got us into this mess.
It's perfectly fine.
Quite frankly, if you have a 64-bit C compiler that doesn't make "NULL" be
"((void *)0)" (or equivalent - some compilers will actually have NULL as
an intrisic, because especially if they also support C++, NULL has some
really magical properties there), you should switch vendors as quickly as
humanly possible.
The "#define NULL 0" practice is still _legal_ C, but that doesn't make it
any less broken. It's K&R traditional, but git requires ANSI prototypes
and some fancy features from modern compilers, so K&R compilers aren't
welcome anyway, and if their headers don't define NULL as a void pointer,
their headers are simply _broken_.
So in modern C, using NULL at the end of a varargs array as a pointer is
perfectly sane, and the extra cast is just ugly and bowing to bad
programming practices and makes no sense to anybody who never saw the
horror that is K&R.
It's akin to trying to not using prototypes, or to trying to limit your
externally visible names to 7 characters. It was "appropriate" about two
decades ago, these days it's just cuddling broken setups that have been
broken for a long long time.
Btw, the reason NULL _has_ to be a pointer ("((void *)0)" or otherwise) is
simply that if it isn't, you not only won't get reasonable varargs
behaviour, you'll also miss real warnings. I've seen broken code like
int i = NULL;
in my life, and if the compiler doesn't warn about that, then the compiler
is BROKEN, and not worth supporting as a programmer.
Linus
^ permalink raw reply
* Re: [PATCH] Use explicit pointers for execl...() sentinels.
From: Timo Hirvonen @ 2006-03-12 15:13 UTC (permalink / raw)
To: git; +Cc: git
In-Reply-To: <slrne18aae.fr9.mdw@metalzone.distorted.org.uk>
On Sun, 12 Mar 2006 13:59:42 +0000 (UTC)
Mark Wooding <mdw@distorted.org.uk> wrote:
> A terminator of `0' (or `NULL', which might well expand to `0') gets
> passed as type `int' in the absence of argument type declarations (which
> is the case for execl...(), since it uses varargs). Argument passing
> conventions may differ between `int' and `char *' if, say, `int' is 32
> bits and pointers a 64; and there's no particular guarantee that a null
> pointer has all-bits-zero anyway.
NULL should always be ((void *)0). What 64-bit systems declare NULL as
plain 0 (not 0L)? How about fixing those systems instead of making the
git source code unreadable.
--
http://onion.dynserv.net/~timo/
^ permalink raw reply
* [BUG] imap-send.c fails to build on OSX
From: Randal L. Schwartz @ 2006-03-12 14:44 UTC (permalink / raw)
To: git
gcc -o imap-send.o -c -g -O2 -Wall -I/sw/include -I/opt/local/include -DSHA1_HEADER='<openssl/sha.h>' imap-send.c
imap-send.c:376: error: static declaration of 'vasprintf' follows non-static declaration
/usr/include/stdio.h:297: error: previous declaration of 'vasprintf' was here
make: *** [imap-send.o] Error 1
--
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
* Possible --remove-empty bug
From: Marco Costalba @ 2006-03-12 14:12 UTC (permalink / raw)
To: junkio; +Cc: git
>From today git:
$ git-rev-parse HEAD
be767c91724275c4534965c0d25c452b76057602
$ git-rev-list be767c91724275c4534965c0d25c452b76057602 -- imap-send.c
f2561fda364ad984ef1441a80c90b0ee04f1a7c4
$ git-rev-list --remove-empty be767c91724275c4534965c0d25c452b76057602
-- imap-send.c
$
>From git-rev-list documentation:
--remove-empty::
Stop when a given path disappears from the tree.
But isn't it to be intended *after* a path disapperas from the tree?
In this case I would expect to see revision
f2561fda364ad984ef1441a80c90b0ee04f1a7c4 also with --remove-empty
option.
BTW rev f2561fda364ad984ef1441a80c90b0ee04f1a7c4 is the 'Add
git-imap-send, derived from isync 1.0.1.' patch.
Thanks
Marco
^ permalink raw reply
* [PATCH] annotate-tests: override VISUAL when running tests.
From: Mark Wooding @ 2006-03-12 14:00 UTC (permalink / raw)
To: git
From: Mark Wooding <mdw@distorted.org.uk>
The tests hang for me waiting for Emacs with its output directed
somewhere strage, because I hedged my bets and set both EDITOR and
VISUAL to run Emacs.
Signed-off-by: Mark Wooding <mdw@distorted.org.uk>
---
t/annotate-tests.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/t/annotate-tests.sh b/t/annotate-tests.sh
index 9c5a15a..114938c 100644
--- a/t/annotate-tests.sh
+++ b/t/annotate-tests.sh
@@ -94,7 +94,7 @@ test_expect_success \
test_expect_success \
'merge-setup part 4' \
'echo "evil merge." >>file &&
- EDITOR=: git commit -a --amend'
+ EDITOR=: VISUAL=: git commit -a --amend'
test_expect_success \
'Two lines blamed on A, one on B, two on B1, one on B2, one on A U Thor' \
^ permalink raw reply related
* [PATCH] Use explicit pointers for execl...() sentinels.
From: Mark Wooding @ 2006-03-12 13:59 UTC (permalink / raw)
To: git
In-Reply-To: <7v7j6zgaxx.fsf@assigned-by-dhcp.cox.net>
A terminator of `0' (or `NULL', which might well expand to `0') gets
passed as type `int' in the absence of argument type declarations (which
is the case for execl...(), since it uses varargs). Argument passing
conventions may differ between `int' and `char *' if, say, `int' is 32
bits and pointers a 64; and there's no particular guarantee that a null
pointer has all-bits-zero anyway.
Signed-off-by: Mark Wooding <mdw@distorted.org.uk>
---
Junio C Hamano <junkio@cox.net> wrote:
> Patches welcome. We have about 15 or so such instances.
So we do! ;-)
---
cat-file.c | 2 +-
connect.c | 6 +++---
daemon.c | 2 +-
fetch-clone.c | 4 ++--
git.c | 2 +-
imap-send.c | 2 +-
merge-index.c | 2 +-
| 2 +-
rsh.c | 2 +-
upload-pack.c | 2 +-
10 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/cat-file.c b/cat-file.c
index 1a613f3..6310787 100644
--- a/cat-file.c
+++ b/cat-file.c
@@ -136,7 +136,7 @@ int main(int argc, char **argv)
/* custom pretty-print here */
if (!strcmp(type, "tree"))
- return execl_git_cmd("ls-tree", argv[2], NULL);
+ return execl_git_cmd("ls-tree", argv[2], (char*)0);
buf = read_sha1_file(sha1, type, &size);
if (!buf)
diff --git a/connect.c b/connect.c
index 3f2d65c..a86a111 100644
--- a/connect.c
+++ b/connect.c
@@ -544,7 +544,7 @@ static int git_proxy_connect(int fd[2],
close(pipefd[0][1]);
close(pipefd[1][0]);
close(pipefd[1][1]);
- execlp(git_proxy_command, git_proxy_command, host, port, NULL);
+ execlp(git_proxy_command, git_proxy_command, host, port, (char *)0);
die("exec failed");
}
fd[0] = pipefd[0][0];
@@ -643,7 +643,7 @@ int git_connect(int fd[2], char *url, co
ssh_basename = ssh;
else
ssh_basename++;
- execlp(ssh, ssh_basename, host, command, NULL);
+ execlp(ssh, ssh_basename, host, command, (char *)0);
}
else {
unsetenv(ALTERNATE_DB_ENVIRONMENT);
@@ -651,7 +651,7 @@ int git_connect(int fd[2], char *url, co
unsetenv(GIT_DIR_ENVIRONMENT);
unsetenv(GRAFT_ENVIRONMENT);
unsetenv(INDEX_ENVIRONMENT);
- execlp("sh", "sh", "-c", command, NULL);
+ execlp("sh", "sh", "-c", command, (char *)0);
}
die("exec failed");
}
diff --git a/daemon.c b/daemon.c
index a1ccda3..13d3974 100644
--- a/daemon.c
+++ b/daemon.c
@@ -260,7 +260,7 @@ static int upload(char *dir)
snprintf(timeout_buf, sizeof timeout_buf, "--timeout=%u", timeout);
/* git-upload-pack only ever reads stuff, so this is safe */
- execl_git_cmd("upload-pack", "--strict", timeout_buf, ".", NULL);
+ execl_git_cmd("upload-pack", "--strict", timeout_buf, ".", (char *)0);
return -1;
}
diff --git a/fetch-clone.c b/fetch-clone.c
index da1b3ff..14a1cdf 100644
--- a/fetch-clone.c
+++ b/fetch-clone.c
@@ -29,7 +29,7 @@ static int finish_pack(const char *pack_
dup2(pipe_fd[1], 1);
close(pipe_fd[0]);
close(pipe_fd[1]);
- execl_git_cmd("index-pack", "-o", idx, pack_tmp_name, NULL);
+ execl_git_cmd("index-pack", "-o", idx, pack_tmp_name, (char *)0);
error("cannot exec git-index-pack <%s> <%s>",
idx, pack_tmp_name);
exit(1);
@@ -106,7 +106,7 @@ int receive_unpack_pack(int fd[2], const
dup2(fd[0], 0);
close(fd[0]);
close(fd[1]);
- execl_git_cmd("unpack-objects", quiet ? "-q" : NULL, NULL);
+ execl_git_cmd("unpack-objects", quiet ? "-q" : (char *)0, (char *)0);
die("git-unpack-objects exec failed");
}
close(fd[0]);
diff --git a/git.c b/git.c
index 0b40e30..8dd7933 100644
--- a/git.c
+++ b/git.c
@@ -253,7 +253,7 @@ static void show_man_page(const char *gi
page = p;
}
- execlp("man", "man", page, NULL);
+ execlp("man", "man", page, (char *)0);
}
static int cmd_version(int argc, const char **argv, char **envp)
diff --git a/imap-send.c b/imap-send.c
index 1b38b3a..825a5cf 100644
--- a/imap-send.c
+++ b/imap-send.c
@@ -946,7 +946,7 @@ imap_open_store( imap_server_conf_t *srv
_exit( 127 );
close( a[0] );
close( a[1] );
- execl( "/bin/sh", "sh", "-c", srvc->tunnel, NULL );
+ execl( "/bin/sh", "sh", "-c", srvc->tunnel, (char *)0);
_exit( 127 );
}
diff --git a/merge-index.c b/merge-index.c
index 024196e..24d4b62 100644
--- a/merge-index.c
+++ b/merge-index.c
@@ -23,7 +23,7 @@ static void run_program(void)
arguments[5],
arguments[6],
arguments[7],
- NULL);
+ (char *)0);
die("unable to execute '%s'", pgm);
}
if (waitpid(pid, &status, 0) < 0 || !WIFEXITED(status) || WEXITSTATUS(status)) {
--git a/pager.c b/pager.c
index 1364e15..9da76ac 100644
--- a/pager.c
+++ b/pager.c
@@ -11,7 +11,7 @@ static void run_pager(void)
if (!prog)
prog = "less";
setenv("LESS", "-S", 0);
- execlp(prog, prog, NULL);
+ execlp(prog, prog, (char *)0);
}
void setup_pager(void)
diff --git a/rsh.c b/rsh.c
index d665269..92ace2f 100644
--- a/rsh.c
+++ b/rsh.c
@@ -103,7 +103,7 @@ int setup_connection(int *fd_in, int *fd
close(sv[1]);
dup2(sv[0], 0);
dup2(sv[0], 1);
- execlp(ssh, ssh_basename, host, command, NULL);
+ execlp(ssh, ssh_basename, host, command, (char *)0);
}
close(sv[0]);
*fd_in = sv[1];
diff --git a/upload-pack.c b/upload-pack.c
index 47560c9..fbfdbcd 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -89,7 +89,7 @@ static void create_pack_file(void)
dup2(fd[0], 0);
close(fd[0]);
close(fd[1]);
- execl_git_cmd("pack-objects", "--stdout", NULL);
+ execl_git_cmd("pack-objects", "--stdout", (char *)0);
die("git-upload-pack: unable to exec git-pack-objects");
}
-- [mdw]
^ permalink raw reply related
* Re: git-diff-tree -M performance regression in 'next'
From: Junio C Hamano @ 2006-03-12 12:28 UTC (permalink / raw)
To: Fredrik Kuivinen; +Cc: git
In-Reply-To: <20060311172818.GB32609@c165.ib.student.liu.se>
Fredrik Kuivinen <freku045@student.liu.se> writes:
> I turned out that the rename detection took almost 10 minutes on my
> machine. More specifically,
>
> git-diff-tree -r -M --diff-filter=R v2.6.12 v2.6.14
>
> takes ~9 minutes with the current 'next'.
I have some updates to "next" tonight.
On my otherwise idle Duron 750 with slow disks, I am getting
something like these:
0.99.9m : 130m virtual, 40m resident, (0major+14205minor)
67.62user 0.08system 1:15.95elapsed
master : 130m virtual, 40m resident, (0major+12510minor)
66.06user 0.07system 1:10.95elapsed
"next" : 150m virtual, 65m resident, (0major+49858minor)
51.41user 0.45system 0.57.55elapsed
The result will _not_ exactly match, because the similarity
estimation algorithms are different.
Judging the differences objectively is a bit hard, but my
impression is that the "next" one tends to find more sensible
renames. To name a few:
* Documentation/dvb/README.dibusb from v2.6.12 seems pretty
similar to Documentation/dvb/README.dvb-usb from v2.6.14, and
"next" finds them, but "master" does not.
* "master" says arch/arm/configs/omnimeter_defconfig was
copy-edited to produce arch/arm/configs/collie_defconfig; The
diff output shows ~350 new lines and ~270 deleted lines, while
these files are 800-900 lines long; "next" rejects them. I
think this is a border-line case.
* "next" finds Kconfig and Makefile in arch/arm/mach-omap-1/ are
derived from arch/arm/mach-omap/; manual inspection of these
files makes me feel that decision is sensible. "master" does
not find them.
* Same thing for config.c in arch/m68knommu/platform/68VZ328/;
found to be derived from arch/m68knommu/platform/68VZ328/de2/ by
"next" but not by "master".
* Other examples "next" finds but "master" misses include:
arch/um/kernel/process.c arch/um/os-Linux/start_up.c
arch/um/kernel/tt/unmap.c arch/um/sys-x86_64/unmap.c
drivers/ide/cris/ide-v10.c drivers/ide/cris/ide-cris.c
include/asm-ppc/cputime.h include/asm-xtensa/cputime.h
include/asm-ppc64/ioctl.h include/asm-xtensa/ioctl.h
include/asm-ppc64/ioctls.h include/asm-xtensa/ioctls.h
include/asm-ppc64/mman.h include/asm-xtensa/mman.h
include/asm-ppc64/poll.h include/asm-xtensa/poll.h
include/asm-ppc64/shmbuf.h include/asm-xtensa/shmbuf.h
include/asm-ppc64/socket.h include/asm-xtensa/socket.h
include/asm-ppc64/termbits.h include/asm-xtensa/termbits.h
* The "next" one is not perfect. There are some quite bad
choices made by it:
include/asm-ppc64/timex.h include/asm-powerpc/bugs.h
include/asm-ppc64/iSeries/LparData.h include/linux/i2c-isa.h
^ permalink raw reply
* Re: [PATCH] Trivial warning fix for imap-send.c
From: Junio C Hamano @ 2006-03-12 11:27 UTC (permalink / raw)
To: Mark Wooding; +Cc: git
In-Reply-To: <slrne17urp.fr9.mdw@metalzone.distorted.org.uk>
Mark Wooding <mdw@distorted.org.uk> writes:
> This is not the right fix. NULL can be simply a #define for 0 (see
> 6.3.2.3#3 and 7.17). You need to write (char *)0 or (char *)NULL. I
> prefer to avoid the macro NULL entirely, since its misleading behaviour
> is precisely what got us into this mess.
Patches welcome. We have about 15 or so such instances.
$ git grep -n -H 'execl[_a-z]*(' '*.c'
cat-file.c:139: return execl_git_cmd("ls-tree", argv[2], NULL);
connect.c:547: execlp(git_proxy_command, git_proxy_command, host, port, NULL);
connect.c:646: execlp(ssh, ssh_basename, host, command, NULL);
connect.c:654: execlp("sh", "sh", "-c", command, NULL);
daemon.c:263: execl_git_cmd("upload-pack", "--strict", timeout_buf, ".", NULL);
exec_cmd.c:97:int execl_git_cmd(const char *cmd,...)
fetch-clone.c:32: execl_git_cmd("index-pack", "-o", idx, pack_tmp_name, NULL);
fetch-clone.c:109: execl_git_cmd("unpack-objects", quiet ? "-q" : NULL, NULL);
git.c:256: execlp("man", "man", page, NULL);
imap-send.c:948: execl( "/bin/sh", "sh", "-c", srvc->tunnel, NULL );
merge-index.c:18: execlp(pgm, arguments[0],
pager.c:14: execlp(prog, prog, NULL);
rsh.c:106: execlp(ssh, ssh_basename, host, command, NULL);
upload-pack.c:92: execl_git_cmd("pack-objects", "--stdout", NULL);
^ permalink raw reply
* [PATCH] imap-send: Add missing #include for macosx
From: Johannes Schindelin @ 2006-03-12 10:55 UTC (permalink / raw)
To: git, junkio
There is a compile error without that.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
imap-send.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
4f24a9d215bca31f40d5b994f59fff012e14086f
diff --git a/imap-send.c b/imap-send.c
index fddaac0..c2fd0fd 100644
--- a/imap-send.c
+++ b/imap-send.c
@@ -28,6 +28,7 @@
#include <netinet/in.h>
#include <netinet/tcp.h>
#include <arpa/inet.h>
+#include <sys/socket.h>
#include <netdb.h>
typedef struct store_conf {
--
1.2.0.gaa33-dirty
^ permalink raw reply related
* Re: [PATCH] Trivial warning fix for imap-send.c
From: Mark Wooding @ 2006-03-12 10:44 UTC (permalink / raw)
To: git
In-Reply-To: <20060311192954.GQ16135@artsapartment.org>
"Art Haas" <ahaas@airmail.net> wrote:
> --- a/imap-send.c
> +++ b/imap-send.c
> @@ -945,7 +945,7 @@ imap_open_store( imap_server_conf_t *srv
> _exit( 127 );
> close( a[0] );
> close( a[1] );
> - execl( "/bin/sh", "sh", "-c", srvc->tunnel, 0 );
> + execl( "/bin/sh", "sh", "-c", srvc->tunnel, NULL );
> _exit( 127 );
> }
This is not the right fix. NULL can be simply a #define for 0 (see
6.3.2.3#3 and 7.17). You need to write (char *)0 or (char *)NULL. I
prefer to avoid the macro NULL entirely, since its misleading behaviour
is precisely what got us into this mess.
-- [mdw]
^ permalink raw reply
* Re: git-diff-tree -M performance regression in 'next'
From: Junio C Hamano @ 2006-03-12 3:10 UTC (permalink / raw)
To: Fredrik Kuivinen; +Cc: git, junkio
In-Reply-To: <20060311172818.GB32609@c165.ib.student.liu.se>
Fredrik Kuivinen <freku045@student.liu.se> writes:
> I turned out that the rename detection took almost 10 minutes on my
> machine.
Yes, that is one of the reasons why it still is in "next", not
in "master".
The rename-detector change was done primarily to work around the
correctness problem the finer-grained delta changes would have
introduced. The new delta code would have produced far more
copies from the source than the current xdelta code, but the
nature of the new copies it would have found was quite different
from what we would usually call "file being renamed". Now we
decided to shelve the finer-grained delta code for now, I do not
see a pressing reason to have the experimental rename detector
graduate to "master" until we resolve its performance issues.
^ permalink raw reply
* Re: [PATCH] imap-send: cleanup execl() call to use NULL sentinel instead of 0
From: Marco Roeland @ 2006-03-11 20:30 UTC (permalink / raw)
To: Morten Welinder; +Cc: Mike McCormack, git
In-Reply-To: <118833cc0603110601x6ac9b2b6kaa0277981c6dd44b@mail.gmail.com>
On Saturday March 11th 2006 Morten Welinder wrote:
> If you're going to fix that, you should use (char *)NULL or
> (char *)0, just in case you end up on a machine where
> NULL doesn't a pointer type.
>
> (Yup, NULL can be a null pointer without having pointer type.)
For gcc NULL is specifically always guaranteed to be a valid sentinel.
And it was basically just about fixing the gcc warning, no pedantics
intended! All other uses within git for the exec() family also use plain
uncast NULL, which looks better anyway.
Strictly speaking you're probably right, but there's a chance that this
will generate warnings on other compilers.
And if you should use a compiler with a weird notion of NULL, you're
probably better off switching compilers immediately. ;-)
--
Marco Roeland
^ permalink raw reply
* [PATCH] Trivial warning fix for imap-send.c
From: Art Haas @ 2006-03-11 19:29 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
Hi.
After my 'git' repo this morning and building I noticed a GCC warning
about a missing sentinel in this file. A scan of the libc docs says
that execl() needs to end with a terminating NULL, as the miniscule
change below does, and recompliation with GCC removed the warning.
Art Haas
Signed-off-by: Art Haas <ahaas@airmail.net>
diff --git a/imap-send.c b/imap-send.c
index fddaac0..203284d 100644
--- a/imap-send.c
+++ b/imap-send.c
@@ -945,7 +945,7 @@ imap_open_store( imap_server_conf_t *srv
_exit( 127 );
close( a[0] );
close( a[1] );
- execl( "/bin/sh", "sh", "-c", srvc->tunnel, 0 );
+ execl( "/bin/sh", "sh", "-c", srvc->tunnel, NULL );
_exit( 127 );
}
--
Man once surrendering his reason, has no remaining guard against absurdities
the most monstrous, and like a ship without rudder, is the sport of every wind.
-Thomas Jefferson to James Smith, 1822
^ permalink raw reply related
* git-diff-tree -M performance regression in 'next'
From: Fredrik Kuivinen @ 2006-03-11 17:28 UTC (permalink / raw)
To: git; +Cc: junkio
Hi,
I added some time logging code to git-merge-recursive to see exactly
what we spend all the time on in merges which involves many changes,
such as a merge of a slightly modified v2.6.12 and an unmodified
v2.6.15.
I turned out that the rename detection took almost 10 minutes on my
machine. More specifically,
git-diff-tree -r -M --diff-filter=R v2.6.12 v2.6.14
takes ~9 minutes with the current 'next'.
With 65416758cd83772f2f3c69f1bd1f501608e64745, which uses the delta
code to compute the similarity measure, the above git-diff-tree
invocation takes 1.50 minutes.
- Fredrik
^ permalink raw reply
* Re: [PATCH] imap-send: cleanup execl() call to use NULL sentinel instead of 0
From: Morten Welinder @ 2006-03-11 14:01 UTC (permalink / raw)
To: Marco Roeland; +Cc: Mike McCormack, git
In-Reply-To: <20060311085550.GA32089@fiberbit.xs4all.nl>
If you're going to fix that, you should use (char *)NULL or
(char *)0, just in case you end up on a machine where
NULL doesn't a pointer type.
(Yup, NULL can be a null pointer without having pointer type.)
M.
^ permalink raw reply
* [PATCH] cg-export: document the -r option
From: Jonas Fonseca @ 2006-03-11 13:13 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
---
commit 4ac3822d222d8562a4cf4ac1edac1e2d60d40535
tree da406621cea613a71e3d46ce71bd629ce5d709d4
parent 129519d0f337f83699bad485dec105a6528961a2
author Jonas Fonseca <fonseca@diku.dk> Sat, 11 Mar 2006 13:56:42 +0100
committer Jonas Fonseca <fonseca@antimatter.localdomain> Sat, 11 Mar 2006 13:56:42 +0100
cg-export | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/cg-export b/cg-export
index 7acc1a0..cf9f0fd 100755
--- a/cg-export
+++ b/cg-export
@@ -9,6 +9,11 @@
# The destination can be either a `.tar`, `.tar.gz`, `.tar.bz2` or `.tgz`
# for generating a tarball. Other destination specifiers are assumed
# to be directory names, and the tree is exported to the given directory.
+#
+# OPTIONS
+# -------
+# -r TREE_ID:: Specify the tree version to export
+# Base the export on the given tree.
USAGE="cg-export [-r TREE_ID] DESTFILE"
_git_requires_root=1
--
Jonas Fonseca
^ permalink raw reply related
* [PATCH 4/4] Add quick reference
From: Jonas Fonseca @ 2006-03-11 13:12 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060310144835.GE7920@diku.dk>
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
---
This renames quick-reference.txt to cg-ref.txt to address the
cg-ref.pdf issue, makes the script more robust by using printf for
alignment, and improves the reference itself a bit.
Documentation/Makefile | 9 ++-
Documentation/asciidoc.conf | 4 +
Documentation/cg-ref.txt | 116 ++++++++++++++++++++++++++++++++++++
Documentation/make-cg-ref-asciidoc | 70 ++++++++++++++++++++++
4 files changed, 196 insertions(+), 3 deletions(-)
diff --git a/Documentation/Makefile b/Documentation/Makefile
index d316a14..b38fc4d 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -4,14 +4,14 @@ CG_SRC=$(filter-out $(CG_IGNORE), $(wild
PACKAGE=cogito
MAN1_TXT=$(patsubst ../cg%,cg%.1.txt,$(CG_SRC))
-MAN7_TXT=$(PACKAGE).7.txt
+MAN7_TXT=$(PACKAGE).7.txt cg-ref.7.txt
-DOC_HTML=$(patsubst %.txt,%.html,$(MAN1_TXT) $(MAN7_TXT)) introduction.html
+DOC_HTML=$(patsubst %.txt,%.html,$(MAN1_TXT) $(MAN7_TXT)) cg-ref.html introduction.html
DOC_MAN1=$(patsubst %.txt,%,$(MAN1_TXT))
DOC_MAN7=$(patsubst %.txt,%,$(MAN7_TXT))
-DOC_PDF=$(patsubst %.txt,%.pdf,$(MAN1_TXT) $(MAN7_TXT)) introduction.pdf
+DOC_PDF=$(patsubst %.txt,%.pdf,$(MAN1_TXT) $(MAN7_TXT)) cg-ref.pdf introduction.pdf
prefix=$(HOME)
bin=$(prefix)/bin
@@ -100,6 +100,9 @@ introduction.xml: ../README
$(PACKAGE).7.txt : make-$(PACKAGE)-asciidoc
./make-$(PACKAGE)-asciidoc > $@
+cg-ref.7.txt : cg-ref.txt make-cg-ref-asciidoc
+ CGPACKAGE=$(PACKAGE) ./make-cg-ref-asciidoc $< > $@
+
# It seems that cg%.txt won't match this so use an explicit rule
cg.1.txt : ../cg make-cg-asciidoc
CGPACKAGE=$(PACKAGE) ./make-cg-asciidoc $< > $@
diff --git a/Documentation/asciidoc.conf b/Documentation/asciidoc.conf
index baefb2f..69f1646 100644
--- a/Documentation/asciidoc.conf
+++ b/Documentation/asciidoc.conf
@@ -19,3 +19,7 @@ ifdef::backend-xhtml11[]
[gitlink-inlinemacro]
<a href="{target}.html">{target}{0?({0})}</a>
endif::backend-xhtml11[]
+
+[attributes]
+# Five non breaking spaces used for option indentation in the quick reference
+cg-refopt=     
diff --git a/Documentation/cg-ref.txt b/Documentation/cg-ref.txt
new file mode 100644
index 0000000..ab2321b
--- /dev/null
+++ b/Documentation/cg-ref.txt
@@ -0,0 +1,116 @@
+Cogito Quick Reference
+======================
+
+[frame="none"]
+`-------------------------------`---------------------------------------------
+Getting help:
+------------------------------------------------------------------------------
+*cg help* 'command' Show help for a command
+*cg* 'command' -h Show usage summary for a command
+------------------------------------------------------------------------------
+
+[frame="none"]
+`-------------------------------`---------------------------------------------
+Repository creation:
+------------------------------------------------------------------------------
+*cg init* Create a repository in the current directory
+*cg clone* 'url' Clone a remote repository into a subdirectory
+------------------------------------------------------------------------------
+
+[frame="none"]
+`-------------------------------`---------------------------------------------
+File operations:
+------------------------------------------------------------------------------
+*cg add* 'file' Add file to the working tree
+*cg add* -r 'directory' Recursively add files in directory
+*cg rm* 'file' Remove file or directory from the working tree
+*cg rm* -r 'directory' Recursively remove files in directory
+{cg-refopt} -f Delete file from disk
+*cg mv* 'file' 'destination' Move file or directory to new location
+{cg-refopt} -f Overwrite existing destination files
+*cg restore* 'file' Restore file
+{cg-refopt} -r 'revision' Bring back file from revision (and add it)
+{cg-refopt} -f Overwrite uncommitted changes
+------------------------------------------------------------------------------
+
+[frame="none"]
+`-------------------------------`---------------------------------------------
+Working tree:
+------------------------------------------------------------------------------
+*cg status* '[file]' Show branches and status of the working tree
+*cg reset* Reset the working tree
+*cg clean* Clean unknown files from the working tree
+*cg commit* '[file]' Commit the working tree
+{cg-refopt} -m 'message' Append message to commit log
+*cg admin-uncommit* Undo commit
+*cg seek* 'revision' Temporarily switch the working tree
+------------------------------------------------------------------------------
+
+[frame="none"]
+`-------------------------------`---------------------------------------------
+Examining History:
+------------------------------------------------------------------------------
+*cg log* '[file]' View commit log
+{cg-refopt} -r 'revision' Limit to revision range
+{cg-refopt} -f List affected files
+{cg-refopt} -s Summarize commits to one line
+*cg diff* '[file]' Show diff of changes
+{cg-refopt} -r 'revision' Diff revision instead of working tree
+{cg-refopt} -p Diff against parent
+{cg-refopt} -s Show diff stat
+------------------------------------------------------------------------------
+
+[frame="none"]
+`-------------------------------`---------------------------------------------
+Remote branches:
+------------------------------------------------------------------------------
+*cg fetch* '[branch]' Fetch changes from a remote branch
+*cg update* '[branch]' Fetch and merge changes from a remote branch
+*cg push* '[branch]' Push changes to a remote branch
+*cg branch-ls* List remote branches
+*cg branch-add* 'branch' 'url' Add remote branch
+*cg branch-chg* 'branch' 'url' Change URL of existing branch
+------------------------------------------------------------------------------
+
+[frame="none"]
+`-------------------------------`---------------------------------------------
+Local branches:
+------------------------------------------------------------------------------
+*cg merge* 'branch' Merge changes from branch
+*cg switch* 'branch' Switch the working tree to branch
+{cg-refopt} -r 'revision' Create branch from revision
+{cg-refopt} -f Overwrite existing branch
+------------------------------------------------------------------------------
+
+[frame="none"]
+`-------------------------------`---------------------------------------------
+Exporting and importing:
+------------------------------------------------------------------------------
+*cg patch* < 'file' Apply patch from stdin
+*cg mkpatch* Format a patch with log message and diffstat
+{cg-refopt} -r 'revision' Limit to revision range
+*cg export* 'directory' Export snapshot to directory
+*cg export* 'file.tar.gz' Export snapshot to tar file
+{cg-refopt} -r 'revision' Base snapshot on revision
+------------------------------------------------------------------------------
+
+[frame="none"]
+`-------------------------------`---------------------------------------------
+Tags:
+------------------------------------------------------------------------------
+*cg tag* 'name' 'revision' Create tag for a given revision
+{cg-refopt} -s Sign tag with your private key using GPG
+*cg tag-ls* Show name and revision for all tags
+------------------------------------------------------------------------------
+
+[frame="none"]
+`-------------------------------`---------------------------------------------
+File status flags:
+------------------------------------------------------------------------------
+`?` unknown File is not under revision control
+`A` added File has been added
+`D` deleted File has been deleted
+`!` disappeared File is not in the working tree
+`M` modified File has been touched or modified
+`m` modified (while merging) File was modified prior to the merge
+------------------------------------------------------------------------------
diff --git a/Documentation/make-cg-ref-asciidoc b/Documentation/make-cg-ref-asciidoc
new file mode 100755
index 0000000..960e711
--- /dev/null
+++ b/Documentation/make-cg-ref-asciidoc
@@ -0,0 +1,70 @@
+#!/usr/bin/env bash
+#
+# Generate asciidoc manpage markup from Cogito quick reference file.
+# Copyright (c) Jonas Fonseca, 2006
+#
+# Takes the path to the reference file. Prints the manpage to stdout.
+
+PACKAGE=${CGPACKAGE:-cogito}
+
+ref=$1
+
+cat <<__END__
+cg-ref(7)
+=========
+
+NAME
+----
+cg-ref - Cogito quick reference
+
+SYNOPSIS
+--------
+A list of frequently used commands grouped with related commands.
+
+DESCRIPTION
+-----------
+
+__END__
+
+sed '
+ 0,/^$/d
+ /^`---/d
+ /frame="none"/,1d
+ s/\\$//
+ s/[*]\([^*]*\)[*]/\1/g
+ s/[`]\([^`]*\)[`]/\1/g
+ s/['\'']\([^'\'']*\)['\'']/\1/g
+' < "$ref" | \
+while read line; do
+ col1=$(echo "$line" | cut -f 1)
+ case "$line" in
+ *":")
+ echo "$line"
+ echo "$line" | sed "s/[^~]/~/g"
+ echo
+ echo "[verse]"
+ continue
+ ;;
+ "-----"*|"")
+ echo "$line" | sed 's/-/./g'
+ continue
+ ;;
+ "{cg-refopt}"*)
+ col1=$(echo "$col1" | sed 's/.*cg-refopt}/ /')
+ ;;
+ esac
+ col2=$(echo "$line" | sed 's/.*[ ]\+//')
+ printf "%-30s %s\n" "$col1" "$col2"
+done
+
+cat << __END__
+
+COPYRIGHT
+---------
+Copyright (C) Jonas Fonseca, 2006.
+
+SEE ALSO
+--------
+gitlink:cg-ref[7] is part of gitlink:${PACKAGE}[7],
+a toolkit for managing gitlink:git[7] trees.
+__END__
--
Jonas Fonseca
^ permalink raw reply related
* [PATCH] imap-send: cleanup execl() call to use NULL sentinel instead of 0
From: Marco Roeland @ 2006-03-11 8:55 UTC (permalink / raw)
To: Mike McCormack; +Cc: git
Some versions of gcc check that calls to the exec() family have the proper
sentinel for variadic calls. This should be (char *) NULL according to the
man page. Although for all other purposes the 0 is equivalent, gcc
nevertheless does emit a warning for 0 and not for NULL. This also makes the
usage consistent throughout git.
The whitespace in function calls throughout imap-send.c has its own style,
so I left it that way.
---
imap-send.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
db1a0875cbc28970208e7a2fbb93d680d8ffe572
diff --git a/imap-send.c b/imap-send.c
index fddaac0..203284d 100644
--- a/imap-send.c
+++ b/imap-send.c
@@ -945,7 +945,7 @@ imap_open_store( imap_server_conf_t *srv
_exit( 127 );
close( a[0] );
close( a[1] );
- execl( "/bin/sh", "sh", "-c", srvc->tunnel, 0 );
+ execl( "/bin/sh", "sh", "-c", srvc->tunnel, NULL );
_exit( 127 );
}
--
1.2.4.ge29f
Marco Roeland
^ permalink raw reply related
* Re: annotate.perl triggers rpm bug
From: sean @ 2006-03-11 7:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v64mlxxq2.fsf@assigned-by-dhcp.cox.net>
On Fri, 10 Mar 2006 23:11:01 -0800
Junio C Hamano <junkio@cox.net> wrote:
> Sheesh -- broken packaging.
Yeah, not rpm's proudest moment.
> How about upcasing the word like other lines?
That seems to fix the dependency problem too and makes a little
more sense.
Sean
diff --git a/git-annotate.perl b/git-annotate.perl
index feea0a2..9df72a1 100755
--- a/git-annotate.perl
+++ b/git-annotate.perl
@@ -20,7 +20,7 @@ sub usage() {
-r, --rename
Follow renames (Defaults on).
-S, --rev-file revs-file
- use revs from revs-file instead of calling git-rev-list
+ Use revs from revs-file instead of calling git-rev-list
-h, --help
This message.
';
^ permalink raw reply related
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