* Re: [PATCH] "test" in Solaris' /bin/sh does not support -e
From: Dennis Stosberg @ 2006-06-26 9:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Petr Baudis, git
In-Reply-To: <7vwtb4i89d.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Dennis Stosberg <dennis@stosberg.net> writes:
>
> > Running "make clean" currently fails:
> > [ ! -e perl/Makefile ] || make -C perl/ clean
> > /bin/sh: test: argument expected
> > make: *** [clean] Error 1
>
> Ah, _BAD_. We seem to have the same in git-branch, git-checkout,
> git-clone and git-tag. You would probably need this on top of
> "master".
The SHELL_PATH in the Makefile is being set to "/bin/bash" on
Solaris, so there is currently no problem with those.
A lot of bashisms have been removed from the shell scripts since
that SHELL_PATH override was added in September 2005; I will have a
look whether it's still necessary.
Regards,
Dennis
^ permalink raw reply
* Re: [PATCH] Git.pm: Support for perl/ being built by a different compiler
From: Dennis Stosberg @ 2006-06-26 9:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmzc0i7xo.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Dennis Stosberg <dennis@stosberg.net> writes:
>
> > Yesterday I could build the next branch with Sun CC 5.8 with a few
> > trivial changes. I will send four patches in reply to this mail.
>
> Thanks. Next time around please sign off your patches.
Sorry, I forgot and will do next time. Please assume the Signed-Off
is present on the first three patches.
Regards,
Dennis
^ permalink raw reply
* Re: [PATCH] Git.pm: Support for perl/ being built by a different compiler
From: Junio C Hamano @ 2006-06-26 9:26 UTC (permalink / raw)
To: Dennis Stosberg; +Cc: git
In-Reply-To: <20060626082428.G52c9608e@leonov.stosberg.net>
Dennis Stosberg <dennis@stosberg.net> writes:
> Yesterday I could build the next branch with Sun CC 5.8 with a few
> trivial changes. I will send four patches in reply to this mail.
Thanks. Next time around please sign off your patches.
^ permalink raw reply
* Re: [PATCH] cast pid_t to long for printing
From: Junio C Hamano @ 2006-06-26 9:26 UTC (permalink / raw)
To: Uwe Zeisberger; +Cc: git
In-Reply-To: <20060626082606.GC3646@informatik.uni-freiburg.de>
Uwe Zeisberger <zeisberg@informatik.uni-freiburg.de> writes:
> While fixing daemon.c, I saw that there is a call to syslog using %d for
> pid_t, too. I fixed that in the same way without further testing and
> manual reading. I assume that's OK.
Is anybody using pid_t that is wider than int? IOW, I wonder if
it would make more sense to use "%d" with casting to int.
^ permalink raw reply
* Re: [PATCH] "test" in Solaris' /bin/sh does not support -e
From: Junio C Hamano @ 2006-06-26 9:19 UTC (permalink / raw)
To: Dennis Stosberg; +Cc: Petr Baudis, git
In-Reply-To: <20060626082754.G6ec0a61e@leonov.stosberg.net>
Dennis Stosberg <dennis@stosberg.net> writes:
> Running "make clean" currently fails:
> [ ! -e perl/Makefile ] || make -C perl/ clean
> /bin/sh: test: argument expected
> make: *** [clean] Error 1
Ah, _BAD_. We seem to have the same in git-branch, git-checkout,
git-clone and git-tag. You would probably need this on top of
"master".
-- >8 --
shell scripts: Avoid non-portable "test -e" where possible.
---
diff --git a/git-branch.sh b/git-branch.sh
index e0501ec..76971be 100755
--- a/git-branch.sh
+++ b/git-branch.sh
@@ -112,7 +112,7 @@ rev=$(git-rev-parse --verify "$head") ||
git-check-ref-format "heads/$branchname" ||
die "we do not like '$branchname' as a branch name."
-if [ -e "$GIT_DIR/refs/heads/$branchname" ]
+if test -f "$GIT_DIR/refs/heads/$branchname"
then
if test '' = "$force"
then
@@ -124,7 +124,7 @@ then
fi
if test "$create_log" = 'yes'
then
- mkdir -p $(dirname "$GIT_DIR/logs/refs/heads/$branchname")
+ mkdir -p "$(dirname "$GIT_DIR/logs/refs/heads/$branchname")"
touch "$GIT_DIR/logs/refs/heads/$branchname"
fi
git update-ref -m "branch: Created from $head" "refs/heads/$branchname" $rev
diff --git a/git-checkout.sh b/git-checkout.sh
index 77c2593..bfc2640 100755
--- a/git-checkout.sh
+++ b/git-checkout.sh
@@ -22,7 +22,7 @@ while [ "$#" != "0" ]; do
shift
[ -z "$newbranch" ] &&
die "git checkout: -b needs a branch name"
- [ -e "$GIT_DIR/refs/heads/$newbranch" ] &&
+ [ -f "$GIT_DIR/refs/heads/$newbranch" ] &&
die "git checkout: branch $newbranch already exists"
git-check-ref-format "heads/$newbranch" ||
die "git checkout: we do not like '$newbranch' as a branch name."
diff --git a/git-clone.sh b/git-clone.sh
index 6fa0daa..b355441 100755
--- a/git-clone.sh
+++ b/git-clone.sh
@@ -202,7 +202,7 @@ fi
dir="$2"
# Try using "humanish" part of source repo if user didn't specify one
[ -z "$dir" ] && dir=$(echo "$repo" | sed -e 's|/$||' -e 's|:*/*\.git$||' -e 's|.*[/:]||g')
-[ -e "$dir" ] && echo "$dir already exists." && usage
+[ -d "$dir" ] && echo "$dir already exists." && usage
mkdir -p "$dir" &&
D=$(cd "$dir" && pwd) &&
trap 'err=$?; cd ..; rm -r "$D"; exit $err' 0
diff --git a/git-tag.sh b/git-tag.sh
index a0afa25..6118b00 100755
--- a/git-tag.sh
+++ b/git-tag.sh
@@ -63,7 +63,7 @@ done
name="$1"
[ "$name" ] || usage
-if [ -e "$GIT_DIR/refs/tags/$name" -a -z "$force" ]; then
+if [ -f "$GIT_DIR/refs/tags/$name" -a -z "$force" ]; then
die "tag '$name' already exists"
fi
shift
^ permalink raw reply related
* Re: [PATCH] include signal.h for prototype of signal()
From: Uwe Zeisberger @ 2006-06-26 8:51 UTC (permalink / raw)
To: git; +Cc: Dennis Stosberg
In-Reply-To: <20060626082323.GB3646@informatik.uni-freiburg.de>
Hello,
Oops, this patch was already posted by Dennis Stosberg in
<20060626082613.G7dd5c243@leonov.stosberg.net>. (But it lacks a
sign-off, as do his other patches.)
Uwe Zeisberger wrote:
> Signed-off-by: Uwe Zeisberger <zeisberg@informatik.uni-freiburg.de>
>
> ---
>
> connect.c | 1 +
> merge-index.c | 1 +
> 2 files changed, 2 insertions(+), 0 deletions(-)
>
> 46cd6d04f4531dfaf56f7f1beb4ea6c73f08015e
> diff --git a/connect.c b/connect.c
> index db7342e..6c5389b 100644
> --- a/connect.c
> +++ b/connect.c
> @@ -3,6 +3,7 @@
> #include "pkt-line.h"
> #include "quote.h"
> #include "refs.h"
> +#include <signal.h>
> #include <sys/wait.h>
> #include <sys/socket.h>
> #include <netinet/in.h>
> diff --git a/merge-index.c b/merge-index.c
> index 190e12f..91908d8 100644
> --- a/merge-index.c
> +++ b/merge-index.c
> @@ -1,3 +1,4 @@
> +#include <signal.h>
> #include <sys/types.h>
> #include <sys/wait.h>
>
--
Uwe Zeisberger
cat /*dev/null; echo 'Hello World!';
cat > /dev/null <<*/
() { } int main() { printf("Hello World!\n");}
/* */
^ permalink raw reply
* Re: [PATCH] Git.pm: Support for perl/ being built by a different compiler
From: Thomas Glanzmann @ 2006-06-26 8:51 UTC (permalink / raw)
To: Dennis Stosberg; +Cc: Junio C Hamano, Petr Baudis, git
In-Reply-To: <20060626082939.G215d3ce6@leonov.stosberg.net>
Hello,
> -/*
> +/*l
> +
this looks like a typo in your patch.
Thomas
^ permalink raw reply
* Re: [PATCH] Git.pm: Support for perl/ being built by a different compiler
From: Dennis Stosberg @ 2006-06-26 8:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Petr Baudis, git
In-Reply-To: <20060626082428.G52c9608e@leonov.stosberg.net>
Sun CC 5.8 fails with a strange error compiling diff-delta.c that
looks like an error in Sun's compiler to me:
$ cc -V
cc: Sun C 5.8 Patch 121015-02 2006/03/29
$ cc -o diff-delta.o -c -I/opt/gnu/include -D__EXTENSIONS__ \
-DSHA1_HEADER='<openssl/sha.h>' -DNO_STRCASESTR -DNO_STRLCPY \
-DNO_SETENV -DNO_UNSETENV diff-delta.c
"diff-delta.c", line 251: identifier redeclared: create_delta
current : function(pointer to const struct delta_index \
{pointer to const void src_buf, unsigned long src_size, \
unsigned int hash_mask, array[-1] of pointer to struct index_entry {..} hash},\
pointer to const void, unsigned long, pointer to unsigned long, \
unsigned long) returning pointer to void
previous: function(pointer to const struct delta_index \
{pointer to const void src_buf, unsigned long src_size, \
unsigned int hash_mask, array[-1] of pointer to struct index_entry {..} hash},\
pointer to const void, unsigned long, pointer to unsigned long, \
unsigned long) returning pointer to void : "delta.h", line 37
cc: acomp failed for diff-delta.c
make: *** [diff-delta.o] Error 2
Yes, the two prototypes are identical. Seems like the compiler has
problems with the opaque struct. When I played around with it, I
was surprised when I found that Sun CC actually compiled this file
after I removed the const qualifier from the first parameter of the
create_delta() function. Does anybody have a better explanation
than an error in the compiler?
Regards,
Dennis
diff --git a/delta.h b/delta.h
index 7b3f86d..ec9147c 100644
--- a/delta.h
+++ b/delta.h
@@ -34,11 +34,12 @@ extern void free_delta_index(struct delt
* must be freed by the caller.
*/
extern void *
-create_delta(const struct delta_index *index,
+create_delta(struct delta_index *index,
const void *buf, unsigned long bufsize,
unsigned long *delta_size, unsigned long max_delta_size);
-/*
+/*l
+
* diff_delta: create a delta from source buffer to target buffer
*
* If max_delta_size is non-zero and the resulting delta is to be larger
diff --git a/diff-delta.c b/diff-delta.c
index 8b9172a..802be76 100644
--- a/diff-delta.c
+++ b/diff-delta.c
@@ -245,7 +245,7 @@ void free_delta_index(struct delta_index
#define MAX_OP_SIZE (5 + 5 + 1 + RABIN_WINDOW + 7)
void *
-create_delta(const struct delta_index *index,
+create_delta(struct delta_index *index,
const void *trg_buf, unsigned long trg_size,
unsigned long *delta_size, unsigned long max_size)
{
^ permalink raw reply related
* [PATCH] "test" in Solaris' /bin/sh does not support -e
From: Dennis Stosberg @ 2006-06-26 8:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Petr Baudis, git
In-Reply-To: <20060626082428.G52c9608e@leonov.stosberg.net>
Running "make clean" currently fails:
[ ! -e perl/Makefile ] || make -C perl/ clean
/bin/sh: test: argument expected
make: *** [clean] Error 1
---
Pasky said in #git that a simple -f test would suffice.
Makefile | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index 3dc54fe..d41d224 100644
--- a/Makefile
+++ b/Makefile
@@ -761,7 +761,7 @@ clean:
rm -f $(GIT_TARNAME).tar.gz git-core_$(GIT_VERSION)-*.tar.gz
rm -f $(htmldocs).tar.gz $(manpages).tar.gz
$(MAKE) -C Documentation/ clean
- [ ! -e perl/Makefile ] || $(MAKE) -C perl/ clean || $(MAKE) -C perl/ clean
+ [ ! -f perl/Makefile ] || $(MAKE) -C perl/ clean || $(MAKE) -C perl/ clean
$(MAKE) -C templates/ clean
$(MAKE) -C t/ clean
rm -f GIT-VERSION-FILE GIT-CFLAGS
--
1.4.0
^ permalink raw reply related
* [PATCH] Fix pkt-line.h to compile with a non-GCC compiler
From: Dennis Stosberg @ 2006-06-26 8:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Petr Baudis, git
In-Reply-To: <20060626082428.G52c9608e@leonov.stosberg.net>
pkt-line.h uses GCC's __attribute__ extension but does not include
git-compat-util.h. So it will not compile with a compiler that does
not support this extension.
---
pkt-line.h | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/pkt-line.h b/pkt-line.h
index 9abef24..9df653f 100644
--- a/pkt-line.h
+++ b/pkt-line.h
@@ -1,6 +1,8 @@
#ifndef PKTLINE_H
#define PKTLINE_H
+#include "git-compat-util.h"
+
/*
* Silly packetized line writing interface
*/
--
1.4.0.g64e8
^ permalink raw reply related
* [PATCH] Solaris needs inclusion of signal.h for signal()
From: Dennis Stosberg @ 2006-06-26 8:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Petr Baudis, git
In-Reply-To: <20060626082428.G52c9608e@leonov.stosberg.net>
Currently the compilation fails in connect.c and merge-index.c
---
connect.c | 1 +
merge-index.c | 1 +
2 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/connect.c b/connect.c
index db7342e..66e78a2 100644
--- a/connect.c
+++ b/connect.c
@@ -8,6 +8,7 @@ #include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <netdb.h>
+#include <signal.h>
static char *server_capabilities = NULL;
diff --git a/merge-index.c b/merge-index.c
index 190e12f..0498a6f 100644
--- a/merge-index.c
+++ b/merge-index.c
@@ -1,5 +1,6 @@
#include <sys/types.h>
#include <sys/wait.h>
+#include <signal.h>
#include "cache.h"
--
1.4.0.g64e8
^ permalink raw reply related
* [PATCH] cast pid_t to long for printing
From: Uwe Zeisberger @ 2006-06-26 8:26 UTC (permalink / raw)
To: git
In-Reply-To: <20060626080912.GA3646@informatik.uni-freiburg.de>
This fixes warnings on Solaris 8.
Signed-off-by: Uwe Zeisberger <zeisberg@informatik.uni-freiburg.de>
---
While fixing daemon.c, I saw that there is a call to syslog using %d for
pid_t, too. I fixed that in the same way without further testing and
manual reading. I assume that's OK.
daemon.c | 9 ++++++---
upload-pack.c | 2 +-
2 files changed, 7 insertions(+), 4 deletions(-)
b339b05462efea5fee9f2b9bf70de03897a5e4ab
diff --git a/daemon.c b/daemon.c
index 1ba4d66..8641b13 100644
--- a/daemon.c
+++ b/daemon.c
@@ -368,7 +368,7 @@ static void remove_child(pid_t pid, unsi
struct child m;
deleted = (deleted + 1) % MAX_CHILDREN;
if (deleted == spawned)
- die("could not find dead child %d\n", pid);
+ die("could not find dead child %ld\n", (long)pid);
m = live_child[deleted];
live_child[deleted] = n;
if (m.pid == pid)
@@ -476,9 +476,12 @@ static void child_handler(int signo)
if (!WIFEXITED(status) || WEXITSTATUS(status) > 0)
dead = " (with error)";
if (log_syslog)
- syslog(LOG_INFO, "[%d] Disconnected%s", pid, dead);
+ syslog(LOG_INFO, "[%ld] Disconnected%s",
+ (long)pid, dead);
else
- fprintf(stderr, "[%d] Disconnected%s\n", pid, dead);
+ fprintf(stderr,
+ "[%ld] Disconnected%s\n",
+ (long)pid, dead);
}
continue;
}
diff --git a/upload-pack.c b/upload-pack.c
index 7b86f69..fdfef39 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -274,7 +274,7 @@ static void create_pack_file(void)
goto fail;
}
error("git-upload-pack: we weren't "
- "waiting for %d", pid);
+ "waiting for %ld", (long)pid);
continue;
}
if (!WIFEXITED(status) || WEXITSTATUS(status) > 0) {
--
1.1.6.g7d80e
--
Uwe Zeisberger
exit vi, lesson V:
o : q ! CTRL-V <CR> <Esc> " d d d @ d
^ permalink raw reply related
* Re: [PATCH] Git.pm: Support for perl/ being built by a different compiler
From: Dennis Stosberg @ 2006-06-26 8:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Petr Baudis, git
In-Reply-To: <7vk676orjy.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Do things link and work fine if we do not have the GCC specific
> options?
Yes, with this patch I can compile Git with GCC while the Perl module
gets built with Sun CC. The result even works.
If the git commands written in Perl will be converted to use Git.pm,
Sun CC will become a new dependency for Git on Solaris, unless
people build a separate Perl with GCC or manually edit the generated
Makefile in the perl subdir to build the module with GCC.
> I would question why the rest of git is not built with Sun CC as
> well if that is the case.
Well, GCC comes along with Solaris on the CDs while Sun CC is a
separate product. And usually it's easier to build free software
with GCC, because many projects use GCC extensions. Often GCC is
the only compiler installed on Solaris machines.
Until the patch series from Florian Forster removed a lot of GCC'isms
a few days ago it was not possible to build Git with Sun CC.
Yesterday I could build the next branch with Sun CC 5.8 with a few
trivial changes. I will send four patches in reply to this mail.
Junio, please consider the first two patches for inclusion into the
next branch. The third patch is on top of Pasky's changes in the pu
branch. The fourth patch is a strange workaround for a strange
problem of which I think it is an error in Sun's compiler. That one
should not make its way into Git, but maybe someone on the list has
an idea about the problem.
Regards,
Dennis
^ permalink raw reply
* [PATCH] include signal.h for prototype of signal()
From: Uwe Zeisberger @ 2006-06-26 8:23 UTC (permalink / raw)
To: git
In-Reply-To: <20060626080912.GA3646@informatik.uni-freiburg.de>
Signed-off-by: Uwe Zeisberger <zeisberg@informatik.uni-freiburg.de>
---
connect.c | 1 +
merge-index.c | 1 +
2 files changed, 2 insertions(+), 0 deletions(-)
46cd6d04f4531dfaf56f7f1beb4ea6c73f08015e
diff --git a/connect.c b/connect.c
index db7342e..6c5389b 100644
--- a/connect.c
+++ b/connect.c
@@ -3,6 +3,7 @@
#include "pkt-line.h"
#include "quote.h"
#include "refs.h"
+#include <signal.h>
#include <sys/wait.h>
#include <sys/socket.h>
#include <netinet/in.h>
diff --git a/merge-index.c b/merge-index.c
index 190e12f..91908d8 100644
--- a/merge-index.c
+++ b/merge-index.c
@@ -1,3 +1,4 @@
+#include <signal.h>
#include <sys/types.h>
#include <sys/wait.h>
--
1.1.6.g7d80e
--
Uwe Zeisberger
http://www.google.com/search?q=the+speed+of+light+in+m%2Fs
^ permalink raw reply related
* Solaris 8
From: Uwe Zeisberger @ 2006-06-26 8:09 UTC (permalink / raw)
To: git
Hello,
when trying to get git running on Solaris 8 (gcc 2.95), there are
several pit-falls:
1) for me, install and tar are GNUish, ginstall and gtar don't exist.
(INSTALL = ginstall, TAR = gtar for SunOS in Makefile)
2) connect.c and merge-index.c use signal() without including signal.h
3) Solaris ships zlib 1.1.3. That version doesn't define
ZLIB_VERNUM. But no, that's not my problem, ... I have it: There is
another zlib version in /usr/local. That's 1.2.3, defining
ZLIB_VERNUM as 0x1230. The compiler uses include files from
/usr/local, but lib from /usr/lib. Aargh, I have to dig the admins
here...
4) libc don't know printf z and t modifier:
alloc.c: In function `alloc_report':
alloc.c:47: warning: unknown conversion type character `z' in format
alloc.c:47: warning: too many arguments for format
alloc.c:48: warning: unknown conversion type character `z' in format
alloc.c:48: warning: too many arguments for format
alloc.c:49: warning: unknown conversion type character `z' in format
alloc.c:49: warning: too many arguments for format
alloc.c:50: warning: unknown conversion type character `z' in format
alloc.c:50: warning: too many arguments for format
mktag.c: In function `verify_tag':
mktag.c:69: warning: unknown conversion type character `t' in format
mktag.c:69: warning: too many arguments for format
mktag.c:72: warning: unknown conversion type character `t' in format
mktag.c:72: warning: too many arguments for format
mktag.c:77: warning: unknown conversion type character `t' in format
mktag.c:77: warning: too many arguments for format
mktag.c:97: warning: unknown conversion type character `t' in format
mktag.c:97: warning: too many arguments for format
mktag.c:104: warning: unknown conversion type character `t' in format
mktag.c:104: warning: too many arguments for format
5) I don't understand why I get this warning for EMIT(c), but not for
EMIT('\\'):
quote.c:34: warning: value computed is not used
quote.c:37: warning: value computed is not used
6) typedef long pid_t
upload-pack.c: In function `create_pack_file':
upload-pack.c:277: warning: int format, pid_t arg (arg 2)
daemon.c: In function `remove_child':
daemon.c:371: warning: int format, pid_t arg (arg 2)
daemon.c: In function `child_handler':
daemon.c:481: warning: int format, pid_t arg (arg 3)
7) I think these can safely be ignored:
builtin-help.c: In function `cmd_help':
builtin-help.c:234: warning: null format string
builtin-help.c:236: warning: null format string
git.c: In function `main':
git.c:280: warning: null format string
I'll send out patches in reply to this mail for 2) and 6)
--
Uwe Zeisberger
main(){char*a="main(){char*a=%c%s%c;printf(a,34,a,34%c";printf(a,34,a,34
,10);a=",10);a=%c%s%c;printf(a,34,a,34,10);}%c";printf(a,34,a,34,10);}
^ permalink raw reply
* Re: [PATCH] correct documentation for git grep
From: Johannes Schindelin @ 2006-06-26 6:59 UTC (permalink / raw)
To: Matthias Lederhofer; +Cc: git
In-Reply-To: <E1Fuecp-0004iI-RG@moooo.ath.cx>
Hi,
On Mon, 26 Jun 2006, Matthias Lederhofer wrote:
> - [-f <file>] [-e <pattern>]
> + [-f <file>] [-e] <pattern> [-e <pattern> [..]]
> [<tree>...]
> [--] [<path>...]
Minor nit: as you can see from the two latter lines, "<bla>..." is the
standard notation, whereas "<bla> [..]" is not.
Ciao,
Dscho
^ permalink raw reply
* Re: PPC SHA-1 Updates in "pu"
From: Junio C Hamano @ 2006-06-26 6:49 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Petr Baudis, git, Linus Torvalds, Randal L. Schwartz
In-Reply-To: <Pine.LNX.4.63.0606251537450.29667@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> I can live with it. Although I still think that it would be a good idea to
> convert (at least the most commonly used) scripts to C.
>
> Perl, Python and sometimes even bash are good for fast prototyping. But
> for serious work, such as profiling, they are not that good.
I expect the eventual primary customer of Git.xs to be gitweb.
I do not necessarily agree with what you just said about
scripting languages. Shell is a very good implementation
language for certain serious things that does not require
performance and non command line UI.
> And you can see different behaviour on different platforms (plus things
> like the SunCC requirement for XS on Solaris), which make the scripts less
> robust.
I am not sure about "less robust" part, but it certainly
involves initial pain to deal with portability across platforms.
That's why I want to make sure that the basics is sound before
we spend too much time and attention on converting existing
scripts. I think the major part of bringing Git.xs series
acceptably mergeable is not about XS programming and Perl script
conversion, but primarily about the work on the build
infrastructure (Makefile, test scripts and .spec).
^ permalink raw reply
* Re: [PATCH] Git.pm build: Fix quoting and missing GIT-CFLAGS dependency
From: Junio C Hamano @ 2006-06-26 6:48 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060625152157.GG21864@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> Could you please also throw in these two?
>
> [PATCH 3/7] Git.pm: Swap hash_object() parameters
> [PATCH 4/7] Git.pm: Fix Git->repository("/somewhere/totally/elsewhere")
Will take a look.
> Yes, -I is very broken. I have abandoned it in:
>
> Subject: Re: [PATCH 01/12] Introduce Git.pm (v4)
> Date: Sat, 24 Jun 2006 13:52:27 +0200
>
> The advantage to your approach is that it works properly without
> requiring to make install even outside of the testsuite.
I remember myself getting utterly discusted when I saw the
inclusion of the build-time blib directory in the search path in
some other Perl code outside git.
Worse yet, I suspect the order you do the two directories is
wrong to prefer the freshly built one over the one you installed
the last time, but I was trying not to stare at too much for
health reasons so ... ;-).
^ permalink raw reply
* perl profiling (was: PPC SHA-1 Updates in "pu")
From: Jeff King @ 2006-06-26 1:51 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Randal L. Schwartz, git
In-Reply-To: <Pine.LNX.4.63.0606260121040.29667@wbgn013.biozentrum.uni-wuerzburg.de>
On Mon, Jun 26, 2006 at 01:23:21AM +0200, Johannes Schindelin wrote:
> one-liner, you probably want to say that profiling Perl is easy. Can you
> enlighten me how to do memory _and_ timing profiling on, say, a per-line
> basis?
For the timing, have you tried using Devel::SmallProf?
perl -d:SmallProf foo.pl
-Peff
^ permalink raw reply
* Re: A series file for git?
From: Shawn Pearce @ 2006-06-26 0:44 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: Junio C Hamano, Linus Torvalds, Git Mailing List
In-Reply-To: <m1r71exww5.fsf@ebiederm.dsl.xmission.com>
"Eric W. Biederman" <ebiederm@xmission.com> wrote:
> Junio C Hamano <junkio@cox.net> writes:
[snip]
> > I am not sure about that. What does the series file contain,
> > and what other things the meta data branch contain? If you are
> > listing commit SHA1 in the series file, you _do_ have the risk
> > of losing things -- git-fsck-objects needs to look at such blob
> > object and consider that as the root of reachability chain; to
> > me that seems too specialized hack.
>
> When described that way I agree. The best I can imagine
> is to list those commits as ancestors of the current commit.
> Hmm. Or possibly I could collect up tag objects and work
> with them. In any case representing this in a non-hackish
> way is my goal.
I did this in pg. It didn't work out very well as the GIT diff
tools (e.g. the diff in gitk) show the diff in a very odd way.
It did not work out as well as I had hoped.
> > I have a feeling that I really should study how well StGIT does
> > things before talking about this further. It may suit your
> > needs perfectly. What do you feel is lacking in StGIT that you
> > need?
>
> What I want and what I see lacking in the git and StGit is
> the ability to record the history of editing the history
> of a branch.
>
> A mundane example. It would be nice if I rebased a branch if
> I could record in some fashion what that branch was before
> I rebased it.
Use the new reflog code. Its in 1.4. Check the documentation for
git-update-ref for some details. git-commit, git-rebase and git-am
should track history on a ref in the reflog. However a reflog
won't anchor a commit into your repository and thus a prune may
remove it if no other commit/ref/tag mentions it.
--
Shawn.
^ permalink raw reply
* [PATCH] correct documentation for git grep
From: Matthias Lederhofer @ 2006-06-26 0:06 UTC (permalink / raw)
To: git
In-Reply-To: <E1FueCE-0003W3-4Q@moooo.ath.cx>
Signed-off-by: Matthias Lederhofer <matled@gmx.net>
---
The 'or' as logic or should be marked in the text. I did
that in the patch with --and too so if this is accepted the
documentation should be consistent. Sorry for the noise.
Documentation/git-grep.txt | 8 +++++++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-grep.txt b/Documentation/git-grep.txt
index 7b810df..ebfe51b 100644
--- a/Documentation/git-grep.txt
+++ b/Documentation/git-grep.txt
@@ -16,7 +16,7 @@ SYNOPSIS
[-n] [-l | --files-with-matches] [-L | --files-without-match]
[-c | --count]
[-A <post-context>] [-B <pre-context>] [-C <context>]
- [-f <file>] [-e <pattern>]
+ [-f <file>] [-e] <pattern> [-e <pattern> [..]]
[<tree>...]
[--] [<path>...]
@@ -71,6 +71,12 @@ OPTIONS
-f <file>::
Read patterns from <file>, one per line.
+-e::
+ The next parameter is a pattern. This option has to be
+ used for patterns starting with - and should be used in
+ scripts passing user input to grep. You can specify multiple
+ patterns which will be combined by 'or'.
+
`<tree>...`::
Search blobs in the trees for specified patterns.
--
1.4.1.rc1.g72a4-dirty
^ permalink raw reply related
* [PATCH] git-grep: --and to combine patterns with and instead of or
From: Matthias Lederhofer @ 2006-06-26 0:02 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.63.0606260108510.29667@wbgn013.biozentrum.uni-wuerzburg.de>
Signed-off-by: Matthias Lederhofer <matled@gmx.net>
---
> ... and by the far the most common use is to pass more than one pattern.
> Also, the usage is "[-e] <pattern> [-e <pattern>...]".
Here is a patch to allow combination of patterns with 'and' instead of
'or'. This makes it easier to search for combinations of words in a line
without using grep multiple times combined by pipes. So it is still
possible to use -A/-B/-C (something I miss in normal grep). --and
cannot be passed down, so we have to use the built-in version if it is
set.
Documentation/git-grep.txt | 5 ++++-
builtin-grep.c | 17 +++++++++++++----
2 files changed, 17 insertions(+), 5 deletions(-)
diff --git a/Documentation/git-grep.txt b/Documentation/git-grep.txt
index ebfe51b..df9d705 100644
--- a/Documentation/git-grep.txt
+++ b/Documentation/git-grep.txt
@@ -16,7 +16,7 @@ SYNOPSIS
[-n] [-l | --files-with-matches] [-L | --files-without-match]
[-c | --count]
[-A <post-context>] [-B <pre-context>] [-C <context>]
- [-f <file>] [-e] <pattern> [-e <pattern> [..]]
+ [-f <file>] [-e] <pattern> [-e <pattern> [..]] [--and]
[<tree>...]
[--] [<path>...]
@@ -77,6 +77,9 @@ OPTIONS
scripts passing user input to grep. You can specify multiple
patterns which will be combined by 'or'.
+--and::
+ Combine multiple patterns by 'and' instead of 'or'.
+
`<tree>...`::
Search blobs in the trees for specified patterns.
diff --git a/builtin-grep.c b/builtin-grep.c
index d0677cc..a2a034a 100644
--- a/builtin-grep.c
+++ b/builtin-grep.c
@@ -96,6 +96,7 @@ struct grep_opt {
regex_t regexp;
unsigned linenum:1;
unsigned invert:1;
+ unsigned and:1;
unsigned name_only:1;
unsigned unmatch_name_only:1;
unsigned count:1;
@@ -268,7 +269,11 @@ static int grep_buffer(struct grep_opt *
word_char(bol[pmatch[0].rm_eo]))
hit = 0;
}
- if (hit)
+ if (opt->and && !hit) {
+ hit = 0;
+ break;
+ }
+ if (!opt->and && hit)
break;
}
/* "grep -v -e foo -e bla" should list lines
@@ -553,10 +558,10 @@ static int grep_cache(struct grep_opt *o
#ifdef __unix__
/*
* Use the external "grep" command for the case where
- * we grep through the checked-out files. It tends to
- * be a lot more optimized
+ * we grep through the checked-out files and do not use
+ * non-standard options. It tends to be a lot more optimized.
*/
- if (!cached) {
+ if (!cached && !opt->and) {
hit = external_grep(opt, paths, cached);
if (hit >= 0)
return hit;
@@ -690,6 +695,10 @@ int cmd_grep(int argc, const char **argv
opt.binary = GREP_BINARY_TEXT;
continue;
}
+ if (!strcmp("--and", arg)) {
+ opt.and = 1;
+ continue;
+ }
if (!strcmp("-i", arg) ||
!strcmp("--ignore-case", arg)) {
opt.regflags |= REG_ICASE;
--
1.4.1.rc1.g72a4-dirty
^ permalink raw reply related
* [PATCH] correct documentation for git grep
From: Matthias Lederhofer @ 2006-06-25 23:39 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0606260108510.29667@wbgn013.biozentrum.uni-wuerzburg.de>
Signed-off-by: Matthias Lederhofer <matled@gmx.net>
---
> ... and by the far the most common use is to pass more than one pattern.
> Also, the usage is "[-e] <pattern> [-e <pattern>...]".
Ok, so I changed the patch :)
Documentation/git-grep.txt | 8 +++++++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-grep.txt b/Documentation/git-grep.txt
index 7b810df..3dd1bdd 100644
--- a/Documentation/git-grep.txt
+++ b/Documentation/git-grep.txt
@@ -16,7 +16,7 @@ SYNOPSIS
[-n] [-l | --files-with-matches] [-L | --files-without-match]
[-c | --count]
[-A <post-context>] [-B <pre-context>] [-C <context>]
- [-f <file>] [-e <pattern>]
+ [-f <file>] [-e] <pattern> [-e <pattern> [..]]
[<tree>...]
[--] [<path>...]
@@ -71,6 +71,12 @@ OPTIONS
-f <file>::
Read patterns from <file>, one per line.
+-e::
+ The next parameter is a pattern. This option has to be
+ used for patterns starting with - and should be used in
+ scripts passing user input to grep. You can specify multiple
+ patterns which will be combined by or.
+
`<tree>...`::
Search blobs in the trees for specified patterns.
--
1.4.1.rc1.g72a4-dirty
^ permalink raw reply related
* Re: [PATCH] GIT_TRACE: show which built-in/external commands are executed
From: Johannes Schindelin @ 2006-06-25 23:30 UTC (permalink / raw)
To: Matthias Lederhofer; +Cc: git
In-Reply-To: <E1FuXBk-0001SG-3n@moooo.ath.cx>
Hi,
On Sun, 25 Jun 2006, Matthias Lederhofer wrote:
> > P.S.: Now we only have to convert all "git-" invocations in the scripts to
> > "git " invocations so we can benefit from it. But that would mean two
> > forks instead of one for the non-builtins. Hmm.
>
> Why do we not use this policy:
>
> git-* is guaranteed to be the normal command without any strange alias
> expansion, default parameters or something else a script does not like
> to be changed in the commands. So all scripts use git-*, this will
> prevent a double exec. The path to git-* should be obtained using git
> --exec-path in the beginnig.
That still leaves my problem: GIT_TRACE=1 on scripts is incomplete.
Ciao,
Dscho
^ permalink raw reply
* Re: PPC SHA-1 Updates in "pu"
From: Johannes Schindelin @ 2006-06-25 23:23 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: Junio C Hamano, Petr Baudis, git, Linus Torvalds
In-Reply-To: <86veqp8456.fsf@blue.stonehenge.com>
Hi,
On Sun, 25 Jun 2006, Randal L. Schwartz wrote:
> >>>>> "Johannes" == Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> Johannes> Perl, Python and sometimes even bash are good for fast
> Johannes> prototyping. But for serious work, such as profiling, they are not
> Johannes> that good.
>
> Allow my to register my strong disagreement to that statement, but then I'll
> crawl back in my hole.
Which statement do you mean? The "good for fast prototyping" one? ;-)
Being our friendly local Perl wizard, who could code cvsserver as a Perl
one-liner, you probably want to say that profiling Perl is easy. Can you
enlighten me how to do memory _and_ timing profiling on, say, a per-line
basis?
Ciao,
Dscho
^ 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