* Re: [PATCH] git-grep: --and to combine patterns with and instead of or
From: Junio C Hamano @ 2006-06-30 17:18 UTC (permalink / raw)
To: Matthias Lederhofer; +Cc: git
In-Reply-To: <E1FwMPf-0005XA-N9@moooo.ath.cx>
Matthias Lederhofer <matled@gmx.net> writes:
> 1. Should the context of near be the same as -[ABC] or perhaps
> --near=N / --near=N:M (default could be the same as specified by
> -[ABC]).
As an end-user, I do not care either way.
> 2. Should it be possible to specify another boolean expression after
> --near? e.g. --near ( -e foo --or ( -e bar --and -e baz )) to match
> if the context contains foo or 'bar and baz'.
I would say why not.
> 3. Is --near just another subexpression? e.g. search for foo with
> either A or B in the context:
> -e foo --and ( --near A --or --near B )
> This does not make sense without 1 and 2.
Ah, interesting. I was thinking --near to be weaker form of --and,
but you made it to be a unary predicate (like --not). That
would be neater.
> With some or all of those features quite mighty and complex
> expressions can be build:
> -e A --and --near=3:-1 ( -e B --and --near=0:0 ( -e foo --and -e bar ) )
> This could mean: find lines containing A and have B in any of the 3
> lines before A (without the line containing A). Additionally foo and
> bar have to be found on the same line before A.
Having said that, I suspect the above made-up example may not be
so useful in practice. I think a more realistic usage is "I
want to find lines that contain `made-up' and `realistic' but
the paragraph might have been filled by the editor and they may
be found on separate nearby lines. Instead of saying `-e
made-up --and -e realistic', I would say `-e made-up --near -e
realistic' to find what I want". That would find the first two
lines of this paragraph, among others.
> With the new extended expressions it would be really nice if git-grep
> could also be used outside a git repository :)
I am not sure about `outside' but it might be useful to extend
the working tree walker and glob filter used there to match what
ls-files uses so that it can do untracked files as well.
^ permalink raw reply
* Re: [PATCH] git-grep: --and to combine patterns with and instead of or
From: Jakub Narebski @ 2006-06-30 17:33 UTC (permalink / raw)
To: git
In-Reply-To: <7vpsgqimu7.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Matthias Lederhofer <matled@gmx.net> writes:
>> 3. Is --near just another subexpression? e.g. search for foo with
>> either A or B in the context:
>> -e foo --and ( --near A --or --near B )
>> This does not make sense without 1 and 2.
>
> Ah, interesting. I was thinking --near to be weaker form of --and,
> but you made it to be a unary predicate (like --not). That
> would be neater.
I think --near _has_ to be non-symmetric binary operator, i.e. first
argument specifies line to be found, second argument has to be in context
for first line if it is found.
So the above expression would be written as:
-e foo --near \( A --or B \)
BTW. we can make -e equivalent to --or, and empty (default) operator to
--and, but of course you have to delimit expression from files, i.e. either
git grep A B C D -- files
or
git grep -e \( A B C D \) files
which would be equivalent to
git grep A --and B --and C --and D files
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: fc046a75d539a78e6b2c16534c4078617a69a327 fails on OpenBSD 3.8
From: Junio C Hamano @ 2006-06-30 17:38 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git
In-Reply-To: <86sllmy3ia.fsf@blue.stonehenge.com>
merlyn@stonehenge.com (Randal L. Schwartz) writes:
>>>>>> "Junio" == Junio C Hamano <junkio@cox.net> writes:
>...
>>> In file included from /usr/include/sys/poll.h:54,
>>> from upload-pack.c:9:
>>> /usr/include/ctype.h:91:1: unterminated #if
>>> /usr/include/ctype.h:40:1: unterminated #ifndef
>
> Junio> Crap. Including <sys/poll.h> pollutes your namespace with ctype
> Junio> macros?
I should stop imitating others -- not my style. Sorry.
Would this work for you?
diff --git a/upload-pack.c b/upload-pack.c
index 2b70c3d..b18eb9b 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -1,3 +1,6 @@
+#include <signal.h>
+#include <sys/wait.h>
+#include <sys/poll.h>
#include "cache.h"
#include "refs.h"
#include "pkt-line.h"
@@ -5,9 +8,6 @@ #include "tag.h"
#include "object.h"
#include "commit.h"
#include "exec_cmd.h"
-#include <signal.h>
-#include <sys/poll.h>
-#include <sys/wait.h>
static const char upload_pack_usage[] = "git-upload-pack [--strict] [--timeout=nn] <dir>";
^ permalink raw reply related
* Re: [PATCH] git-grep: --and to combine patterns with and instead of or
From: Matthias Lederhofer @ 2006-06-30 17:49 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e83n97$973$1@sea.gmane.org>
Jakub Narebski wrote:
> I think --near _has_ to be non-symmetric binary operator, i.e. first
> argument specifies line to be found, second argument has to be in context
> for first line if it is found.
>
> So the above expression would be written as:
>
> -e foo --near \( A --or B \)
Why is that?
-e foo --and --near \( -e A -- or -e B \)
would mean lines containing foo and either A or B in the context and
-e foo --or --near \( -e A -- or -e B \)
would mean lines containing foo or having A or B in the context.
> BTW. we can make -e equivalent to --or, and empty (default) operator to
> --and, but of course you have to delimit expression from files, i.e. either
>
> git grep A B C D -- files
This is incompatible with the current implementation.
'git grep A B C D -- files' means A is the pattern, B, C, D are
revisions and files is the pathspec.
> or
>
> git grep -e \( A B C D \) files
>
> which would be equivalent to
>
> git grep A --and B --and C --and D files
I think this could probably be used. But I think having two different
implicit operators depending on the context is too confusing.
^ permalink raw reply
* Re: [PATCH] git-grep: --and to combine patterns with and instead of or
From: Junio C Hamano @ 2006-06-30 17:58 UTC (permalink / raw)
To: Matthias Lederhofer; +Cc: git, Jakub Narebski
In-Reply-To: <E1FwN7M-0007GI-Ng@moooo.ath.cx>
Matthias Lederhofer <matled@gmx.net> writes:
> -e foo --or --near \( -e A -- or -e B \)
> would mean lines containing foo or having A or B in the context.
How would that "--near" be useful? You will see A or B either way.
^ permalink raw reply
* Re: [PATCH] git-grep: --and to combine patterns with and instead of or
From: Jakub Narebski @ 2006-06-30 18:03 UTC (permalink / raw)
To: git
In-Reply-To: <E1FwN7M-0007GI-Ng@moooo.ath.cx>
Matthias Lederhofer wrote:
> Jakub Narebski wrote:
>> I think --near _has_ to be non-symmetric binary operator, i.e. first
>> argument specifies line to be found, second argument has to be in context
>> for first line if it is found.
>>
>> So the above expression would be written as:
>>
>> -e foo --near \( A --or B \)
> Why is that?
> -e foo --and --near \( -e A --or -e B \)
> would mean lines containing foo and either A or B in the context and
> -e foo --or --near \( -e A --or -e B \)
> would mean lines containing foo or having A or B in the context.
Because --near needs an expression it check context for (context is for
found match of lhs expression). So
-e foo --near \( -e A --or -e B \)
means lines containing foo and either A or B in the context _for "foo"_.
--and --near could be shorthand for --and-near, and --or --near for
--or-near... except that the second one doesn't have much sense:
What is the difference between
-e foo --or --near \( -e A --or -e B \)
and
-e foo --or \( -e A --or -e B \)
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH 1/3] Fix probing for already installed Error.pm
From: Pavel Roskin @ 2006-06-30 18:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Petr Baudis, git
In-Reply-To: <7vbqsbks69.fsf@assigned-by-dhcp.cox.net>
On Fri, 2006-06-30 at 00:40 -0700, Junio C Hamano wrote:
> > 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-<.
Nice catch! Thank you for fixing it.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: [PATCH] git-grep: --and to combine patterns with and instead of or
From: Junio C Hamano @ 2006-06-30 18:16 UTC (permalink / raw)
To: jnareb; +Cc: git
In-Reply-To: <e83p0q$dla$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> Because --near needs an expression it check context for (context is for
> found match of lhs expression). So
>
> -e foo --near \( -e A --or -e B \)
>
> means lines containing foo and either A or B in the context _for "foo"_.
The syntax and semantics of --near I suggested (and you are
following) and what Matthias discusses are different and I think
that is why you two are talking past each other.
What I originally suggested is that you can (syntactically)
replace --near with --and. That is, the LHS is the match and
RHS is "the LHS must match, but in addition RHS must match but
unlike --and RHS does not have to be exactly on the same line
but it is OK if it is a line somewhere nearby".
The --near Matthias talk about is syntactically not like --and
but more like --not. It takes a condition for a line after
that, and loosens it to cover nearby lines. So "-e A"
means "the line must have A on it" but "--near -e A" means "the
line must be nearby a line that satisfies `-e A'".
Matthias's "--near EXP" is spelled as "-e '' --near EXP" (the
first one is always true) with our syntax, in other words.
I do not think either of these semantics is invalid; they are
just different. The version by Matthias is more general and
more expressive.
^ permalink raw reply
* Re: [PATCH] git-grep: --and to combine patterns with and instead of or
From: Matthias Lederhofer @ 2006-06-30 18:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jakub Narebski
In-Reply-To: <7vfyhmil07.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Matthias Lederhofer <matled@gmx.net> writes:
>
> > -e foo --or --near \( -e A -- or -e B \)
> > would mean lines containing foo or having A or B in the context.
>
> How would that "--near" be useful? You will see A or B either way.
Ok, this example was quite bad.
If --near is binary
-e foo --and ( --near=3:0 -e A --or --near=0:3 -e B )
could not be done anymore, could it (without repeating the first
pattern)? (Find foo with A in the 3 lines before or B in the 3 lines
after the line.)
Without different contexts for multiple --near it probably does not
matter if --near is binary or unary.
^ permalink raw reply
* git object hash cleanups
From: Linus Torvalds @ 2006-06-30 18:20 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List
This IMNSHO cleans up the object hashing.
The hash expansion is separated out into a function of its own, the hash
array (and size) names are made more obvious, and the code is generally
made to look a bit more like the object-ref hashing.
It also gets rid of "find_object()" returning an index (or negative
position if no object is found), since that is made redundant by the
simplified object rehashing. The basic operation is now "lookup_object()"
which just returns the object itself.
There's an almost unmeasurable speed increase, but more importantly, I
think the end result is more readable.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
---
I tried to be really careful, and this should all be good, but I'm still
embarrassed about my hash insertion bug in object-refs.c, so people should
double- and triple-check this.
diff --git a/object.c b/object.c
index 31c77ea..37277f9 100644
--- a/object.c
+++ b/object.c
@@ -5,88 +5,97 @@ #include "tree.h"
#include "commit.h"
#include "tag.h"
-static struct object **objs;
-static int nr_objs, obj_allocs;
+static struct object **obj_hash;
+static int nr_objs, obj_hash_size;
unsigned int get_max_object_index(void)
{
- return obj_allocs;
+ return obj_hash_size;
}
struct object *get_indexed_object(unsigned int idx)
{
- return objs[idx];
+ return obj_hash[idx];
}
const char *type_names[] = {
"none", "blob", "tree", "commit", "bad"
};
+static unsigned int hash_obj(struct object *obj, unsigned int n)
+{
+ unsigned int hash = *(unsigned int *)obj->sha1;
+ return hash % n;
+}
+
+static void insert_obj_hash(struct object *obj, struct object **hash, unsigned int size)
+{
+ int j = hash_obj(obj, size);
+
+ while (hash[j]) {
+ j++;
+ if (j >= size)
+ j = 0;
+ }
+ hash[j] = obj;
+}
+
static int hashtable_index(const unsigned char *sha1)
{
unsigned int i;
memcpy(&i, sha1, sizeof(unsigned int));
- return (int)(i % obj_allocs);
+ return (int)(i % obj_hash_size);
}
-static int find_object(const unsigned char *sha1)
+struct object *lookup_object(const unsigned char *sha1)
{
int i;
+ struct object *obj;
- if (!objs)
- return -1;
+ if (!obj_hash)
+ return NULL;
i = hashtable_index(sha1);
- while (objs[i]) {
- if (memcmp(sha1, objs[i]->sha1, 20) == 0)
- return i;
+ while ((obj = obj_hash[i]) != NULL) {
+ if (!memcmp(sha1, obj->sha1, 20))
+ break;
i++;
- if (i == obj_allocs)
+ if (i == obj_hash_size)
i = 0;
}
- return -1 - i;
+ return obj;
}
-struct object *lookup_object(const unsigned char *sha1)
+static void grow_object_hash(void)
{
- int pos = find_object(sha1);
- if (pos >= 0)
- return objs[pos];
- return NULL;
+ int i;
+ int new_hash_size = obj_hash_size < 32 ? 32 : 2 * obj_hash_size;
+ struct object **new_hash;
+
+ new_hash = calloc(new_hash_size, sizeof(struct object *));
+ for (i = 0; i < obj_hash_size; i++) {
+ struct object *obj = obj_hash[i];
+ if (!obj)
+ continue;
+ insert_obj_hash(obj, new_hash, new_hash_size);
+ }
+ free(obj_hash);
+ obj_hash = new_hash;
+ obj_hash_size = new_hash_size;
}
void created_object(const unsigned char *sha1, struct object *obj)
{
- int pos;
-
obj->parsed = 0;
- memcpy(obj->sha1, sha1, 20);
- obj->type = TYPE_NONE;
obj->used = 0;
+ obj->type = TYPE_NONE;
+ obj->flags = 0;
+ memcpy(obj->sha1, sha1, 20);
- if (obj_allocs - 1 <= nr_objs * 2) {
- int i, count = obj_allocs;
- obj_allocs = (obj_allocs < 32 ? 32 : 2 * obj_allocs);
- objs = xrealloc(objs, obj_allocs * sizeof(struct object *));
- memset(objs + count, 0, (obj_allocs - count)
- * sizeof(struct object *));
- for (i = 0; i < obj_allocs; i++)
- if (objs[i]) {
- int j = find_object(objs[i]->sha1);
- if (j != i) {
- j = -1 - j;
- objs[j] = objs[i];
- objs[i] = NULL;
- }
- }
- }
-
- pos = find_object(sha1);
- if (pos >= 0)
- die("Inserting %s twice\n", sha1_to_hex(sha1));
- pos = -pos-1;
+ if (obj_hash_size - 1 <= nr_objs * 2)
+ grow_object_hash();
- objs[pos] = obj;
+ insert_obj_hash(obj, obj_hash, obj_hash_size);
nr_objs++;
}
^ permalink raw reply related
* Re: [PATCH/RFC] Add git-instaweb, instantly browse the working repo with gitweb
From: Junio C Hamano @ 2006-06-30 18:24 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <11513991301372-git-send-email-normalperson@yhbt.net>
Eric Wong <normalperson@yhbt.net> writes:
> I got tired of having to configure gitweb for every repository
> I work on. I sometimes prefer gitweb to standard GUIs like gitk
> or gitview; so this lets me automatically configure gitweb to
> browse my working repository and also opens my browser to it.
>
> Signed-off-by: Eric Wong <normalperson@yhbt.net>
This is cute but I haven't seen much responses to it yet. Are
people uninterested?
^ permalink raw reply
* [PATCH/RFT] upload-pack.c: <sys/poll.h> includes <ctype.h> on OpenBSD 3.8
From: Junio C Hamano @ 2006-06-30 18:30 UTC (permalink / raw)
To: git; +Cc: Randal L. Schwartz
In-Reply-To: <7vk66yilxd.fsf@assigned-by-dhcp.cox.net>
Merlyn reports that <sys/poll.h> on OpenBSD 3.8 includes <ctype.h>
and having our custom ctype (done in git-compat-util.h which is
included via cache.h) makes upload-pack.c uncompilable. Try to
work it around by including the system headers first.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* Can somebody with OpenBSD who can reproduce the original
problem confirm or reject this patch, so that the issue can
be resolved before 1.4.1, please?
diff --git a/upload-pack.c b/upload-pack.c
index 2b70c3d..b18eb9b 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -1,3 +1,6 @@
+#include <signal.h>
+#include <sys/wait.h>
+#include <sys/poll.h>
#include "cache.h"
#include "refs.h"
#include "pkt-line.h"
@@ -5,9 +8,6 @@ #include "tag.h"
#include "object.h"
#include "commit.h"
#include "exec_cmd.h"
-#include <signal.h>
-#include <sys/poll.h>
-#include <sys/wait.h>
static const char upload_pack_usage[] = "git-upload-pack [--strict] [--timeout=nn] <dir>";
^ permalink raw reply related
* Re: [PATCH/RFT] upload-pack.c: <sys/poll.h> includes <ctype.h> on OpenBSD 3.8
From: Jakub Narebski @ 2006-06-30 19:00 UTC (permalink / raw)
To: git
In-Reply-To: <7vr716h4xm.fsf_-_@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Try to work it around by including the system headers first.
Shouldn't it be always the case?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] git-grep: --and to combine patterns with and instead of or
From: Jakub Narebski @ 2006-06-30 19:11 UTC (permalink / raw)
To: git
In-Reply-To: <7v1wt6ik4x.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> The --near Matthias talk about is syntactically not like --and
> but more like --not. It takes a condition for a line after
> that, and loosens it to cover nearby lines. So "-e A"
> means "the line must have A on it" but "--near -e A" means "the
> line must be nearby a line that satisfies `-e A'".
>
> Matthias's "--near EXP" is spelled as "-e '' --near EXP" (the
> first one is always true) with our syntax, in other words.
>
> I do not think either of these semantics is invalid; they are
> just different. The version by Matthias is more general and
> more expressive.
It also uses the fact that grep search for _lines_, the fact I have forgot
about. But if we cannot search for multiline regexp using git-grep,
Matthias version is truly more expressive, especially with context limiting
extension.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] git-grep: --and to combine patterns with and instead of or
From: Junio C Hamano @ 2006-06-30 20:26 UTC (permalink / raw)
To: jnareb; +Cc: git
In-Reply-To: <e83t0m$4s0$2@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> Matthias version is truly more expressive, especially with context limiting
> extension.
That's orthogonal. I do not think there is any reason you
cannot make the version whose --near is similar to --and to
understand different ranges for each "neighbor search"
expression using --near=M:N syntax.
Now stop talking and code it up, please ;-).
^ permalink raw reply
* Re: [PATCH 13] autoconf: Append '-include config.mak.autogen' to config.mak if it is not present
From: Jakub Narebski @ 2006-06-30 20:29 UTC (permalink / raw)
To: git
In-Reply-To: <200606301711.39635.jnareb@gmail.com>
Jakub Narebski wrote:
> +grep -q -s -F "-include ${config_file}" config.mak || \
> + echo "-include ${config_file}" >> config.mak
Gah, should be of course
+grep -q -s -F -e "-include ${config_file}" config.mak || \
+ echo "-include ${config_file}" >> config.mak
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Prepare "git-merge-tree" for future work
From: Junio C Hamano @ 2006-06-30 20:52 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0606291925230.12404@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> In contrast, the ones to diff_filespec I've never really used, and I did
> not want to compare blob objects, I very much wanted to compare in-memory
> buffers (_and_ potentially blobs).
>
> So if you can show an easy example of how to populate a set of filespec
> pairs (not with blobs - with in-memory generated data) and insert them
> onto the lists, that would be good.
Ah, I see. Your origin() function always returns a in-core
buffer from an existing blob (or NULL if it is a new file) but
result() returns either an existing blob resulting from the
tree-level merge, or a 3-way content merge result that does not
have an existing blob, and it is not obvious how to express the
latter as a filespec (all other cases you can stuff the blob
object name in the sha1[] member and if you choose to do the
read_sha1_file() yourself store the result in data member or you
can let diff_populate_filespec() read the data when diff
machinery needs it).
I think a filespec that has 0{40} sha1, with data already
populated and should_free/should_munmap members both set to
false might work for the in-memory data but I haven't tried.
I'd take the hint, and I will (eventually) take a look at it
if nobody beats me to it, but most likely not now, sorry.
^ permalink raw reply
* [RFC/PATCH 14] autoconf: Added --with/--without for openssl, curl, expat to ./configure
From: Jakub Narebski @ 2006-06-30 21:45 UTC (permalink / raw)
To: git
In-Reply-To: <200606301711.39635.jnareb@gmail.com>
Added --with-PACKAGE[=PATH] (where PATH is prefix for PACKAGE
libraries and includes) and --without-PACKAGE (--with-PACKAGE=no)
support for curl, openssl, expat to configure.ac
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
I'm not autoconf/m4 expert: could anyone tell me how to uppercase
PACKAGE name, so one could write MY_PARSE_WITH(openssl)?
How to add [=PATH] to --with-PACKAGE option description in a way
which does not screw up AS_HELP_WITH calculations. I could use
@<:@=PATH@:>@ which transforms to [=PATH], but AS_HELP_WITH counts
number of characters in source I think.
configure.ac | 34 ++++++++++++++++++++++++++++++++++
1 files changed, 34 insertions(+), 0 deletions(-)
diff --git a/configure.ac b/configure.ac
index fcfc9ce..26d6f4d 100644
--- a/configure.ac
+++ b/configure.ac
@@ -19,6 +19,22 @@ # Append LINE to file ${config_append}
AC_DEFUN([MY_APPEND_LINE],
[[echo "$1" >> "${config_append}"]])# MY_APPEND_LINE
+# MY_PARSE_WITH(PACKAGE)
+# ----------------------
+# For use in AC_ARG_WITH action-if-found, for packages default ON.
+# * Set NO_PACKAGE=YesPlease for --without-PACKAGE
+# * Set PACKAGEDIR=ARG for --with-PACKAGE=ARG
+# * Do nothing for --with-PACKAGE without ARG
+# PACKAGE option must be all uppercase
+AC_DEFUN([MY_PARSE_WITH],
+[[if test "$withval" = "no"; then \
+ MY_APPEND_LINE(NO_$1=YesPlease); \
+ elif test "$withval" != "yes"; then \
+ MY_APPEND_LINE($1DIR=$withval); \
+ fi; \
+]])# MY_PARSE_WITH
+
+
# Checks for libraries.
AC_MSG_NOTICE([CHECKS for libraries])
AC_CHECK_LIB([crypto], [SHA1_Init],,MY_APPEND_LINE(NO_OPENSSL=YesPlease))
@@ -48,6 +64,24 @@ AC_CHECK_FUNC(strlcpy,,MY_APPEND_LINE(NO
AC_CHECK_FUNC(setenv,,MY_APPEND_LINE(NO_SETENV=YesPlease))
+# Site configuration
+AC_MSG_NOTICE([CHECKS for site configuration])
+AC_ARG_WITH(curl,
+AS_HELP_STRING([--with-curl],[support http(s):// transports (default is YES)])
+AS_HELP_STRING([], [ARG can be also prefix for curl library and headers]),\
+MY_PARSE_WITH(CURL))
+
+AC_ARG_WITH(openssl,
+AS_HELP_STRING([--with-openssl],[use OpenSSL library (default is YES)])
+AS_HELP_STRING([], [ARG can be prefix for openssl library and headers]),\
+MY_PARSE_WITH(OPENSSL))
+
+AC_ARG_WITH(expat,
+AS_HELP_STRING([--with-expat],[support git-push using http:// and https:// transports via WebDAV (default is YES)])
+AS_HELP_STRING([], [ARG can be also prefix for expat library and headers]),\
+MY_PARSE_WITH(EXPAT))
+
+
# Output files
AC_CONFIG_FILES(["${config_file}":"${config_in}":"${config_append}"])
AC_OUTPUT
--
1.4.0
^ permalink raw reply related
* Re: [RFC/PATCH 14] autoconf: Added --with/--without for openssl, curl, expat to ./configure
From: Pavel Roskin @ 2006-06-30 21:57 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200606302345.17045.jnareb@gmail.com>
Hi Jakub,
On Fri, 2006-06-30 at 23:45 +0200, Jakub Narebski wrote:
> I'm not autoconf/m4 expert: could anyone tell me how to uppercase
> PACKAGE name, so one could write MY_PARSE_WITH(openssl)?
I don't quite understand what you want, but you could check m4_toupper.
> How to add [=PATH] to --with-PACKAGE option description in a way
> which does not screw up AS_HELP_WITH calculations. I could use
> @<:@=PATH@:>@ which transforms to [=PATH], but AS_HELP_WITH counts
> number of characters in source I think.
Try another pair of square brackets as quotes for literal contents. In
this case, use [[=PATH]]
> +# MY_PARSE_WITH(PACKAGE)
By the way, it's better to use a prefix other than MY. I thing
GIT_PARSE_WITH would be great.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: [RFC/PATCH 14] autoconf: Added --with/--without for openssl, curl, expat to ./configure
From: Jakub Narebski @ 2006-06-30 22:32 UTC (permalink / raw)
To: git
In-Reply-To: <1151704626.12008.5.camel@dv>
<posted & mailed>
Pavel Roskin wrote:
> On Fri, 2006-06-30 at 23:45 +0200, Jakub Narebski wrote:
>> I'm not autoconf/m4 expert: could anyone tell me how to uppercase
>> PACKAGE name, so one could write MY_PARSE_WITH(openssl)?
>
> I don't quite understand what you want, but you could check m4_toupper.
Thanks. It works great. GIT_PARSE_WITH is now:
AC_DEFUN([GIT_PARSE_WITH],
[[PACKAGE=m4_toupper($1); \
if test "$withval" = "no"; then \
GIT_APPEND_LINE(NO_${PACKAGE}=YesPlease); \
elif test "$withval" != "yes"; then \
GIT_APPEND_LINE(${PACKAGE}DIR=$withval); \
fi; \
]])# GIT_PARSE_WITH
>> How to add [=PATH] to --with-PACKAGE option description in a way
>> which does not screw up AS_HELP_WITH calculations. I could use
>> @<:@=PATH@:>@ which transforms to [=PATH], but AS_HELP_WITH counts
>> number of characters in source I think.
>
> Try another pair of square brackets as quotes for literal contents. In
> this case, use [[=PATH]]
I suspect that AS_HELP_WITH does some strange quoting, or stripping. Both
[=PATH] and [[=PATH]] produces =PATH in ./configure --help output.
When using @<:@=PATH@:>@ I get [=PATH], but the description of option begins
line below.
>> +# MY_PARSE_WITH(PACKAGE)
>
> By the way, it's better to use a prefix other than MY. I thing
> GIT_PARSE_WITH would be great.
Any ideas for name of MY_APPEND_LINE(LINE)/GIT_APPEND_LINE(LINE) macro,
which as a result adds line to output (e.g. LINE = "NO_CURL=YesPlease")?
Thanks for all suggestions
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [RFC/PATCH 14] autoconf: Added --with/--without for openssl, curl, expat to ./configure
From: Jakub Narebski @ 2006-06-30 22:34 UTC (permalink / raw)
To: git
In-Reply-To: <200606302345.17045.jnareb@gmail.com>
Jakub Narebski wrote:
> +AC_ARG_WITH(expat,
> +AS_HELP_STRING([--with-expat],[support git-push using http:// and https:// transports via WebDAV (default is YES)])
> +AS_HELP_STRING([], [ARG can be also prefix for expat library and headers]),\
> +MY_PARSE_WITH(EXPAT))
Of course to do anything for --with-expat=PATH case this patch needs
the one that introduces EXPATDIR (there was such patch on the list,
I'm not sure if it got accepted).
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* [PATCH] Speed up history generation
From: Luben Tuikov @ 2006-07-01 0:59 UTC (permalink / raw)
To: git
Speed up history generation as suggested by Linus.
Signed-off-by: Luben Tuikov <ltuikov@yahoo.com>
---
gitweb/gitweb.cgi | 9 ++-------
1 files changed, 2 insertions(+), 7 deletions(-)
diff --git a/gitweb/gitweb.cgi b/gitweb/gitweb.cgi
index 035e76d..2705a93 100755
--- a/gitweb/gitweb.cgi
+++ b/gitweb/gitweb.cgi
@@ -2295,16 +2295,12 @@ sub git_history {
"</div>\n";
print "<div class=\"page_path\"><b>/" . esc_html($file_name) . "</b><br/></div>\n";
- open my $fd, "-|", "$gitbin/git-rev-list $hash | $gitbin/git-diff-tree -r --stdin --
\'$file_name\'";
- my $commit;
+ open my $fd, "-|", "$gitbin/git-rev-list $hash -- \'$file_name\'";
print "<table cellspacing=\"0\">\n";
my $alternate = 0;
while (my $line = <$fd>) {
if ($line =~ m/^([0-9a-fA-F]{40})/){
- $commit = $1;
- next;
- }
- if ($line =~ m/^:([0-7]{6}) ([0-7]{6}) ([0-9a-fA-F]{40}) ([0-9a-fA-F]{40}) (.)\t(.*)$/ &&
(defined $commit)) {
+ my $commit = $1;
my %co = git_read_commit($commit);
if (!%co) {
next;
@@ -2336,7 +2332,6 @@ sub git_history {
}
print "</td>\n" .
"</tr>\n";
- undef $commit;
}
}
print "</table>\n";
--
1.4.1.rc2.g4ce4
^ permalink raw reply related
* [PATCH] Enable tree (directory) history display
From: Luben Tuikov @ 2006-07-01 1:00 UTC (permalink / raw)
To: git
This patch allows history display of whole trees/directories a la
"git-rev-list HEAD -- <dir or file>". I find this useful especially
when a project lives in its own subdirectory, as opposed to being all
of the GIT repository (i.e. when a sub-project is merged into a
super-project).
Signed-off-by: Luben Tuikov <ltuikov@yahoo.com>
---
gitweb/gitweb.cgi | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/gitweb/gitweb.cgi b/gitweb/gitweb.cgi
index 2705a93..d808900 100755
--- a/gitweb/gitweb.cgi
+++ b/gitweb/gitweb.cgi
@@ -1676,6 +1676,7 @@ # " | " . $cgi->a({-href => "$my
"</td>\n" .
"<td class=\"link\">" .
$cgi->a({-href => "$my_uri?" .
esc_param("p=$project;a=tree;h=$t_hash$base_key;f=$base$t_name")}, "tree") .
+ " | " . $cgi->a({-href => "$my_uri?" .
esc_param("p=$project;a=history;h=$hash_base;f=$base$t_name")}, "history") .
"</td>\n";
}
print "</tr>\n";
--
1.4.1.rc2.g4ce4
^ permalink raw reply related
* Re: [PATCH] Speed up history generation
From: Junio C Hamano @ 2006-07-01 1:04 UTC (permalink / raw)
To: ltuikov; +Cc: git
In-Reply-To: <20060701005924.7726.qmail@web31812.mail.mud.yahoo.com>
Luben Tuikov <ltuikov@yahoo.com> writes:
> Speed up history generation as suggested by Linus.
> @@ -2295,16 +2295,12 @@ sub git_history {
> "</div>\n";
> print "<div class=\"page_path\"><b>/" . esc_html($file_name) . "</b><br/></div>\n";
>
> - open my $fd, "-|", "$gitbin/git-rev-list $hash | $gitbin/git-diff-tree -r --stdin --
> \'$file_name\'";
> - my $commit;
> + open my $fd, "-|", "$gitbin/git-rev-list $hash -- \'$file_name\'";
This would speed things up but at the same time it changes the
semantics because it involves merge simplification, no?
At least that should be noted in the commit log.
^ permalink raw reply
* Re: [PATCH] Speed up history generation
From: Luben Tuikov @ 2006-07-01 1:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7j2ygmou.fsf@assigned-by-dhcp.cox.net>
--- Junio C Hamano <junkio@cox.net> wrote:
> Luben Tuikov <ltuikov@yahoo.com> writes:
>
> > Speed up history generation as suggested by Linus.
> > @@ -2295,16 +2295,12 @@ sub git_history {
> > "</div>\n";
> > print "<div class=\"page_path\"><b>/" . esc_html($file_name) . "</b><br/></div>\n";
> >
> > - open my $fd, "-|", "$gitbin/git-rev-list $hash | $gitbin/git-diff-tree -r --stdin --
> > \'$file_name\'";
> > - my $commit;
> > + open my $fd, "-|", "$gitbin/git-rev-list $hash -- \'$file_name\'";
>
> This would speed things up but at the same time it changes the
> semantics because it involves merge simplification, no?
>
> At least that should be noted in the commit log.
Ok, I guess this should be in the log. Can you add it please when
commiting to the master git branch?
Luben
^ 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