* Re: PPC SHA-1 Updates in "pu"
From: Johannes Schindelin @ 2006-06-25 13:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Petr Baudis, git, Linus Torvalds, Randal L. Schwartz
In-Reply-To: <7vzmg1v7ci.fsf@assigned-by-dhcp.cox.net>
Hi,
On Sun, 25 Jun 2006, Junio C Hamano wrote:
> I vaguely recall that last time we discussed the minimum Perl
> version requirement somebody perhaps Merlyn said 5.6 is old
> enough but in some corporate settings people may still be stuck
> with 5.004.
>
> Tentatively let's say our cut-off point is somewhere around 5.6.
> If we can get away without relying on extra from CPAN that would
> be great. Otherwise as long as the modules from CPAN we end up
> depending on are all compatible with the cut-off version of Perl
> that would be acceptable. We might even try to be nicer and
> carry a straight copy of what we require from CPAN in compat/
> just like we have subprocess.py there (modulo licensing worries
> if any, of course).
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.
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.
Ciao,
Dscho
^ permalink raw reply
* Re: New web frontend: gitarella
From: Johannes Schindelin @ 2006-06-25 13:47 UTC (permalink / raw)
To: Marco Costalba; +Cc: git
In-Reply-To: <e5bfff550606250349m1d243cbfsbecea557f3225d9b@mail.gmail.com>
Hi,
On Sun, 25 Jun 2006, Marco Costalba wrote:
> It's amazing to see in how many different ways a lot of people try to
> find an (almost the same) solution for (almost) the same problem. IMHO
> this is one of the main differences between developing for fun and as a
> day job.
Disagree. I was refactoring a C++ project recently, and we found no less
than 34 separate implementations of sorted arrays, _plus_ usage of the
STL to do the same job.
It does not depend on commercial or not, but it depends on a dedicated
benevolent dictator to keep things clean.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] GIT_TRACE: show which built-in/external commands are executed
From: Matthias Lederhofer @ 2006-06-25 13:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v3bdtv4h3.fsf@assigned-by-dhcp.cox.net>
With the environment variable GIT_TRACE set git will show
- alias expansion
- built-in command execution
- external command execution
on stderr.
Signed-off-by: Matthias Lederhofer <matled@gmx.net>
---
Examples:
% GIT_TRACE=1 git status > /dev/null
trace: exec: '/home/matled/local/stow/git/bin/git-status'
trace: built-in: git 'rev-parse' '--git-dir'
trace: built-in: git 'rev-parse' '--show-cdup'
trace: built-in: git 'update-index' '-q' '--unmerged' '--refresh'
trace: built-in: git 'diff-index' '-M' '--cached' '--name-status' \
'--diff-filter=MDTCRA' 'HEAD'
trace: built-in: git 'diff-files' '--name-status'
trace: built-in: git 'ls-files' '-z' '--others' '--directory' \
'--no-empty-directory' '--exclude-from=.git/info/exclude' \
'--exclude-per-directory=.gitignore'
This seems to be quite useful to find out how tools do things and for
debugging.
% GIT_TRACE=1 git showtag v1.4.0 > /dev/null
trace: exec: '/home/matled/local/stow/git/bin/git-showtag' 'v1.4.0'
trace: exec failed: No such file or directory
trace: alias expansion: showtag => 'cat-file' 'tag'
trace: built-in: git 'cat-file' 'tag' 'v1.4.0'
% GIT_TRACE=1 git l > /dev/null
trace: exec: '/home/matled/local/stow/git/bin/git-l'
trace: exec failed: No such file or directory
trace: alias expansion: l => 'log' '-p'
trace: built-in: git 'log' '-p'
Documentation/git.txt | 7 +++++++
exec_cmd.c | 19 +++++++++++++++++++
git.c | 25 +++++++++++++++++++++++++
quote.c | 17 +++++++++++++++++
quote.h | 1 +
5 files changed, 69 insertions(+), 0 deletions(-)
diff --git a/Documentation/git.txt b/Documentation/git.txt
index 51f20c6..603c474 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -615,6 +615,13 @@ git Diffs
gitlink:git-diff-files[1];
gitlink:git-diff-tree[1]
+other
+~~~~~
+'GIT_TRACE'::
+ If this variable is set git will print `trace:` messages on
+ stderr telling about alias expansion, built-in command
+ execution and external command execution.
+
Discussion[[Discussion]]
------------------------
include::README[]
diff --git a/exec_cmd.c b/exec_cmd.c
index c1539d1..f2133ec 100644
--- a/exec_cmd.c
+++ b/exec_cmd.c
@@ -1,5 +1,6 @@
#include "cache.h"
#include "exec_cmd.h"
+#include "quote.h"
#define MAX_ARGS 32
extern char **environ;
@@ -96,9 +97,27 @@ int execv_git_cmd(const char **argv)
tmp = argv[0];
argv[0] = git_command;
+ if (getenv("GIT_TRACE")) {
+ fputs("trace: exec:", stderr);
+ const char **p = argv;
+ while (*p) {
+ fputc(' ', stderr);
+ sq_quote_print(stderr, *p);
+ ++p;
+ }
+ putc('\n', stderr);
+ fflush(stderr);
+ }
+
/* execve() can only ever return if it fails */
execve(git_command, (char **)argv, environ);
+ if (getenv("GIT_TRACE")) {
+ fprintf(stderr, "trace: exec failed: %s\n",
+ strerror(errno));
+ fflush(stderr);
+ }
+
argv[0] = tmp;
}
return -1;
diff --git a/git.c b/git.c
index 94e9a4a..8b060e8 100644
--- a/git.c
+++ b/git.c
@@ -11,6 +11,7 @@ #include <stdarg.h>
#include "git-compat-util.h"
#include "exec_cmd.h"
#include "cache.h"
+#include "quote.h"
#include "builtin.h"
@@ -119,6 +120,18 @@ static int handle_alias(int *argcp, cons
if (!strcmp(alias_command, new_argv[0]))
die("recursive alias: %s", alias_command);
+ if (getenv("GIT_TRACE")) {
+ int i;
+ fprintf(stderr, "trace: alias expansion: %s =>",
+ alias_command);
+ for (i = 0; i < count; ++i) {
+ fputc(' ', stderr);
+ sq_quote_print(stderr, new_argv[i]);
+ }
+ fputc('\n', stderr);
+ fflush(stderr);
+ }
+
/* insert after command name */
if (*argcp > 1) {
new_argv = realloc(new_argv, sizeof(char*) *
@@ -198,6 +211,18 @@ static void handle_internal_command(int
struct cmd_struct *p = commands+i;
if (strcmp(p->cmd, cmd))
continue;
+
+ if (getenv("GIT_TRACE")) {
+ int i;
+ fprintf(stderr, "trace: built-in: git");
+ for (i = 0; i < argc; ++i) {
+ fputc(' ', stderr);
+ sq_quote_print(stderr, argv[i]);
+ }
+ putc('\n', stderr);
+ fflush(stderr);
+ }
+
exit(p->fn(argc, argv, envp));
}
}
diff --git a/quote.c b/quote.c
index dcc2326..2ca18e8 100644
--- a/quote.c
+++ b/quote.c
@@ -45,6 +45,23 @@ size_t sq_quote_buf(char *dst, size_t n,
return len;
}
+void sq_quote_print(FILE *stream, const char *src)
+{
+ char c;
+
+ fputc('\'', stream);
+ while ((c = *src++)) {
+ if (need_bs_quote(c)) {
+ fputs("'\\", stream);
+ fputc(c, stream);
+ fputc('\'', stream);
+ } else {
+ fputc(c, stream);
+ }
+ }
+ fputc('\'', stream);
+}
+
char *sq_quote(const char *src)
{
char *buf;
diff --git a/quote.h b/quote.h
index c1ab378..fc5481e 100644
--- a/quote.h
+++ b/quote.h
@@ -29,6 +29,7 @@ #include <stdio.h>
*/
extern char *sq_quote(const char *src);
+extern void sq_quote_print(FILE *stream, const char *src);
extern size_t sq_quote_buf(char *dst, size_t n, const char *src);
/* This unwraps what sq_quote() produces in place, but returns
--
1.4.1.rc1.gfa6c9-dirty
^ permalink raw reply related
* Re: On boolean configuration variables...
From: Johannes Schindelin @ 2006-06-25 14:00 UTC (permalink / raw)
To: Anand Kumria; +Cc: git
In-Reply-To: <e7m3b6$eoa$1@sea.gmane.org>
Hi,
On Sun, 25 Jun 2006, Anand Kumria wrote:
> Allowing 'yes' and 'no' to equal 'true' and 'false' respectively sounds
> pretty sane and user-friendly.
>
> Why wouldn't you want to do that?
'Cause you'd have to add "maybe", too ;-)
Seriously, there is a subtle side to booleans, which is the reason that
they typically take on only "false" and "true": Consider the question "Is
the box not red?". If the answer is "yes", I do not know if "yes, the box
is red" or "yes, the box is not red".
"true" and "false" are less ambiguous.
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC] GIT user survey
From: Paolo Ciarrocchi @ 2006-06-25 14:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfyhtv6iw.fsf@assigned-by-dhcp.cox.net>
On 6/25/06, Junio C Hamano <junkio@cox.net> wrote:
> "Paolo Ciarrocchi" <paolo.ciarrocchi@gmail.com> writes:
>
> > About you
> >
> > 1. What country are you in?
> > 2. What is your preferred language?
> > 3. What's your gender?
>
> Demography is interesting and quite relevant to understand the
> bias in the answers to the rest of the questions, although I do
> not see much point about #3. Question #2 is relevant in i18n,
> of course.
Yeah, removed item #3.
> I would also ask if the respondent has her own patch in the
> git.git repository. If most of them are git developers, the
> answer to the question "was git easy to learn" becomes
> suspicious, for example.
OK.
> > Getting started with GIT
> >
> > 1. How did you hear about GIT?
> > 2. Did you find GIT easy to learn?
> > 3. What helped you most in learning to use it?
>
> Also "When did you start using git?" -- old timers who learned
> git when it was still young and small would have had an easier
> time to learn it.
OK.
> > How you use GIT
> >
> > 1. Do you use GIT for work, unpaid projects, or both?
> > 2. How do you obtain GIT? Source tarball, binary package, or
> > pull the main repository?
> > 3. What platforms (hardware, OS, version) do you use GIT on?
> > 4. How many people do you collaborate with using GIT?
> > 5. How big are the repositories that you work on? (e.g. how many
> > files, how much disk space)
> > 6. How many different projects do you manage using GIT?
> > 7. Which porcelains do you use?
>
> After seeing the Mercurial survey result, I think question #3
> should be stated a bit more concretely. The results having
> mixture of i386 and Linux are not very interesting. I would
> also add "how deep the history" to #5.
OK
> > Getting help, staying in touch
> >
> > 1. Have you tried to get GIT help from other people?
> > * If yes, did you get these problems resolved quickly and to
> > your liking?
> > 2. Do you subscribe to the mailing list?
> > * If yes, do you find it useful, and traffic levels OK?
> > 3. Do you use the IRC channel (#git on irc.freenode.net)?
> > * If no, did you know that all of the core developers use
> > IRC, and that there's almost 24-hour help available?
>
> About #3, I do not see some people I consider "core" often on
> the IRC. Maybe "most of the core".
I think I can remove that part of the sentece, Pasky already had the
same comment when I was discussing the sruvey on #GIT. My mistake.
New version attached.
About you
1. What country are you in?
2. What is your preferred language?
Getting started with GIT
1. How did you hear about GIT?
2. Did you find GIT easy to learn?
3. What helped you most in learning to use it?
4. When did you start using git?
How you use GIT
1. Do you use GIT for work, unpaid projects, or both?
2. How do you obtain GIT? Source tarball, binary package, or
pull the main repository?
3. What hardware platforms do you use GIT on?
4. What OS (please include the version) do you use GIT on?
5. How many people do you collaborate with using GIT?
6. How big are the repositories that you work on? (e.g. how many
files, how much disk space, how deep is the histoty)
7. How many different projects do you manage using GIT?
8. Which porcellains do you use?
9. Is the git.git repository including codes produced by you?
What you think of GIT
1. Overall, how happy are you with GIT?
2. How does GIT compare to other SCM tools you have used?
3. What do you like about using GIT?
4. What would you most like to see improved about GIT?
(features, bugs, plugins, documentation, ...)
5. If you want to see GIT more widely used, what do you
think we could do to make this happen?
Documentation
1. Do you use the GIT wiki? If yes, do you find it useful?
2. Do you find GIT's online help useful?
3. What is your favourite user documentation for any software
projects or products you have used?
4. What could be improved on the GIT homepage?
Getting help, staying in touch
1. Have you tried to get GIT help from other people?
* If yes, did you get these problems resolved quickly and to
your liking?
2. Do you subscribe to the mailing list?
* If yes, do you find it useful, and traffic levels OK?
3. Do you use the IRC channel (#git on irc.freenode.net)?
Open forum
1. What other comments or suggestions do you have that are not
covered by the questions above?
--
Paolo
http://paolociarrocchi.googlepages.com
http://picasaweb.google.com/paolo.ciarrocchi
^ permalink raw reply
* Re: [PATCH] GIT_TRACE: show which built-in/external commands are executed
From: Johannes Schindelin @ 2006-06-25 14:11 UTC (permalink / raw)
To: Matthias Lederhofer; +Cc: Junio C Hamano, git
In-Reply-To: <E1FuV62-0004Jd-Ve@moooo.ath.cx>
Hi,
On Sun, 25 Jun 2006, Matthias Lederhofer wrote:
> With the environment variable GIT_TRACE set git will show
> - alias expansion
> - built-in command execution
> - external command execution
> on stderr.
Nice.
Ciao,
Dscho
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.
^ permalink raw reply
* Re: [PATCH] GIT_TRACE: show which built-in/external commands are executed
From: Petr Baudis @ 2006-06-25 14:22 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Matthias Lederhofer, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.63.0606251607090.29667@wbgn013.biozentrum.uni-wuerzburg.de>
Hi,
Dear diary, on Sun, Jun 25, 2006 at 04:11:48PM CEST, I got a letter
where Johannes Schindelin <Johannes.Schindelin@gmx.de> said that...
> 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.
actually this is a myth - not two fork()s since 'git' has no reason to
fork; only two execve()s in line after a single fork().
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
A person is just about as big as the things that make them angry.
^ permalink raw reply
* Re: [Patch] trap: exit: invalid signal specification
From: S.Çağlar Onur @ 2006-06-25 14:33 UTC (permalink / raw)
To: Yakov Lerner; +Cc: git
In-Reply-To: <f36b08ee0606241311h399c42b0h11638f14d6f54bd5@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 659 bytes --]
Cumartesi 24 Haziran 2006 23:11 tarihinde şunları yazmıştınız:
> But in the commandline you are patching, 'exit' keyword
> is not bash signal name,
Pff, you are completely right. I'm currently using git-1.2.6 which has "exit"
signal (git-clone.sh: trap 'err=$?; cd ..; rm -r "$D"; exit $err' exit )
causing that trouble but in git-1.4.0 its converted to 0 (git-clone.sh:
trap 'err=$?; cd ..; rm -r "$D"; exit $err' 0) and i didn't realize until
look again. Sorry for noise :(
--
S.Çağlar Onur <caglar@pardus.org.tr>
http://cekirdek.pardus.org.tr/~caglar/
Linux is like living in a teepee. No Windows, no Gates and an Apache in house!
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] Git.pm build: Fix quoting and missing GIT-CFLAGS dependency
From: Petr Baudis @ 2006-06-25 15:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Chris Wright, Linus Torvalds, git
In-Reply-To: <7vac82q6mb.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Sun, Jun 25, 2006 at 05:03:24AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> During our a handful piecemeal patch exchange back-and-forth on
> the list, most of the patches did not apply mechanically, so I
> rolled them up and have pushed out the result in "pu" and it
> will mirror out shortly. I am reasonably sure it is in much
> better shape than 24 hours ago; could you double check the
> result for me please?
It looks good; I don't like the makefile changes a lot but more on that
below.
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")
..snip..
> - RPM target -- we probably acquired a new build-dependency in
> which case the .spec file needs to be updated;
..snip..
> I think we have cleared SITELIBARCH, and Git.xs building is in
> testable state for wider audience. The remaining hurdles are to
> make sure the RPM target is still sensible, and fix the test
> scheme.
>
> Now, I am clueless about RPM, so help is very much appreciated.
Chris, could you help, please? Do we need to insert anything special
to builddeps if we build own Perl module?
> About the testsuite, I think with the way git-fmt-merge-msg (and
> other Perl scripts that will use Git.pm) is munged on the
> initial line "#!/usr/bin/perl -I$(installedpath)", the test
> scheme is seriously broken. To see how yourself, have a good
> working version of Git.pm and friends in the path your
> git-fmt-merge-msg's first line points at, apply the following
> patch to perl/Git.pm in your source tree and run "make test".
> It will pass t5700-clone-reference.sh test, which does "git
> pull" (and uses git-fmt-merge-msg) without problems X-<.
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.
> The additional dependency to perl/Makefile is needed regardless
> of this tentative fix -- you cannot run make -C perl before
> building perl/Makefile.
Yes, that bit shall be Acked-by: Petr Baudis <pasky@suse.cz>
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
A person is just about as big as the things that make them angry.
^ permalink raw reply
* Re: [PATCH] Git.pm: Support for perl/ being built by a different compiler
From: Petr Baudis @ 2006-06-25 15:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk676orjy.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Sun, Jun 25, 2006 at 05:14:09AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> Petr Baudis <pasky@suse.cz> writes:
> > This is not really meant for an application yet since it's not clear
> > if it will alone help anything.
It appears that it did have helped and all went well, according to dst_.
> I would question why the rest of git is not built with Sun CC as
> well if that is the case.
< dst_> Three points: (1) Gcc comes along with solaris, sun cc not.
< dst_> (2) Git used a lot of GCC'isms whan I last checked a few weeks ago
< dst_> (3) a lot of other software will not ompile out of the box with suncc, so gcc is usually the safer choice
Of course (1) is troublesome since this means you can't build Git on
Solaris without installing Sun CC - I have no other answer to this than
that Solaris is horribly broken. :-( Perhaps ExtUtils::MakeMaker could
be convinced to build with gcc, I'm not sure.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
A person is just about as big as the things that make them angry.
^ permalink raw reply
* [PATCH] git-grep: allow patterns starting with -
From: Matthias Lederhofer @ 2006-06-25 15:38 UTC (permalink / raw)
To: git
Signed-off-by: Matthias Lederhofer <matled@gmx.net>
---
I did not find another way to use patterns starting with -, if it is
possible without the patch please tell me and ignore the patch :)
example:
% git grep -- --bla HEAD HEAD~1 -- --foo
HEAD:--foo/bla:test --bla foo
builtin-grep.c | 7 ++++++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/builtin-grep.c b/builtin-grep.c
index 2e7986c..d0677cc 100644
--- a/builtin-grep.c
+++ b/builtin-grep.c
@@ -817,8 +817,13 @@ int cmd_grep(int argc, const char **argv
}
usage(builtin_grep_usage);
}
- if (!strcmp("--", arg))
+ if (!strcmp("--", arg)) {
+ if (!opt.pattern_list && argc > 0) {
+ argc--; argv++;
+ add_pattern(&opt, *argv, "command line", 0);
+ }
break;
+ }
if (*arg == '-')
usage(builtin_grep_usage);
--
1.4.1.rc1.g29f4a-dirty
^ permalink raw reply related
* Re: On boolean configuration variables...
From: Anand Kumria @ 2006-06-25 15:41 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0606251553110.29667@wbgn013.biozentrum.uni-wuerzburg.de>
On Sun, Jun 25, 2006 at 04:00:34PM +0200, Johannes Schindelin wrote:
> Hi,
>
> On Sun, 25 Jun 2006, Anand Kumria wrote:
>
> > Allowing 'yes' and 'no' to equal 'true' and 'false' respectively sounds
> > pretty sane and user-friendly.
> >
> > Why wouldn't you want to do that?
>
> 'Cause you'd have to add "maybe", too ;-)
>
> Seriously, there is a subtle side to booleans, which is the reason that
> they typically take on only "false" and "true": Consider the question "Is
> the box not red?". If the answer is "yes", I do not know if "yes, the box
> is red" or "yes, the box is not red".
>
> "true" and "false" are less ambiguous.
"True, the box is red" and "true, the box is not red" are just as ambiguous.
It is always ambiguous if you allow a qualifier.
Cheers,
Anand
--
`When any government, or any church for that matter, undertakes to say to
its subjects, "This you may not read, this you must not see, this you are
forbidden to know," the end result is tyranny and oppression no matter how
holy the motives' -- Robert A Heinlein, "If this goes on --"
^ permalink raw reply
* Re: [PATCH] git-grep: allow patterns starting with -
From: Timo Hirvonen @ 2006-06-25 15:47 UTC (permalink / raw)
To: Matthias Lederhofer; +Cc: git
In-Reply-To: <E1FuWh7-0008Ry-HX@moooo.ath.cx>
Matthias Lederhofer <matled@gmx.net> wrote:
> Signed-off-by: Matthias Lederhofer <matled@gmx.net>
> ---
> I did not find another way to use patterns starting with -, if it is
> possible without the patch please tell me and ignore the patch :)
> example:
> % git grep -- --bla HEAD HEAD~1 -- --foo
> HEAD:--foo/bla:test --bla foo
git grep -e --bla
It's not very well documented.
--
http://onion.dynserv.net/~timo/
^ permalink raw reply
* [PATCH] correct documentation for git grep
From: Matthias Lederhofer @ 2006-06-25 16:07 UTC (permalink / raw)
To: Timo Hirvonen; +Cc: git
In-Reply-To: <20060625184757.f8273820.tihirvon@gmail.com>
---
> git grep -e --bla
>
> It's not very well documented.
Let's change that!
Documentation/git-grep.txt | 7 ++++++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-grep.txt b/Documentation/git-grep.txt
index 7b810df..62a8e7f 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>
[<tree>...]
[--] [<path>...]
@@ -71,6 +71,11 @@ OPTIONS
-f <file>::
Read patterns from <file>, one per line.
+-e::
+ The next parameter is the pattern. This option has to be
+ used for patterns starting with - and should be used in
+ scripts passing user input to grep.
+
`<tree>...`::
Search blobs in the trees for specified patterns.
--
1.4.1.rc1.gc594
^ permalink raw reply related
* Re: [PATCH] GIT_TRACE: show which built-in/external commands are executed
From: Matthias Lederhofer @ 2006-06-25 16:10 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0606251607090.29667@wbgn013.biozentrum.uni-wuerzburg.de>
> Hi,
>
> On Sun, 25 Jun 2006, Matthias Lederhofer wrote:
>
> > With the environment variable GIT_TRACE set git will show
> > - alias expansion
> > - built-in command execution
> > - external command execution
> > on stderr.
>
> Nice.
Thanks :)
> 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.
git <command> is to be used by the user if he wants aliases, default
parameters and other fancy stuff.
Using this policy the user can always get the normal behaviour and it
is possible to shadown built-in commands etc.
^ permalink raw reply
* Re: [PATCH] git-grep: allow patterns starting with -
From: Matthias Lederhofer @ 2006-06-25 16:18 UTC (permalink / raw)
To: Timo Hirvonen; +Cc: git
In-Reply-To: <20060625184757.f8273820.tihirvon@gmail.com>
> Matthias Lederhofer <matled@gmx.net> wrote:
>
> > Signed-off-by: Matthias Lederhofer <matled@gmx.net>
> > ---
> > I did not find another way to use patterns starting with -, if it is
> > possible without the patch please tell me and ignore the patch :)
> > example:
> > % git grep -- --bla HEAD HEAD~1 -- --foo
> > HEAD:--foo/bla:test --bla foo
>
> git grep -e --bla
Perhaps the original patch may be applied anyways for consistency with
the GNU grep? :)
But it's really not important to me and well, having -- twice in the
command line is a bit strange too.
^ permalink raw reply
* Re: [RFC] GIT user survey
From: Sam Ravnborg @ 2006-06-25 16:20 UTC (permalink / raw)
To: Paolo Ciarrocchi; +Cc: Martin Langhoff, Git Mailing List
In-Reply-To: <4d8e3fd30606250347o47c4b200t6feb0406bfa535fa@mail.gmail.com>
Hi
> 2. What is your preferred language?
You need to rephase this so it tell for what purpose.
Sam
^ permalink raw reply
* Re: [RFC] git-fetch - repack in the background after fetching
From: Linus Torvalds @ 2006-06-25 17:29 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Martin Langhoff, git, junkio
In-Reply-To: <Pine.LNX.4.63.0606251122260.29667@wbgn013.biozentrum.uni-wuerzburg.de>
On Sun, 25 Jun 2006, Johannes Schindelin wrote:
>
> On Sat, 24 Jun 2006, Linus Torvalds wrote:
>
> > However, the more worrisome thing about background repacking is that while
> > it should be safe against normal users, if you have two _repacks_ at the
> > same time, they can decide to remove each others packs. Yeah, yeah, that's
> > pretty damn unlikely, but hey, "pretty damn unlikely" is not "impossible".
>
> Why not introduce a lock file for repack?
You can do that. The problem is, lock-files are really hard to do
right, and portably. Especially from scripts.
But _I_ think the basic issue is that it's wrong to even try to do this
background repack.
Git does explicit repacking. That's just how it is. If the worry is that
people forget to pack often enough, why not just have the "git pull"
script _tell_ the user, something like
if [lots of unpacked objects]; then
echo "You've got a boatload of unpacked objects now."
echo "Maybe you'd like to repack using"
echo " git repack -a -d"
echo "Thank you for not smoking"
fi >&2
which is educational on so many levels.
Linus
^ permalink raw reply
* Re: What's in git.git
From: Linus Torvalds @ 2006-06-25 17:47 UTC (permalink / raw)
To: Junio C Hamano, Timo Hirvonen; +Cc: Git Mailing List
In-Reply-To: <7v7j35wp84.fsf@assigned-by-dhcp.cox.net>
On Sun, 25 Jun 2006, Junio C Hamano wrote:
>
> Timo Hirvonen:
> Clean up diff.c
THIS IS CRAP!
Dammit, anybody who claims that casting a constant string to "(char *)" is
a _cleanup_ is doing something seriously wrong.
That's crap, crap, crap, CRAP!
If the "cleanup" was about hiding compiler warnings, then dammit, those
warnings should be fixed by fixing the code, not by casting the warning
away but leaving the broken code.
If the ptr really is never accessed, and doesn't matter, then don't use a
constant empty string, use NULL.
And if it _is_ accessed, then casting a constant string to "char *" is
_wrong_.
The whole and only point about the "const" warnings is not to hide them,
but to fix the code. If you're not going to fix the code, then you
shouldn't ask the compiler to warn about it, it's that simple. Adding
bogus casts is not the answer.
I really hate how many _bogus_ casts we're growing. Casts are one of the
most important features of C (it's what allows you to break the type
system if you need to, and turns C into the truly extensible language it
is), but they should be used with reverence and care, not to shut up a
compiler.
I'm _especially_ disgusted by how this was claimed to be a "cleanup".
Adding a cast is _never_ a cleanup.
Dammit, don't do crap like this!
THIS is a cleanup:
- char *prefix = "";
+ const char *prefix = "";
but THESE are total and utter CRAP:
- mf->ptr = ""; /* does not matter */
+ mf->ptr = (char *)""; /* does not matter */
- s->data = "";
+ s->data = (char *)"";
and we're better off with the warning than with the new code.
I suspect that both could have been made to use NULL instead to indicate
that no pointer exists.
Linus
^ permalink raw reply
* Re: [RFC] git-fetch - repack in the background after fetching
From: linux @ 2006-06-25 17:53 UTC (permalink / raw)
To: git
How about a post-fetch hook script that can do this? With an example
of either printing a message or repacking in the background?
procmail includes a lockfile(1) utility useful for shell scripts, but
it also wouldn't be hard to add a "git-lock-file <file> <command>..."
utility that would create the given lock file, fork the command, and
clean up again when it exited, relaying its exit status.
(I can write one if there's interest.)
I agree with Linus that *defaulting* to background repack has problems,
but it does seem useful to provide enough hooks to easily implement
the option. Even printing the warning in a script seems like it would
simplify internationalization, and different sites (e.g. reiserfs
developers) might have different policies about what constitutes
"a boatload".
^ permalink raw reply
* Re: What's in git.git
From: Timo Hirvonen @ 2006-06-25 18:07 UTC (permalink / raw)
To: Linus Torvalds; +Cc: junkio, git
In-Reply-To: <Pine.LNX.4.64.0606251033030.3747@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> wrote:
> On Sun, 25 Jun 2006, Junio C Hamano wrote:
> >
> > Timo Hirvonen:
> > Clean up diff.c
>
> THIS IS CRAP!
>
> Dammit, anybody who claims that casting a constant string to "(char *)" is
> a _cleanup_ is doing something seriously wrong.
>
> That's crap, crap, crap, CRAP!
Sorry. It got really annoying to skip over the same compiler warnings
in vim's quickfix window many times. At that time I just wanted to
focus on the code I was writing.
> but THESE are total and utter CRAP:
>
> - mf->ptr = ""; /* does not matter */
> + mf->ptr = (char *)""; /* does not matter */
> - s->data = "";
> + s->data = (char *)"";
>
> and we're better off with the warning than with the new code.
>
> I suspect that both could have been made to use NULL instead to indicate
> that no pointer exists.
I'll look into this.
--
http://onion.dynserv.net/~timo/
^ permalink raw reply
* Re: What's in git.git
From: Linus Torvalds @ 2006-06-25 18:43 UTC (permalink / raw)
To: Timo Hirvonen; +Cc: junkio, git
In-Reply-To: <20060625210724.934617c4.tihirvon@gmail.com>
On Sun, 25 Jun 2006, Timo Hirvonen wrote:
> >
> > I suspect that both could have been made to use NULL instead to indicate
> > that no pointer exists.
>
> I'll look into this.
An alternative is to really mark the char pointer structure members const.
That is often the preferred thing to do, if usage allows it.
The biggest problem I've traditionally had with structure members that are
"const char *" has ironically been that the standard C definition of
"free()" is misdesigned.
"free()" should take a "const volatile void *", not just a "void *". As it
is, you often have to cast things to free() just to avoid the warning
about discarding qualifiers. Which is really sad.
It's perfectly valid to do something like
struct xyzzy {
const char *member;
..
};
s->member = strdup(string);
..
free(s->member);
free(s)
but sadly, that member free generates a (bogus) warning.
Of course, we should probably do a "xfree()" anyway, to match our
"x[c|re]alloc()".
Linus
^ permalink raw reply
* Re: PPC SHA-1 Updates in "pu"
From: Randal L. Schwartz @ 2006-06-25 18:46 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Petr Baudis, git, Linus Torvalds
In-Reply-To: <Pine.LNX.4.63.0606251537450.29667@wbgn013.biozentrum.uni-wuerzburg.de>
>>>>> "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.
--
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] correct documentation for git grep
From: Johannes Schindelin @ 2006-06-25 23:10 UTC (permalink / raw)
To: Matthias Lederhofer; +Cc: Timo Hirvonen, git
In-Reply-To: <E1FuX8l-0001H5-2z@moooo.ath.cx>
Hi,
On Sun, 25 Jun 2006, Matthias Lederhofer wrote:
> +-e::
> + The next parameter is the pattern. This option has to be
> + used for patterns starting with - and should be used in
> + scripts passing user input to grep.
... and by the far the most common use is to pass more than one pattern.
Also, the usage is "[-e] <pattern> [-e <pattern>...]".
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