* [PATCH 10] autoconf: Write how to use ./configure generated file in git build process
From: Jakub Narebski @ 2006-06-30 12:39 UTC (permalink / raw)
To: git
In-Reply-To: <200606301437.52590.jnareb@gmail.com>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
Probably there is better way to do this.
configure.ac | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/configure.ac b/configure.ac
index e387f5b..ef310ee 100644
--- a/configure.ac
+++ b/configure.ac
@@ -54,3 +54,9 @@ AC_CONFIG_FILES(["${config_file}":"${con
AC_OUTPUT
rm -f "${config_append}"
+
+cat <<_ACEOF
+
+Add '-include ${config_file}' to your config.mak,
+or rename ${config_file} to config.mak
+_ACEOF
--
1.4.0
^ permalink raw reply related
* [PATCH 9] autoconf: Cleanup generation of temporary "append" file
From: Jakub Narebski @ 2006-06-30 12:37 UTC (permalink / raw)
To: git
In-Reply-To: <200606300232.34472.jnareb@gmail.com>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
configure.ac | 7 ++++---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/configure.ac b/configure.ac
index 799bc87..e387f5b 100644
--- a/configure.ac
+++ b/configure.ac
@@ -10,7 +10,7 @@ config_file=config.mak.auto
config_append=config.mak.append
config_in=config.mak.in
-echo "# ${config_append}. Generated by configure." >> "${config_append}"
+echo "# ${config_append}. Generated by configure." > "${config_append}"
# Definitions of macros
# MY_APPEND_LINE(LINE)
@@ -50,6 +50,7 @@ AC_CHECK_FUNC(setenv,,MY_APPEND_LINE(NO_
# Output files
-AC_CONFIG_FILES(["${config_file}":"${config_in}":"${config_append}"],
-[rm -f "${config_append}"])
+AC_CONFIG_FILES(["${config_file}":"${config_in}":"${config_append}"])
AC_OUTPUT
+
+rm -f "${config_append}"
--
1.4.0
^ permalink raw reply related
* Re: [PATCH] consider previous pack undeltified object state only when reusing delta data
From: Andreas Ericsson @ 2006-06-30 12:28 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Nicolas Pitre, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.63.0606301144450.29667@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
> Hi,
>
> On Thu, 29 Jun 2006, Nicolas Pitre wrote:
>
>
>>Without this there would never be a chance to improve packing for
>>previously undeltified objects.
>
>
> Earlier this year, I was quite surprised to learn that multiple repackings
> actually improved packing. Does that patch mean this feature is gone?
>
The patch Linus sent removes that feature. This one re-introduces it.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] autoconf: Use autoconf to write installation directories to config.mak
From: Andreas Ericsson @ 2006-06-30 12:18 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e80lnq$9mi$1@sea.gmane.org>
Jakub Narebski wrote:
> Matthias Lederhofer wrote:
>
>
>>>This is beginning of patch series introducing installation configuration
>>>using autoconf (and no other autotools) to git. The idea is to generate
>>>config.mak using ./configure (generated from configure.ac) from
>>>config.mak.in, so one can use autoconf as an _alternative_ to ordinary
>>>Makefile, and creating one's own config.mak.
>>
>>Are you sure this should be named config.mak? From INSTALL:
>>
>>>You can place local settings in config.mak and the Makefile
>>>will include them. Note that config.mak is not distributed;
>>>the name is reserved for local settings.
>>
>>So with another filename either include it
>>- before config.mak: the user may override ./configure options with
>> config.mak
>>- after config.mak: ./configure overrides config.mak
>
>
> The idea was to use ./configure to _generate_ config.mak, which the user can
> then edit.
>
This is bad, since it forces users to do one thing first and then do
what they're used to. Better to have the script add
-include config.mak.autogen
LAST in config.mak, unless it's already in the file and generate
config.mak.autogen with configure.
Since Make does things bottoms-up (much like swedish students and
midsummer celebrators), the previous hand-edited defaults in config.mak
will beat the ones in config.mak.autogen (a good thing).
> But perhaps using another filename for results of ./configure script
> (and including it in main Makefile) would be better idea.
>
>
>>At least do not overwrite config.mak if it exists.
>
>
> But one might want to run ./configure with different options, to finally
> arrive at the set which is satisfactionary. So unless some magic to detect
> if config.mak was generated from ./configure script, or generated by user
> is used...
>
grep -q autogen config.mak || \
echo "-include config.mak.autogen" >> config.mak
I wouldn't want my long-standing, functioning config.mak overwritten,
but I *might* be interested in trying some of the options provided by
./configure.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH 4/4] save another call to git-update-index
From: Alex Riesen @ 2006-06-30 11:33 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Alex Riesen, git
In-Reply-To: <Pine.LNX.4.63.0606301155050.29667@wbgn013.biozentrum.uni-wuerzburg.de>
On 6/30/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > >
> > > FYI I've been just battling this pipe for a couple of hours. The first
> > > steps were easy, but since I wanted to do it incrementally, the index has
> > > to be written every so often, and I seem not to be able to get that right.
> > >
> > Are you sure? Does something use the index between starting update-index
> > pipe and pclose?
>
> Yes, I am sure you have to write the cache before git-read-tree and
> git-write-tree ;-)
Indeed :) That's what pclose before git-write-tree is for (which was not the
case as I published this optimization. Noticed it later. The last patch series
has pclose before git-write-tree)
> I must have done something severely wrong, though,
> since there are not too many places where they are called. The problem is
> more likely that the cache has to be _read_, and _before_ the first
> substituted call to git-update-index.
git-write-tree change index?
^ permalink raw reply
* Re: [PATCH] git-grep: --and to combine patterns with and instead of or
From: Matthias Lederhofer @ 2006-06-30 10:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v3bdnkrfb.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> I see you are trying hard to think of a way to justify your
> original prefix "--and" (or --FOO) implementation, but I simply
> do not see much point in that. I doubt changing the default
> operator from --or to --and is less confusing than changing the
> precedence for the users, so you would hear the same "I
> personally feel FOO should not even exist" objection from me.
It just happens to make more sense to me and I don't see a reason not to
add this. If no one else is interested in this I'll just stop arguing :)
Here again an overview of the arguments if anyone is interested:
- Less to type for common searches using only AND (or more ANDs than
ORs).
- Easy to implement (both with and without extended expressions).
- AND/* is the normal implicit operator in other contexts than grep
(math).
- The high precedence operator (AND) should be implicit rather than
the low precedence one (OR) (so this is only fulfilled when the
option is used).
^ permalink raw reply
* Re: [PATCH] git-grep: boolean expression on pattern matching.
From: Junio C Hamano @ 2006-06-30 10:29 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e82u4l$fvb$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
>>
>> $ git grep -e _PATTERN --and \( -e atom -e token \)
>
> And where is documentation update?
Heh, real men do not do documentation ;-).
I am going to bed now, and am hoping a kind soul would be
sending out a patch while I am sleeping.
^ permalink raw reply
* Re: GIt.xs merge status
From: Junio C Hamano @ 2006-06-30 10:26 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0606301150250.29667@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> I'll try it (it's in pu, right?). Note that breaking git-fmt-merge-msg
> might be a good way to force somebody to rewrite it in C ;-)
It would hopefully not come to that (and that is I am playing
safe and keeping the series in "pu"), and even if it did, I am
hoping that Perl is so ubiquitous that people would fix it up
quickly.
^ permalink raw reply
* Re: [PATCH] git-grep: boolean expression on pattern matching.
From: Jakub Narebski @ 2006-06-30 10:24 UTC (permalink / raw)
To: git
In-Reply-To: <7vsllnj6rh.fsf_-_@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> This extends the behaviour of git-grep when multiple -e options
> are given. So far, we allowed multiple -e to behave just like
> regular grep with multiple -e, i.e. the patterns are OR'ed
> together.
>
> With this change, you can also have multiple patterns AND'ed
> together, or form boolean expressions, like this (the
> parentheses are quoted from the shell in this example):
>
> $ git grep -e _PATTERN --and \( -e atom -e token \)
And where is documentation update?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* [PATCH] git-grep: boolean expression on pattern matching.
From: Junio C Hamano @ 2006-06-30 10:08 UTC (permalink / raw)
To: Matthias Lederhofer; +Cc: git
In-Reply-To: <7v3bdnkrfb.fsf@assigned-by-dhcp.cox.net>
This extends the behaviour of git-grep when multiple -e options
are given. So far, we allowed multiple -e to behave just like
regular grep with multiple -e, i.e. the patterns are OR'ed
together.
With this change, you can also have multiple patterns AND'ed
together, or form boolean expressions, like this (the
parentheses are quoted from the shell in this example):
$ git grep -e _PATTERN --and \( -e atom -e token \)
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* OR'ing together, admittably, can be done easily by saying
something like -e 'atom\|token', so being able to say --and
as you argued is of more practical importance, and doing
boolean expression like this might be too much frill.
Only very lightly tested; it is obviously not slated for
1.4.1.
builtin-grep.c | 378 ++++++++++++++++++++++++++++++++++++++++++++++++--------
1 files changed, 327 insertions(+), 51 deletions(-)
diff --git a/builtin-grep.c b/builtin-grep.c
index 2e7986c..70b1fd2 100644
--- a/builtin-grep.c
+++ b/builtin-grep.c
@@ -82,17 +82,47 @@ static int pathspec_matches(const char *
return 0;
}
+enum grep_pat_token {
+ GREP_PATTERN,
+ GREP_AND,
+ GREP_OPEN_PAREN,
+ GREP_CLOSE_PAREN,
+ GREP_NOT,
+ GREP_OR,
+};
+
struct grep_pat {
struct grep_pat *next;
const char *origin;
int no;
+ enum grep_pat_token token;
const char *pattern;
regex_t regexp;
};
+enum grep_expr_node {
+ GREP_NODE_ATOM,
+ GREP_NODE_NOT,
+ GREP_NODE_AND,
+ GREP_NODE_OR,
+};
+
+struct grep_expr {
+ enum grep_expr_node node;
+ union {
+ struct grep_pat *atom;
+ struct grep_expr *unary;
+ struct {
+ struct grep_expr *left;
+ struct grep_expr *right;
+ } binary;
+ } u;
+};
+
struct grep_opt {
struct grep_pat *pattern_list;
struct grep_pat **pattern_tail;
+ struct grep_expr *pattern_expression;
regex_t regexp;
unsigned linenum:1;
unsigned invert:1;
@@ -105,43 +135,224 @@ #define GREP_BINARY_DEFAULT 0
#define GREP_BINARY_NOMATCH 1
#define GREP_BINARY_TEXT 2
unsigned binary:2;
+ unsigned extended:1;
int regflags;
unsigned pre_context;
unsigned post_context;
};
static void add_pattern(struct grep_opt *opt, const char *pat,
- const char *origin, int no)
+ const char *origin, int no, enum grep_pat_token t)
{
struct grep_pat *p = xcalloc(1, sizeof(*p));
p->pattern = pat;
p->origin = origin;
p->no = no;
+ p->token = t;
*opt->pattern_tail = p;
opt->pattern_tail = &p->next;
p->next = NULL;
}
+static void compile_regexp(struct grep_pat *p, struct grep_opt *opt)
+{
+ int err = regcomp(&p->regexp, p->pattern, opt->regflags);
+ if (err) {
+ char errbuf[1024];
+ char where[1024];
+ if (p->no)
+ sprintf(where, "In '%s' at %d, ",
+ p->origin, p->no);
+ else if (p->origin)
+ sprintf(where, "%s, ", p->origin);
+ else
+ where[0] = 0;
+ regerror(err, &p->regexp, errbuf, 1024);
+ regfree(&p->regexp);
+ die("%s'%s': %s", where, p->pattern, errbuf);
+ }
+}
+
+#if DEBUG
+static inline void indent(int in)
+{
+ int i;
+ for (i = 0; i < in; i++) putchar(' ');
+}
+
+static void dump_pattern_exp(struct grep_expr *x, int in)
+{
+ switch (x->node) {
+ case GREP_NODE_ATOM:
+ indent(in);
+ puts(x->u.atom->pattern);
+ break;
+ case GREP_NODE_NOT:
+ indent(in);
+ puts("--not");
+ dump_pattern_exp(x->u.unary, in+1);
+ break;
+ case GREP_NODE_AND:
+ dump_pattern_exp(x->u.binary.left, in+1);
+ indent(in);
+ puts("--and");
+ dump_pattern_exp(x->u.binary.right, in+1);
+ break;
+ case GREP_NODE_OR:
+ dump_pattern_exp(x->u.binary.left, in+1);
+ indent(in);
+ puts("--or");
+ dump_pattern_exp(x->u.binary.right, in+1);
+ break;
+ }
+}
+
+static void looking_at(const char *msg, struct grep_pat **list)
+{
+ struct grep_pat *p = *list;
+ fprintf(stderr, "%s: looking at ", msg);
+ if (!p)
+ fprintf(stderr, "empty\n");
+ else
+ fprintf(stderr, "<%s>\n", p->pattern);
+}
+#else
+#define looking_at(a,b) do {} while(0)
+#endif
+
+static struct grep_expr *compile_pattern_expr(struct grep_pat **);
+static struct grep_expr *compile_pattern_atom(struct grep_pat **list)
+{
+ struct grep_pat *p;
+ struct grep_expr *x;
+
+ looking_at("atom", list);
+
+ p = *list;
+ switch (p->token) {
+ case GREP_PATTERN: /* atom */
+ x = xcalloc(1, sizeof (struct grep_expr));
+ x->node = GREP_NODE_ATOM;
+ x->u.atom = p;
+ *list = p->next;
+ return x;
+ case GREP_OPEN_PAREN:
+ *list = p->next;
+ x = compile_pattern_expr(list);
+ if (!x)
+ return NULL;
+ if (!*list || (*list)->token != GREP_CLOSE_PAREN)
+ die("unmatched parenthesis");
+ *list = (*list)->next;
+ return x;
+ default:
+ return NULL;
+ }
+}
+
+static struct grep_expr *compile_pattern_not(struct grep_pat **list)
+{
+ struct grep_pat *p;
+ struct grep_expr *x;
+
+ looking_at("not", list);
+
+ p = *list;
+ switch (p->token) {
+ case GREP_NOT:
+ if (!p->next)
+ die("--not not followed by pattern expression");
+ *list = p->next;
+ x = xcalloc(1, sizeof (struct grep_expr));
+ x->node = GREP_NODE_NOT;
+ x->u.unary = compile_pattern_not(list);
+ if (!x->u.unary)
+ die("--not followed by non pattern expression");
+ return x;
+ default:
+ return compile_pattern_atom(list);
+ }
+}
+
+static struct grep_expr *compile_pattern_and(struct grep_pat **list)
+{
+ struct grep_pat *p;
+ struct grep_expr *x, *y, *z;
+
+ looking_at("and", list);
+
+ x = compile_pattern_not(list);
+ p = *list;
+ if (p && p->token == GREP_AND) {
+ if (!p->next)
+ die("--and not followed by pattern expression");
+ *list = p->next;
+ y = compile_pattern_and(list);
+ if (!y)
+ die("--and not followed by pattern expression");
+ z = xcalloc(1, sizeof (struct grep_expr));
+ z->node = GREP_NODE_AND;
+ z->u.binary.left = x;
+ z->u.binary.right = y;
+ return z;
+ }
+ return x;
+}
+
+static struct grep_expr *compile_pattern_or(struct grep_pat **list)
+{
+ struct grep_pat *p;
+ struct grep_expr *x, *y, *z;
+
+ looking_at("or", list);
+
+ x = compile_pattern_and(list);
+ p = *list;
+ if (x && p && p->token != GREP_CLOSE_PAREN) {
+ y = compile_pattern_or(list);
+ if (!y)
+ die("not a pattern expression %s", p->pattern);
+ z = xcalloc(1, sizeof (struct grep_expr));
+ z->node = GREP_NODE_OR;
+ z->u.binary.left = x;
+ z->u.binary.right = y;
+ return z;
+ }
+ return x;
+}
+
+static struct grep_expr *compile_pattern_expr(struct grep_pat **list)
+{
+ looking_at("expr", list);
+
+ return compile_pattern_or(list);
+}
+
static void compile_patterns(struct grep_opt *opt)
{
struct grep_pat *p;
+
+ /* First compile regexps */
for (p = opt->pattern_list; p; p = p->next) {
- int err = regcomp(&p->regexp, p->pattern, opt->regflags);
- if (err) {
- char errbuf[1024];
- char where[1024];
- if (p->no)
- sprintf(where, "In '%s' at %d, ",
- p->origin, p->no);
- else if (p->origin)
- sprintf(where, "%s, ", p->origin);
- else
- where[0] = 0;
- regerror(err, &p->regexp, errbuf, 1024);
- regfree(&p->regexp);
- die("%s'%s': %s", where, p->pattern, errbuf);
- }
+ if (p->token == GREP_PATTERN)
+ compile_regexp(p, opt);
+ else
+ opt->extended = 1;
}
+
+ if (!opt->extended)
+ return;
+
+ /* Then bundle them up in an expression.
+ * A classic recursive descent parser would do.
+ */
+ p = opt->pattern_list;
+ opt->pattern_expression = compile_pattern_expr(&p);
+#if DEBUG
+ dump_pattern_exp(opt->pattern_expression, 0);
+#endif
+ if (p)
+ die("incomplete pattern expression: %s", p->pattern);
}
static char *end_of_line(char *cp, unsigned long *left)
@@ -196,6 +407,79 @@ static int fixmatch(const char *pattern,
}
}
+static int match_one_pattern(struct grep_opt *opt, struct grep_pat *p, char *bol, char *eol)
+{
+ int hit = 0;
+ regmatch_t pmatch[10];
+
+ if (!opt->fixed) {
+ regex_t *exp = &p->regexp;
+ hit = !regexec(exp, bol, ARRAY_SIZE(pmatch),
+ pmatch, 0);
+ }
+ else {
+ hit = !fixmatch(p->pattern, bol, pmatch);
+ }
+
+ if (hit && opt->word_regexp) {
+ /* Match beginning must be either
+ * beginning of the line, or at word
+ * boundary (i.e. the last char must
+ * not be alnum or underscore).
+ */
+ if ((pmatch[0].rm_so < 0) ||
+ (eol - bol) <= pmatch[0].rm_so ||
+ (pmatch[0].rm_eo < 0) ||
+ (eol - bol) < pmatch[0].rm_eo)
+ die("regexp returned nonsense");
+ if (pmatch[0].rm_so != 0 &&
+ word_char(bol[pmatch[0].rm_so-1]))
+ hit = 0;
+ if (pmatch[0].rm_eo != (eol-bol) &&
+ word_char(bol[pmatch[0].rm_eo]))
+ hit = 0;
+ }
+ return hit;
+}
+
+static int match_expr_eval(struct grep_opt *opt,
+ struct grep_expr *x,
+ char *bol, char *eol)
+{
+ switch (x->node) {
+ case GREP_NODE_ATOM:
+ return match_one_pattern(opt, x->u.atom, bol, eol);
+ break;
+ case GREP_NODE_NOT:
+ return !match_expr_eval(opt, x->u.unary, bol, eol);
+ case GREP_NODE_AND:
+ return (match_expr_eval(opt, x->u.binary.left, bol, eol) &&
+ match_expr_eval(opt, x->u.binary.right, bol, eol));
+ case GREP_NODE_OR:
+ return (match_expr_eval(opt, x->u.binary.left, bol, eol) ||
+ match_expr_eval(opt, x->u.binary.right, bol, eol));
+ }
+ die("Unexpected node type (internal error) %d\n", x->node);
+}
+
+static int match_expr(struct grep_opt *opt, char *bol, char *eol)
+{
+ struct grep_expr *x = opt->pattern_expression;
+ return match_expr_eval(opt, x, bol, eol);
+}
+
+static int match_line(struct grep_opt *opt, char *bol, char *eol)
+{
+ struct grep_pat *p;
+ if (opt->extended)
+ return match_expr(opt, bol, eol);
+ for (p = opt->pattern_list; p; p = p->next) {
+ if (match_one_pattern(opt, p, bol, eol))
+ return 1;
+ }
+ return 0;
+}
+
static int grep_buffer(struct grep_opt *opt, const char *name,
char *buf, unsigned long size)
{
@@ -231,46 +515,15 @@ static int grep_buffer(struct grep_opt *
hunk_mark = "--\n";
while (left) {
- regmatch_t pmatch[10];
char *eol, ch;
int hit = 0;
- struct grep_pat *p;
eol = end_of_line(bol, &left);
ch = *eol;
*eol = 0;
- for (p = opt->pattern_list; p; p = p->next) {
- if (!opt->fixed) {
- regex_t *exp = &p->regexp;
- hit = !regexec(exp, bol, ARRAY_SIZE(pmatch),
- pmatch, 0);
- }
- else {
- hit = !fixmatch(p->pattern, bol, pmatch);
- }
+ hit = match_line(opt, bol, eol);
- if (hit && opt->word_regexp) {
- /* Match beginning must be either
- * beginning of the line, or at word
- * boundary (i.e. the last char must
- * not be alnum or underscore).
- */
- if ((pmatch[0].rm_so < 0) ||
- (eol - bol) <= pmatch[0].rm_so ||
- (pmatch[0].rm_eo < 0) ||
- (eol - bol) < pmatch[0].rm_eo)
- die("regexp returned nonsense");
- if (pmatch[0].rm_so != 0 &&
- word_char(bol[pmatch[0].rm_so-1]))
- hit = 0;
- if (pmatch[0].rm_eo != (eol-bol) &&
- word_char(bol[pmatch[0].rm_eo]))
- hit = 0;
- }
- if (hit)
- break;
- }
/* "grep -v -e foo -e bla" should list lines
* that do not have either, so inversion should
* be done outside.
@@ -452,6 +705,8 @@ static int external_grep(struct grep_opt
char *argptr = randarg;
struct grep_pat *p;
+ if (opt->extended)
+ return -1;
len = nr = 0;
push_arg("grep");
if (opt->fixed)
@@ -801,16 +1056,36 @@ int cmd_grep(int argc, const char **argv
/* ignore empty line like grep does */
if (!buf[0])
continue;
- add_pattern(&opt, strdup(buf), argv[1], ++lno);
+ add_pattern(&opt, strdup(buf), argv[1], ++lno,
+ GREP_PATTERN);
}
fclose(patterns);
argv++;
argc--;
continue;
}
+ if (!strcmp("--not", arg)) {
+ add_pattern(&opt, arg, "command line", 0, GREP_NOT);
+ continue;
+ }
+ if (!strcmp("--and", arg)) {
+ add_pattern(&opt, arg, "command line", 0, GREP_AND);
+ continue;
+ }
+ if (!strcmp("--or", arg))
+ continue; /* no-op */
+ if (!strcmp("(", arg)) {
+ add_pattern(&opt, arg, "command line", 0, GREP_OPEN_PAREN);
+ continue;
+ }
+ if (!strcmp(")", arg)) {
+ add_pattern(&opt, arg, "command line", 0, GREP_CLOSE_PAREN);
+ continue;
+ }
if (!strcmp("-e", arg)) {
if (1 < argc) {
- add_pattern(&opt, argv[1], "-e option", 0);
+ add_pattern(&opt, argv[1], "-e option", 0,
+ GREP_PATTERN);
argv++;
argc--;
continue;
@@ -824,7 +1099,8 @@ int cmd_grep(int argc, const char **argv
/* First unrecognized non-option token */
if (!opt.pattern_list) {
- add_pattern(&opt, arg, "command line", 0);
+ add_pattern(&opt, arg, "command line", 0,
+ GREP_PATTERN);
break;
}
else {
--
1.4.1.rc2.gfff62
^ permalink raw reply related
* Re: Incorporating gitweb-xmms2 features in trunk gitweb
From: Jakub Narebski @ 2006-06-30 9:59 UTC (permalink / raw)
To: Sham Chukoury, git
In-Reply-To: <449EF8A9.3080301@xmms.org>
Sham Chukoury <eleusis[@]xmms[.]org> wrote:
> Jakub Narebski wrote:
>> Now (from git 1.4.0) that gitweb is incorporated in main git.git
>> repository, and patches to it are accepted by Junio on git mailing
>> list, I have taken to adding new features to gitweb.
>>
>> I've planned on adding gitweb-xmms2 features (using separate topic
>> branches for each feature, like snapshots, hightlighting, committags).
>> Perhaps we could coordinate efforts?
>
> Coordination sounds great. What do you have in mind? :)
Actually it seems that I wouldn't have much time (at least in near future)
for work on gitweb. The main thing stopping me is that gitweb needs
refactoring before adding (or re-adding) new features, as it is written
partially at least in copy'n'paste style, AND waiting for Git.pm Perly git
interface (I'd like to have perl-only Git.pm and use it in gitweb, but
pasky who develops it uses XS for speed).
An example of such refactoring is your separation of navbar generation
code. Similar work was done by Sven Verdoolaege when introducing in-gitweb
snapshot code in
"gitweb and tar snapshots"
http://marc.theaimsgroup.com/?l=git&m=111909432415478&w=2
http://www.liacs.nl/~sverdool/gitweb.cgi?p=gitweb.git;a=summary
http://www.liacs.nl/~sverdool/gitweb.git#master
In my opinion your navbar code is too tied up with current navbar, while
sverdool is a little too perl-hackerish (e.g. there is only one instance,
i.e. root commit, where "top" part of navbar is not default, i.e. it
lacks "commitdiff" (to parent)).
>> For now from gitweb-xmms2.git I have only cherry-picked "Make CSS
>> readable" commit 561262030d58a6325f500b36d836dbe02a5abc68.
>
> Bear in mind that, since 'forking' (for lack of a better word) from v264, I
> haven't merged any changes from the 'official' gitweb tree.. Last time I
> checked, there's at least one changeset I reimplemented differently (perhaps
> wrongly). I need to go back and see what needs to be fixed properly..
gitweb-xmms2 merged quite cleanly with 1.4.0. It was later changes in next
(among others adding optional "blame" view for blobs, using old navbar
generation) that makes automatic merge fail.
> Going back to the point on coordination - I currently track bugs and feature
> requests for gitweb-xmms2 using the xmms2 bug tracker at
> http://bugs.xmms2.xmms.se (You'll need to select the 'Misc - gitweb' project
> from the dropdown at the top right of the page to see the relevant reports)
Check my two threads on gitweb wishlist features, and plans on refactoring
on git mailing list:
"[RFC] gitweb wishlist and TODO list"
Message-ID: <e79921$u0e$1@sea.gmane.org>
http://permalink.gmane.org/gmane.comp.version-control.git/22213
http://marc.theaimsgroup.com/?l=git&m=115082279425118&w=2
and
"gitweb refactoring"
Message-ID: <e7ed1r$9ve$1@sea.gmane.org>
http://permalink.gmane.org/gmane.comp.version-control.git/22345
http://marc.theaimsgroup.com/?l=git&m=115099031220954&w=2
P.S. Now that gitweb is included in git.git (from git version 1.4.0), you should
have easier to have your patches accepted into gitweb trunk.
--
Jakub Narebski
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH 4/4] save another call to git-update-index
From: Johannes Schindelin @ 2006-06-30 9:56 UTC (permalink / raw)
To: Alex Riesen; +Cc: Alex Riesen, git
In-Reply-To: <81b0412b0606300022k68d13dg8e292d9b768df51c@mail.gmail.com>
Hi,
On Fri, 30 Jun 2006, Alex Riesen wrote:
> On 6/30/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> >
> > FYI I've been just battling this pipe for a couple of hours. The first
> > steps were easy, but since I wanted to do it incrementally, the index has
> > to be written every so often, and I seem not to be able to get that right.
> >
> Are you sure? Does something use the index between starting update-index
> pipe and pclose?
Yes, I am sure you have to write the cache before git-read-tree and
git-write-tree ;-) I must have done something severely wrong, though,
since there are not too many places where they are called. The problem is
more likely that the cache has to be _read_, and _before_ the first
substituted call to git-update-index.
Ciao,
Dscho
^ permalink raw reply
* Re: GIt.xs merge status
From: Johannes Schindelin @ 2006-06-30 9:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Petr Baudis
In-Reply-To: <7vmzbvmny4.fsf_-_@assigned-by-dhcp.cox.net>
Hi,
On Thu, 29 Jun 2006, Junio C Hamano wrote:
> Junio C Hamano <junkio@cox.net> writes:
>
> > - Make sure Git.xs builds and installed result works fine on
> > all platforms we care about, including Cygwin and other
> > non-Linux boxes.
>
> Help wanted from the list here. One thing to note is that I
> understand Pasky is working on not using Devel::PPPort to make
> the code work with 5.6, so if your build dies with problems in
> that area you might want to wait until that is fixed.
I'll try it (it's in pu, right?). Note that breaking git-fmt-merge-msg
might be a good way to force somebody to rewrite it in C ;-)
Note that on my iBook (where I reported the Devel::PPPort problem), I _do_
have perl modules compiled from source, using SWIG. So, there _should_ be
no problem to get it to run (although I have problems with my eyes ever
since I looked into the code generated by SWIG).
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] consider previous pack undeltified object state only when reusing delta data
From: Johannes Schindelin @ 2006-06-30 9:45 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0606292335190.1213@localhost.localdomain>
Hi,
On Thu, 29 Jun 2006, Nicolas Pitre wrote:
> Without this there would never be a chance to improve packing for
> previously undeltified objects.
Earlier this year, I was quite surprised to learn that multiple repackings
actually improved packing. Does that patch mean this feature is gone?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 2/4] make filepairs detachable
From: Alex Riesen @ 2006-06-30 8:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7j2zkrod.fsf@assigned-by-dhcp.cox.net>
On 6/30/06, Junio C Hamano <junkio@cox.net> wrote:
>
> > BTW, is there any chance we get the struct diff_filepair's
> > double-linked? They don't seem to be sorted. Will increase
> > the memory footprint, though.
>
> You do not necessarily have to do things in place. In fact, all
> of the standard diffcore transformers create a new queue, read
> from the old queue and place the filtered or munged result in
> the new queue, swap the global queued_diff variable to point at
> the new one and discard the old queue.
>
> See diff.c::diffcore_apply_filter() for the simplest example.
>
I see. Looks dangerous outside of diff.c though.
^ permalink raw reply
* Re: [PATCH] git-grep: --and to combine patterns with and instead of or
From: Junio C Hamano @ 2006-06-30 7:56 UTC (permalink / raw)
To: Matthias Lederhofer; +Cc: git
In-Reply-To: <E1FwDiI-0007Xp-2s@moooo.ath.cx>
Matthias Lederhofer <matled@gmx.net> writes:
> (Junio: please reply to this one, forgot the Cc in the first one :/)
Huh?
>> I personally feel FOO should not even exist. An option that
>> covers the entire expression to make operator precedence in it
>> sounds quite evil.
>>
>> I would say make --and bind tighter than --or and use parentheses as
>> needed.
> Ok, perhaps changing operator precedence is a bit much. What do you
> think of that then:
> ...
I see you are trying hard to think of a way to justify your
original prefix "--and" (or --FOO) implementation, but I simply
do not see much point in that. I doubt changing the default
operator from --or to --and is less confusing than changing the
precedence for the users, so you would hear the same "I
personally feel FOO should not even exist" objection from me.
^ permalink raw reply
* Re: [PATCH 2/4] make filepairs detachable
From: Junio C Hamano @ 2006-06-30 7:50 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <81b0412b0606300042r24931d9i5fad0e849b8de84c@mail.gmail.com>
"Alex Riesen" <raa.lkml@gmail.com> writes:
> BTW, is there any chance we get the struct diff_filepair's
> double-linked? They don't seem to be sorted. Will increase
> the memory footprint, though.
You do not necessarily have to do things in place. In fact, all
of the standard diffcore transformers create a new queue, read
from the old queue and place the filtered or munged result in
the new queue, swap the global queued_diff variable to point at
the new one and discard the old queue.
See diff.c::diffcore_apply_filter() for the simplest example.
^ permalink raw reply
* Re: [PATCH] git-grep: --and to combine patterns with and instead of or
From: Matthias Lederhofer @ 2006-06-30 7:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7j2zmgbu.fsf@assigned-by-dhcp.cox.net>
(Junio: please reply to this one, forgot the Cc in the first one :/)
Junio C Hamano wrote:
> Matthias Lederhofer <matled@gmx.net> writes:
>
> > OR and AND have precedence, so there are two possibilities, I'd take
> > the first one.
> > 1. OR, AND:
> > This will make it easier to read because OR can be skipped:
> > pat1 pat2 AND pat3 pat4
> > = pat1 OR pat2 AND pat3 OR pat4
> > = (pat1 OR pat2) AND (pat3 OR pat4)
> > 2. AND, OR:
> > This is a bit more logic if you think of AND as * and OR as +.
>
> > ... FOO should not be named --and imo but I don't have any idea
> > for a good name atm.
>
> I personally feel FOO should not even exist. An option that
> covers the entire expression to make operator precedence in it
> sounds quite evil.
>
> I would say make --and bind tighter than --or and use parentheses as
> needed.
Ok, perhaps changing operator precedence is a bit much. What do you
think of that then:
Operator precedence AND, OR. The FOO options changes the default
operator to AND. This also seems quite natural if you think of
AND as * and OR as +:
A B + C D = A * B + C * D = (A * B) + (C * D)
A few examples to get an impression how the command line could look
like:
A OR B OR (C AND D) => A B C AND D
(A OR B OR C) AND D => (A B C) AND D
A AND B AND (C OR D) => -FOO A B (C OR D)
(A AND B AND C) OR D => -FOO A B C OR D
Perhaps we even could use options which are similar to * and +, for
example:
- -* and -+ (-* should not be expanded often but is annoying anyway)
- -. and -+
- -t and -p (A -t B is A times B, A -p B is A plus B)
> Making --or optional sounds fine as that
> would make the default "multiple -e" case similar to what GNU
> grep does without any --and nor --or.
That's exactly what I was thinking about: make extended expressions
compatible to current grep options. This will confuse less people and
there is no need for an extra option to activate this.
^ permalink raw reply
* Re: [PATCH/RFH] Racy GIT (part #3)
From: Uwe Zeisberger @ 2006-06-30 7:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7j2zpr6k.fsf@assigned-by-dhcp.cox.net>
Hello,
Junio C Hamano wrote:
> Does everybody have "cp -p" to preserve the file timestamps on
> his/her platform? I am assuming this is safe (it is in POSIX),
> but please raise hand if that is not a case for you.
Solaris[1] has two different "cp"s[2].
From cp(1):
[...] [/usr/bin/cp] does not fail if unable to preserve extended
attributes, modification and access time, or permission modes.
[...] [/usr/xpg4/bin/cp] does not fail if unable to preserve
extended attributes. If unable to duplicate the modification
and access time or the permission modes, cp prints a diagnostic
message to stderr and return a non-zero exit status.
There is yet an other difference when -@ is specified. The complete man
page can be found at docs.sun.com[2].
Best regards
Uwe
[1] in my case Solaris 10 = SunOS 5.10 and Solaris 9 = SunOS 5.9
[2] http://docs.sun.com/app/docs/doc/816-5165/6mbb0m9dm?a=view
--
Uwe Zeisberger
http://www.google.com/search?q=0+degree+Celsius+in+kelvin
^ permalink raw reply
* Re: [PATCH 2/4] make filepairs detachable
From: Alex Riesen @ 2006-06-30 7:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Alex Riesen, git, Johannes Schindelin
In-Reply-To: <7vy7vfmoit.fsf@assigned-by-dhcp.cox.net>
On 6/30/06, Junio C Hamano <junkio@cox.net> wrote:
>
> > Actually, just make sure diff_flush does not crash for diff queue
> > entries which were cleared.
>
> Somehow I really feel uneasy about this one. I think it is the
> responsibility of the one who mangles the queue to adjust the
> entries and count consistent.
>
That's what I get after being exposed to double-linked lists for
too long: I begin to think it's fine to take whatever I want.
The pairs are actually exactly what I need, so I take them.
I think I just have to encapsulate it nicely, i.e.:
struct diff_filepair *diff_queued_detach(int pos)
{
struct diff_filepair *pair = NULL;
if (pos < diff_queued_diff.nr) {
diff_queued_diff.queue[pos];
if (diff_queued_diff.nr - pos > 1)
memmove(pair->queue + pos, pair->queue + pos + 1,
diff_queued_diff.nr - pos - 1);
diff_queued_diff.nr--;
}
return pair;
}
BTW, is there any chance we get the struct diff_filepair's
double-linked? They don't seem to be sorted. Will increase
the memory footprint, though.
^ permalink raw reply
* Re: [PATCH 1/3] Fix probing for already installed Error.pm
From: Junio C Hamano @ 2006-06-30 7:40 UTC (permalink / raw)
To: Pavel Roskin, Petr Baudis; +Cc: git
In-Reply-To: <7vfyhnksqf.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Pavel Roskin <proski@gnu.org> writes:
>
>> diff --git a/perl/Makefile.PL b/perl/Makefile.PL
>> index d401a66..b3fbb73 100644
>> --- a/perl/Makefile.PL
>> +++ b/perl/Makefile.PL
>> @@ -12,7 +12,7 @@ my %pm = ('Git.pm' => '$(INST_LIBDIR)/Gi
>>
>> # We come with our own bundled Error.pm. It's not in the set of default
>> # Perl modules so install it if it's not available on the system yet.
>> -eval { require 'Error' };
>> +eval { require Error };
>> if ($@) {
>> $pm{'Error.pm'} = '$(INST_LIBDIR)/Error.pm';
>> }
>
> The syntax updates is correct, but this is still wrong, I am
> afraid.
>
> It is trying to see if we need to install the Error.pm we ship
> just in case the system does not have Error.pm available. But
> this script is run in perl/ directory where we have that private
> copy of Error.pm, so "require Error" always succeeds, eh, at
> least after you fixed the above syntax error X-<.
That is, we would want something like this.
diff --git a/perl/Error.pm b/perl/private-Error.pm
similarity index 100%
rename from perl/Error.pm
rename to perl/private-Error.pm
diff --git a/perl/Makefile.PL b/perl/Makefile.PL
index b3fbb73..25ae54a 100644
--- a/perl/Makefile.PL
+++ b/perl/Makefile.PL
@@ -14,7 +14,7 @@ # We come with our own bundled Error.pm.
# Perl modules so install it if it's not available on the system yet.
eval { require Error };
if ($@) {
- $pm{'Error.pm'} = '$(INST_LIBDIR)/Error.pm';
+ $pm{'private-Error.pm'} = '$(INST_LIBDIR)/Error.pm';
}
WriteMakefile(
^ permalink raw reply related
* Re: Git.xs merge status
From: Pavel Roskin @ 2006-06-30 7:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, hpa
In-Reply-To: <7vlkrfkt6q.fsf_-_@assigned-by-dhcp.cox.net>
Quoting Junio C Hamano <junkio@cox.net>:
> The kernel.org machine I am using for testing does not seem to
> have perl-Error installed, and I suspect Pasky arranged to ship
> our own Error.pm for people building git from source because the
> package is not so widely installed. I guess I should ask the
> admins there before I can build perl-Git RPMs for release.
It's better than to have conflicting packages (perl-Git and perl-Error). The
build requirement can be relaxed if needed (either by finding and removing
Error* after the install or by adding another flag to Makefile.PL), but I think
it's logical to have it because perl-Error would be needed by git-core anyway.
Another solution would be to arrange Error.pm to be installed and used as
Git::Error, but that would be a case of code duplication.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: [PATCH 1/3] Fix probing for already installed Error.pm
From: Junio C Hamano @ 2006-06-30 7:28 UTC (permalink / raw)
To: Pavel Roskin, Petr Baudis; +Cc: git
In-Reply-To: <20060630050923.701.37665.stgit@dv.roinet.com>
Pavel Roskin <proski@gnu.org> writes:
> diff --git a/perl/Makefile.PL b/perl/Makefile.PL
> index d401a66..b3fbb73 100644
> --- a/perl/Makefile.PL
> +++ b/perl/Makefile.PL
> @@ -12,7 +12,7 @@ my %pm = ('Git.pm' => '$(INST_LIBDIR)/Gi
>
> # We come with our own bundled Error.pm. It's not in the set of default
> # Perl modules so install it if it's not available on the system yet.
> -eval { require 'Error' };
> +eval { require Error };
> if ($@) {
> $pm{'Error.pm'} = '$(INST_LIBDIR)/Error.pm';
> }
The syntax updates is correct, but this is still wrong, I am
afraid.
It is trying to see if we need to install the Error.pm we ship
just in case the system does not have Error.pm available. But
this script is run in perl/ directory where we have that private
copy of Error.pm, so "require Error" always succeeds, eh, at
least after you fixed the above syntax error X-<.
^ permalink raw reply
* Re: [PATCH 4/4] save another call to git-update-index
From: Alex Riesen @ 2006-06-30 7:22 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Alex Riesen, git
In-Reply-To: <Pine.LNX.4.63.0606300235300.29667@wbgn013.biozentrum.uni-wuerzburg.de>
On 6/30/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
> FYI I've been just battling this pipe for a couple of hours. The first
> steps were easy, but since I wanted to do it incrementally, the index has
> to be written every so often, and I seem not to be able to get that right.
>
Are you sure? Does something use the index between starting update-index
pipe and pclose?
^ permalink raw reply
* Re: Git.xs merge status
From: Junio C Hamano @ 2006-06-30 7:18 UTC (permalink / raw)
To: Pavel Roskin; +Cc: git, hpa
In-Reply-To: <1151644101.10496.22.camel@dv>
Pavel Roskin <proski@gnu.org> writes:
> I guess all this perl stuff should be in a separate module perl-Git to
> comply with Red Hat conventions. This would make git-core depend on
> perl-Git, but it's OK.
>
> Error.pm is already provided by perl-Error. If we require perl(Error)
> for building, it won't be installed. Actually, probing for Error.pm is
> incorrect, so I'm fixing it.
>
> Git.bs, .packlist and perllocal.pod should be removed - that's what
> other Perl packages do. Red Hat packages use INSTALLDIRS=vendor so that
> "site_perl" becomes "vendor_perl".
>
> While hacking that, I have wound that "--without doc" is broken in pu,
> so I'm fixing it as well. The patches will be sent shortly.
Thanks.
The kernel.org machine I am using for testing does not seem to
have perl-Error installed, and I suspect Pasky arranged to ship
our own Error.pm for people building git from source because the
package is not so widely installed. I guess I should ask the
admins there before I can build perl-Git RPMs for release.
I am doing this preparation not for the upcoming 1.4.1 but later
than that -- perhaps way later than that -- so there is no rush.
^ 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