* Problem using GIT CVS-server
From: Panagiotis Issaris @ 2006-05-03 8:11 UTC (permalink / raw)
To: git
Hi,
I've tried using git-cvsserver, but keep running into problems:
When doing a checkout, it only checks out a small subset of
the total amount of files in the repository and reports a warning/error.
When doing a subsequent update, it doesn't seem to do anything,
but reports two error messages/warnings.
I'm using yesterdays GIT and try to serve my local copy of the GIT
repository using git-cvsserver.
export CVSROOT=:ext:takis@localhost:/usr/local/src/git/.git
export CVS_SERVER=git-cvsserver
takis@issaris:/tmp/a/b$ cvs co -d project-master master
takis@localhost's password:
cvs checkout: Updating project-master
U project-master/Makefile
U project-master/README
U project-master/cache.h
U project-master/cat-file.c
U project-master/commit-tree.c
U project-master/init-db.c
U project-master/read-cache.c
U project-master/read-tree.c
U project-master/show-diff.c
U project-master/update-cache.c
U project-master/write-tree.c
closing dbh with active statement handles
takis@issaris:/tmp/a/b$ cd project-master/
takis@issaris:/tmp/a/b/project-master$ cvs -z3 update -PAd
takis@localhost's password:
server doesn't support gzip-file-contents
closing dbh with active statement handles
takis@issaris:/tmp/a/b/project-master$
With friendly regards,
Takis
^ permalink raw reply
* Re: [PATCH] Transitively read alternatives
From: Martin Waitz @ 2006-05-03 7:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v8xpjhguu.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 632 bytes --]
hoi :)
On Tue, May 02, 2006 at 09:28:25PM -0700, Junio C Hamano wrote:
> > + if (*entry != '/' && relative_base) {
> > + /* Relative alt-odb */
> > + if (base_len < 0)
> > + base_len = strlen(relative_base) + 1;
>
> Wouldn't base_len be always -1 here?
hmm, I just moved that part around.
> Maybe it is easier not to do the recursive thing unless the alternate
> is absolute path, and also as a purely safety measure, limit the
> maximum recursion depth to something low like 5, similar to recursive
> symlink resolution.
Agreed.
Lets see if I have some free time in the evening ;-)
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] Transitively read alternatives
From: Junio C Hamano @ 2006-05-03 4:28 UTC (permalink / raw)
To: Martin Waitz; +Cc: git
In-Reply-To: <20060502073847.GK20847@admingilde.org>
Martin Waitz <tali@admingilde.org> writes:
> When adding an alternate object store then add entries from its
> info/alternates files, too.
Not quite, I'm afraid...
> +static int link_alt_odb_entry(const char * entry, int len, const char * relative_base)
> +{
> + struct stat st;
> + const char *objdir = get_object_directory();
> + struct alternate_object_database *ent;
> + struct alternate_object_database *alt;
> + /* 43 = 40-byte + 2 '/' + terminating NUL */
> + int pfxlen = len;
> + int entlen = pfxlen + 43;
> + int base_len = -1;
> +
> + if (*entry != '/' && relative_base) {
> + /* Relative alt-odb */
> + if (base_len < 0)
> + base_len = strlen(relative_base) + 1;
Wouldn't base_len be always -1 here?
> + if (*entry != '/' && relative_base) {
> + memcpy(ent->base, relative_base, base_len - 1);
> + ent->base[base_len - 1] = '/';
> + memcpy(ent->base + base_len, entry, len);
> + }
> + else
> + memcpy(ent->base, entry, pfxlen);
Handling of full path sounds sensible; with relative_base case,
the referred-to object directory is relative to our object/
directory, so "A/.git/objects/info/alternates" would typically
have "../../../B/.git/objects/" if A borrows from B that lives
in the same subdirectory as A itself.
> + /* recursively add alternates */
> + read_info_alternates(ent->base);
But using that "../../../B/.git/objects/", we would read its
alternates. If it points at a neighbor we already borrow from,
say C (we would refer to it as "../../../C/.git/objects/"),
prefixing with relative_base would yield
../../../B/.git/objects/../../../C/.git/objects/
and we would end up getting the same thing twice, which sounds a
bit unfortunate. Maybe it is easier not to do the recursive
thing unless the alternate is absolute path, and also as a
purely safety measure, limit the maximum recursion depth to
something low like 5, similar to recursive symlink resolution.
Hmm?
^ permalink raw reply
* Re: [PATCH] repo-config: support --get-regexp and fix crash
From: Junio C Hamano @ 2006-05-03 4:06 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0605021422150.7051@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> diff --git a/repo-config.c b/repo-config.c
> index fa8aba7..722153c 100644
> --- a/repo-config.c
> +++ b/repo-config.c
> @@ -6,7 +6,10 @@ static const char git_config_set_usage[]
New flag missing from usage.
>
> static char* key = NULL;
> static char* value = NULL;
> +static regex_t* key_regexp = NULL;
> static regex_t* regexp = NULL;
> +static int show_keys = 0;
> +static int use_key_regexp = 0;
> static int do_all = 0;
> static int do_not_match = 0;
> static int seen = 0;
> @@ -26,16 +29,18 @@ static int show_config(const char* key_,
> if (value_ == NULL)
> value_ = "";
>
> - if (!strcmp(key_, key) &&
> + if ((use_key_regexp || !strcmp(key_, key)) &&
> + (!use_key_regexp ||
> + !regexec(key_regexp, key_, 0, NULL, 0)) &&
> (regexp == NULL ||
> (do_not_match ^
> !regexec(regexp, value_, 0, NULL, 0)))) {
That's a convoluted logic.
(1) Either we are using key-regexp, or otherwise the key has to
exactly match; and
(2) Either we are not using key-regexp, or key-regexp must
match; and
(3) Either we are not using regexp, or value must match (or
unmatch) as we are told by do_no_match.
It all makes sense, but I wonder if this is the clearest way to
convey what is happening to people. Not that I have a cleaner
alternative in mind...
> @@ -63,6 +70,14 @@ static int get_value(const char* key_, c
> key[i] = tolower(key_[i]);
> key[i] = 0;
>
> + if (use_key_regexp) {
> + key_regexp = (regex_t*)malloc(sizeof(regex_t));
> + if (regcomp(key_regexp, key, REG_EXTENDED)) {
> + fprintf(stderr, "Invalid key pattern: %s\n", regex_);
> + return -1;
> + }
> + }
> +
Not worrying about leaking on failure path is just fine, since
this is not a libified part. Perhaps the free() in get_value()
are all like that -- get_value() is called once immediately
before exiting the program anyway ;-).
To my deliberately bogus request, I am getting (null); fprintf()
should use "key" instead of "regex_", perhaps?
$ git-repo-config --get-regexp 'core['
Invalid key pattern: (null)
> @@ -78,7 +93,8 @@ static int get_value(const char* key_, c
>
> git_config(show_config);
> if (value) {
> - printf("%s\n", value);
> + if (!do_all)
> + printf("%s\n", value);
> free(value);
> }
> free(key);
I wonder if it would make things cleaner if you do not keep the
global "value" around. Instead, do all the printing in
show_config(), using a static global bool "seen" to control
do_all vs get-all request as you already do. Then get_value()
does not even need to worry about freeing the value, does it?
Also I am not sure if "say OK if do_all was requested" at the
end of get_value(). If a do_all request did not find any match,
is it an OK condition? I do not have strong feeling either way,
though.
A suggested patch on top of your version that is in "pu".
-- >8 --
diff --git a/repo-config.c b/repo-config.c
index 722153c..7e06d1a 100644
--- a/repo-config.c
+++ b/repo-config.c
@@ -2,10 +2,9 @@ #include "cache.h"
#include <regex.h>
static const char git_config_set_usage[] =
-"git-repo-config [ --bool | --int ] [--get | --get-all | --replace-all | --unset | --unset-all] name [value [value_regex]] | --list";
+"git-repo-config [ --bool | --int ] [--get | --get-all | --get-regexp | --replace-all | --unset | --unset-all] name [value [value_regex]] | --list";
static char* key = NULL;
-static char* value = NULL;
static regex_t* key_regexp = NULL;
static regex_t* regexp = NULL;
static int show_keys = 0;
@@ -26,6 +25,9 @@ static int show_all_config(const char *k
static int show_config(const char* key_, const char* value_)
{
+ char value[256];
+ const char *vptr = value;
+
if (value_ == NULL)
value_ = "";
@@ -35,28 +37,25 @@ static int show_config(const char* key_,
(regexp == NULL ||
(do_not_match ^
!regexec(regexp, value_, 0, NULL, 0)))) {
+ int dup_error = 0;
if (show_keys)
printf("%s ", key_);
- if (seen > 0) {
- if (!do_all)
- fprintf(stderr, "More than one value: %s\n",
- value);
- free(value);
- }
-
- if (type == T_INT) {
- value = malloc(256);
+ if (seen && !do_all)
+ dup_error = 1;
+ if (type == T_INT)
sprintf(value, "%d", git_config_int(key_, value_));
- } else if (type == T_BOOL) {
- value = malloc(256);
+ else if (type == T_BOOL)
sprintf(value, "%s", git_config_bool(key_, value_)
? "true" : "false");
- } else {
- value = strdup(value_);
- }
+ else
+ vptr = value_;
seen++;
- if (do_all)
- printf("%s\n", value);
+ if (dup_error) {
+ error("More than one value for the key %s: %s",
+ key_, vptr);
+ }
+ else
+ printf("%s\n", vptr);
}
return 0;
}
@@ -73,7 +72,7 @@ static int get_value(const char* key_, c
if (use_key_regexp) {
key_regexp = (regex_t*)malloc(sizeof(regex_t));
if (regcomp(key_regexp, key, REG_EXTENDED)) {
- fprintf(stderr, "Invalid key pattern: %s\n", regex_);
+ fprintf(stderr, "Invalid key pattern: %s\n", key_);
return -1;
}
}
@@ -92,11 +91,6 @@ static int get_value(const char* key_, c
}
git_config(show_config);
- if (value) {
- if (!do_all)
- printf("%s\n", value);
- free(value);
- }
free(key);
if (regexp) {
regfree(regexp);
@@ -104,9 +98,9 @@ static int get_value(const char* key_, c
}
if (do_all)
- return 0;
+ return !seen;
- return seen == 1 ? 0 : 1;
+ return (seen == 1) ? 0 : 1;
}
int main(int argc, const char **argv)
^ permalink raw reply related
* [PATCH] tiny optimization to diff-delta
From: Nicolas Pitre @ 2006-05-03 3:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0605022226070.28543@localhost.localdomain>
This is my assembly freak side looking at generated code again. And
since create_delta() is certainly pretty high on the radar every bits
count. In this case shorter code is generated if hash_mask is not
copied to a local variable.
Signed-off-by: Nicolas Pitre <nico@cam.org>
---
diff --git a/diff-delta.c b/diff-delta.c
index 26540d8..c618875 100644
--- a/diff-delta.c
+++ b/diff-delta.c
@@ -253,7 +253,7 @@ create_delta(const struct delta_index *i
const void *trg_buf, unsigned long trg_size,
unsigned long *delta_size, unsigned long max_size)
{
- unsigned int i, outpos, outsize, hash_mask, val;
+ unsigned int i, outpos, outsize, val;
int inscnt;
const unsigned char *ref_data, *ref_top, *data, *top;
unsigned char *out;
@@ -289,7 +289,6 @@ create_delta(const struct delta_index *i
ref_top = ref_data + index->src_size;
data = trg_buf;
top = trg_buf + trg_size;
- hash_mask = index->hash_mask;
outpos++;
val = 0;
@@ -304,7 +303,7 @@ create_delta(const struct delta_index *i
struct index_entry *entry;
val ^= U[data[-RABIN_WINDOW]];
val = ((val << 8) | *data) ^ T[val >> RABIN_SHIFT];
- i = val & hash_mask;
+ i = val & index->hash_mask;
for (entry = index->hash[i]; entry; entry = entry->next) {
const unsigned char *ref = entry->ptr;
const unsigned char *src = data;
^ permalink raw reply related
* [PATCH] improve diff-delta with sparse and/or repetitive data
From: Nicolas Pitre @ 2006-05-03 3:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
It is useless to preserve multiple hash entries for consecutive blocks
with the same hash. Keeping only the first one will allow for matching
the longest string of identical bytes while subsequent blocks will only
allow for shorter matches. The backward matching code will match the
end of it as necessary.
This improves both performances (no repeated string compare with long
successions of identical bytes, or even small group of bytes), as well
as compression (less likely to need random hash bucket entry culling),
especially with sparse files.
With well behaved data sets this patch doesn't change much.
Signed-off-by: Nicolas Pitre <nico@cam.org>
---
diff --git a/diff-delta.c b/diff-delta.c
index 35e517d..c618875 100644
--- a/diff-delta.c
+++ b/diff-delta.c
@@ -136,11 +136,12 @@ struct delta_index {
struct delta_index * create_delta_index(const void *buf, unsigned long bufsize)
{
- unsigned int i, hsize, hmask, entries, *hash_count;
+ unsigned int i, hsize, hmask, entries, prev_val, *hash_count;
const unsigned char *data, *buffer = buf;
struct delta_index *index;
struct index_entry *entry, **hash;
void *mem;
+ unsigned long memsize;
if (!buf || !bufsize)
return NULL;
@@ -155,9 +156,10 @@ struct delta_index * create_delta_index(
hmask = hsize - 1;
/* allocate lookup index */
- mem = malloc(sizeof(*index) +
- sizeof(*hash) * hsize +
- sizeof(*entry) * entries);
+ memsize = sizeof(*index) +
+ sizeof(*hash) * hsize +
+ sizeof(*entry) * entries;
+ mem = malloc(memsize);
if (!mem)
return NULL;
index = mem;
@@ -179,18 +181,26 @@ struct delta_index * create_delta_index(
}
/* then populate the index */
- data = buffer + entries * RABIN_WINDOW - RABIN_WINDOW;
- while (data >= buffer) {
+ prev_val = ~0;
+ for (data = buffer + entries * RABIN_WINDOW - RABIN_WINDOW;
+ data >= buffer;
+ data -= RABIN_WINDOW) {
unsigned int val = 0;
for (i = 1; i <= RABIN_WINDOW; i++)
val = ((val << 8) | data[i]) ^ T[val >> RABIN_SHIFT];
- i = val & hmask;
- entry->ptr = data + RABIN_WINDOW;
- entry->val = val;
- entry->next = hash[i];
- hash[i] = entry++;
- hash_count[i]++;
- data -= RABIN_WINDOW;
+ if (val == prev_val) {
+ /* keep the lowest of consecutive identical blocks */
+ entry[-1].ptr = data + RABIN_WINDOW;
+ } else {
+ prev_val = val;
+ i = val & hmask;
+ entry->ptr = data + RABIN_WINDOW;
+ entry->val = val;
+ entry->next = hash[i];
+ hash[i] = entry++;
+ hash_count[i]++;
+ entries--;
+ }
}
/*
@@ -220,6 +230,10 @@ struct delta_index * create_delta_index(
}
free(hash_count);
+ /* If we didn't use all hash entries, free the unused memory. */
+ if (entries)
+ index = realloc(index, memsize - entries * sizeof(*entry));
+
return index;
}
^ permalink raw reply related
* Re: gitk highlight feature
From: Paul Mackerras @ 2006-05-03 2:55 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0605021721540.4086@g5.osdl.org>
Linus Torvalds writes:
> The obvious way to do it would be to just have two buttons per view: one
> exclusive one (for the main view - only one selected at a time), and the
> other one for the "highlight" one where you could allow multiple views to
> be selected for highlighting.
That's hard to do in a menu, but I could do it in a separate pane.
Or, I could draw a series of tabs between the menu bar and the
graph/headline/author/date panes. Each tab would have the view name,
a radiobutton to select it for highlighting, and a close button.
Paul.
^ permalink raw reply
* Re: [PATCH 3/3] fetch: optionally store the current remote information in the config
From: Junio C Hamano @ 2006-05-03 0:36 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0605021422520.7051@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> Well, I took the liberty of adjusting the first one in the
>> series and tonight's "pu" has that one and the second one.
>> I haven't touched the third one yet, though.
>
> I don't think it is worth introducing yet another way to specify
> short-cuts for remote information, if there is not at least one problem
> which can get solved easier with it than with the other two ways.
I think the biggest contribution this series might bring in is
to send a message that we would want to have things in config,
not outside -- otherwise people might be tempted to do "while on
this branch use this remote to fetch/pull from by default"
outside config (perhaps abusing .git/branches, which _is_ per
branch configuration).
>> I do not like that hidden environment variable that sits in the
>> command I use everyday, waiting to be triggered to update my
>> .config file, possibly by my PEBCAK mistake when I did not want
>> it to do so.
>
> I will refactor it.
Thanks.
> I fixed this error (see separate patch). This was reintroduced by
> carelessly checking argv[1] for "--list" and "-l", even if argc < 2.
Thanks.
> As for the trust in repo-config writing the config: it is all done by
> calling git_config_set() or git_config_set_multivar(), which you use
> yourself to set core.repositoryformatversion, among other values.
Since that happens in a freshly created empty config, I do not
have to have a high confidence for that case, compared to the
case it has to muck with random configuration files people
already have populated with arbitrary gunk. In any case, I
haven't seen breakage myself recently so hopefully it is safe
enough now ;-).
^ permalink raw reply
* Re: gitk highlight feature
From: Linus Torvalds @ 2006-05-03 0:23 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0605021659430.4086@g5.osdl.org>
On Tue, 2 May 2006, Linus Torvalds wrote:
>
> Ie not a separate menu, but having the current "view" radio buttons be
> more flexible.
The obvious way to do it would be to just have two buttons per view: one
exclusive one (for the main view - only one selected at a time), and the
other one for the "highlight" one where you could allow multiple views to
be selected for highlighting.
Linus
^ permalink raw reply
* Re: gitk highlight feature
From: Paul Mackerras @ 2006-05-03 0:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vejzcj8da.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano writes:
> Eh, the string entered by me is quoted by the program, or do I
> have to quote it myself? I suspect it should not be so bad to
> code, even if you have to do it with tcl ;-).
It's split up into arguments at whitespace unless the whitespace is
quoted, just like the shell does. I wrote tcl code to do the
splitting and quoting according to the shell rules. So you can, for
example, put:
--unpacked --since='2 days ago'
in there and it will pass two arguments to git-rev-list, the second
containing the embedded spaces (but without the single-quotes).
Paul.
^ permalink raw reply
* Re: gitk highlight feature
From: Linus Torvalds @ 2006-05-03 0:07 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
In-Reply-To: <17495.61142.677439.171773@cargo.ozlabs.ibm.com>
On Wed, 3 May 2006, Paul Mackerras wrote:
>
> I just pushed out some changes to gitk which allow you to use one view
> to highlight another (see the "Highlight" submenu under the "View"
> menu), and which allow you to specify arbitrary git-rev-list arguments
> for a view. The arguments string uses shell quoting conventions.
Ok. It looks interesting. I don't have a particular issue to try it with,
but the bold-face certainly stands out enough that it was easy to ask for
a high-light of any commits that changed the kernel/ subdirectory, and it
was visually very obvious.
The interface does feel a bit awkward, though. Separating out "view" and
"highlight" into two separate things seems wrong. Wouldn't it be better to
just have multiple views in the "view" menu, and just a way to mark one or
more of them as "highliht views".
Ie not a separate menu, but having the current "view" radio buttons be
more flexible.
> I had been thinking of having fields in the view editor dialog where
> you could put in refs that you did and didn't want included, date
> specifiers, etc., all in separate fields with suitable labels. Now
> I'm thinking that it's probably just as convenient to put
> "ORIG_HEAD.." into the git-rev-list arguments field as it is to put
> "ORIG_HEAD" in the "Don't include commits reachable from this" field.
Yeah. I think it's easier with a single thing, just let people stick it
there.
> There may be an argument for having fields for "Exclude commits before
> this date" and "Exclude commits after this date", because those things
> often have spaces in them (e.g. "2 weeks ago") which would have to be
> quoted in the git-rev-list arguments field.
I alwaus use "2.weeks.ago" instead, but I guess you could do a calendar
widget or something.
Linus
^ permalink raw reply
* Re: [PATCH] built-in "git grep" (git grip).
From: Junio C Hamano @ 2006-05-03 0:01 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <7vbqugks8j.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Linus Torvalds <torvalds@osdl.org> writes:
>
>> On Tue, 2 May 2006, Junio C Hamano wrote:
>>>
>>> - The shell-script one, if you use GNU grep, accepts more
>>> options to grep than what the current built-in one supports.
>>> Notable ones that are missing: fixed strings (-F), patterns
>>> from file (-f), count matches (-c), omit filenames (-h),
>>> skipping binary files (-I, -U), files without match (-L),
>>> pcre (-P), silent (-q), word expression (-w), NUL (-z). They
>>> should be easy to add if somebody cares enough, and I plan to
>>> do a few myself before pushing it out to "master".
>>
>> I use "-w" all the time, along with -5 or similar to get context for the
>> grep.
>
> Noted; -w is missing; -A/-B/-C are already there so you could
> say -C 5 instead, and -<n> should be easy to add.
I did both -<n> and -w, and pushed it out in "next".
What we have:
-<n>, -[ABC] <n> (and -[ABC]<n>)
-E
-G
-H (but it is an no-op -- we always show name)
-c
-e (you can do multiple patterns now)
-i
-n
-v
-w
-l
What are still missing:
-I (easy)
-L (probably a bit intrusive)
-P (code is easy -- deciding dependency on pcre is OK is harder)
-U (probably not so easy but may be useful)
-Z (probably easy but is it useful?)
-q (may not be worth doing)
-z (easy but pointless)
-F (dunno)
-f (with the enhancement to do multiple -e, trivial to add this)
^ permalink raw reply
* Re: Features ask for git-send-email
From: Bertrand Jacquin @ 2006-05-02 23:51 UTC (permalink / raw)
To: David Woodhouse; +Cc: Git Mailing List
In-Reply-To: <1146612793.19101.50.camel@pmac.infradead.org>
On 5/3/06, David Woodhouse <dwmw2@infradead.org> wrote:
> On Wed, 2006-05-03 at 00:46 +0200, Bertrand Jacquin wrote:
> > I tryed it. I used this patch again master git git release
> >
> > And I got the following with git-send-email :
> >
> > Use of uninitialized value in hash element at /usr/bin/git-send-email line 437.
> > Use of uninitialized value in hash element at /usr/bin/git-send-email line 437.
> > <>: missing or malformed local part
>
> Interesting; it worked for me. Does the same happen _without_ the patch
> applied?
It appear without in 1.3.1 and I can't seed mail with too.
Also, 1.2.4 work fine here (without patch).
I don't make any test for other version (too tired for now).
I use exim 4.60 as SMTP server (if it can help).
--
Beber
#e.fr@freenode
^ permalink raw reply
* Re: gitk highlight feature
From: Junio C Hamano @ 2006-05-02 23:48 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
In-Reply-To: <17495.61142.677439.171773@cargo.ozlabs.ibm.com>
Paul Mackerras <paulus@samba.org> writes:
> I just pushed out some changes to gitk which allow you to use one view
> to highlight another (see the "Highlight" submenu under the "View"
> menu), and which allow you to specify arbitrary git-rev-list arguments
> for a view. The arguments string uses shell quoting conventions.
Eh, the string entered by me is quoted by the program, or do I
have to quote it myself? I suspect it should not be so bad to
code, even if you have to do it with tcl ;-).
> I had been thinking of having fields in the view editor dialog where
> you could put in refs that you did and didn't want included, date
> specifiers, etc., all in separate fields with suitable labels. Now
> I'm thinking that it's probably just as convenient to put
> "ORIG_HEAD.." into the git-rev-list arguments field as it is to put
> "ORIG_HEAD" in the "Don't include commits reachable from this" field.
> There may be an argument for having fields for "Exclude commits before
> this date" and "Exclude commits after this date", because those things
> often have spaces in them (e.g. "2 weeks ago") which would have to be
> quoted in the git-rev-list arguments field.
>
> Thoughts?
Calendar widgets. BTW, "rev-list --since=2.days.ago" would work
rather well ;-).
^ permalink raw reply
* gitk highlight feature
From: Paul Mackerras @ 2006-05-02 23:44 UTC (permalink / raw)
To: git; +Cc: torvalds
I just pushed out some changes to gitk which allow you to use one view
to highlight another (see the "Highlight" submenu under the "View"
menu), and which allow you to specify arbitrary git-rev-list arguments
for a view. The arguments string uses shell quoting conventions.
I had been thinking of having fields in the view editor dialog where
you could put in refs that you did and didn't want included, date
specifiers, etc., all in separate fields with suitable labels. Now
I'm thinking that it's probably just as convenient to put
"ORIG_HEAD.." into the git-rev-list arguments field as it is to put
"ORIG_HEAD" in the "Don't include commits reachable from this" field.
There may be an argument for having fields for "Exclude commits before
this date" and "Exclude commits after this date", because those things
often have spaces in them (e.g. "2 weeks ago") which would have to be
quoted in the git-rev-list arguments field.
Thoughts?
Paul.
^ permalink raw reply
* Re: [ANNOUNCE] Git wiki
From: Junio C Hamano @ 2006-05-02 23:33 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060502232553.GL27689@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> I'm personally not exceptionally fond of wikis (other than Wikipedia)
> but a wish to have one has been expressed several times and I hope it
> will be helpful for the Git community; not only the newbies might dig
> (and especially exchange!) some useful information, tips'n'trick and
> such. Ideally, it could become a melting pot for the Documentation/
> directories or the rather austere (I take patches) Git homepage - or
> something entirely different. Whatever _you_ make from it.
Thanks for doing this. I am not a Wiki person myself, and
would rather want to see we have useful and authoritative bits
in the Documentation set, but this would help the community.
I'd love to see somebody volunteer to act as an editor to feed
cooked topics for inclusion of the Documentation/ set. Anybody?
^ permalink raw reply
* Re: Features ask for git-send-email
From: David Woodhouse @ 2006-05-02 23:33 UTC (permalink / raw)
To: Bertrand Jacquin; +Cc: Git Mailing List
In-Reply-To: <4fb292fa0605021546i45c740c4i42c64125b8c560e@mail.gmail.com>
On Wed, 2006-05-03 at 00:46 +0200, Bertrand Jacquin wrote:
> I tryed it. I used this patch again master git git release
>
> And I got the following with git-send-email :
>
> Use of uninitialized value in hash element at /usr/bin/git-send-email line 437.
> Use of uninitialized value in hash element at /usr/bin/git-send-email line 437.
> <>: missing or malformed local part
Interesting; it worked for me. Does the same happen _without_ the patch
applied?
--
dwmw2
^ permalink raw reply
* Re: [PATCH] repo-config: support --get-regexp and fix crash
From: Junio C Hamano @ 2006-05-02 23:30 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0605021422150.7051@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Junio made me aware of a crash, a fix for which was too easy to
> merit a separate patch.
Not really. The fix is clean-and-obvious, and is readily
applicable to "master" without being cooked in "next". On the
other hand, --get-regexp may or may not be so; by conflating the
two, you are delaying the trivial and useful fix unnecessarily.
I already split the patch and applied the fix on "master", while
keeping the rest in "pu" (sorry, I ran out of patience to test
everything to put it in "next" -- will do so tomorrow).
It is usually a good idea to avoid making an otherwise good
clean patch a hostage to new features (intentionally or
accidentally).
> Strange thing I realized: A value is white-space-trimmed at the end
> only if the line does not end with a comment. This fact is accounted
> for in the new tests.
Thanks - a note like this helps me quite a bit, because I
usually apply e-mailed patches with --whitespace=strip, which
would have destroyed the test, leaving me scratching my head
without such a notice.
^ permalink raw reply
* Re: [PATCH] cache-tree: replace a sscanf() by two strtol() calls
From: Junio C Hamano @ 2006-05-02 23:26 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0605020327400.31493@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On one of my systems, sscanf() first calls strlen() on the buffer. But
> this buffer is not terminated by NUL. So git crashed.
Interesting.
"git grep sscanf next -- '*.c'" reports handful sscanf() there.
Most of them scan argv[], which are NUL terminated, so they
should be OK. The rest in convert-objects.c, tree-walk.c, and
tree.c all scan the mode bits in tree objects, which will later
have the pathname component terminated with NUL, so that would
also be OK.
But I think your patch is wrong, and makes it ignore cache-tree
structure; I suspect you have two off-by-one errors and are
making buf and size out of sync.
> Maybe, a better solution would be to store the integers in
> binary form. But I am not familiar with that part of git, and
> further, it would break setups which already have an index
> with cache-tree information.
In theory, it is stashed in the extension section of index so we
could define a new extension type, say "TRE2" and store the
information in the new format. But this is purely a cache used
as optimiation, so we could just say, "make sure to save local
modifications before doing an update, then run 'rm .git/index &&
git-read-tree HEAD' please".
I've applied a fixed up one, but I am actually thinking about
ripping out the whole cache-tree thing and redoing it all in the
index.
Currently the index stores set of blobs after flattening the
hierarchical tree structure, losing the original "tree"
information. We could instead store something that looks like
"ls-tree -t -r" output (plus the toplevel tree information which
"ls-tree -t -r" does not give you). Just like an update-index
on the path t/t0000-basic.sh invalidates the cache-tree entry
for "" and "t/", we could either invalidate or recompute (I am
inclined to do the former to make things lazy) these "tree"
entries in the index. This would be more direct way to store
what I am storing in the cache-tree.
Keeping the object names of unchanged subtrees available will
allow us to walk the index and a tree (or two or more trees) in
parallel in various applications. "diff-index --cached" and
"read-tree -m" extract one entry from tree and index for each
blob, but when we have an up-to-date information for a subtree
in the index, and when that subtree matches the corresponding
subtree in the tree object diff-index or read-tree is reading,
the application can short-cut without reading anything in the
subtree.
^ permalink raw reply
* [PATCH] gitweb: Add shorthand URLs for summary and a special html branch
From: Martin Waitz @ 2006-05-02 23:25 UTC (permalink / raw)
To: git
gitweb now supports URLs like .../gitweb.cgi/<projectpath> as a shortcut
for the project summary page and .../gitweb.cgi/<projectpath>/<file.html>
to access .html pages in an "html" branch.
Signed-off-by: Martin Waitz <tali@admingilde.org>
---
gitweb.cgi | 60 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++----
1 files changed, 56 insertions(+), 4 deletions(-)
05d0376478ccc273d12dbe177cf11c62c86ab848
diff --git a/gitweb.cgi b/gitweb.cgi
index c1bb624..959ca3e 100755
--- a/gitweb.cgi
+++ b/gitweb.cgi
@@ -20,6 +20,7 @@ my $cgi = new CGI;
my $version = "264";
my $my_url = $cgi->url();
my $my_uri = $cgi->url(-absolute => 1);
+my $my_path = $cgi->url(-path => 1);
my $rss_link = "";
# absolute fs-path which will be prepended to the project path
@@ -42,8 +43,30 @@ # source of projects list
#my $projects_list = $projectroot;
my $projects_list = "index/index.aux";
+
+my ($action, $project, $file_name, $hash);
+
+# rewrite to support direct access to .html files in the "html" branch
+if ($my_path =~ /^$my_url\/(.*\.git)\/?$/) {
+ $action = "summary";
+ $project = validate_input($1);
+} elsif ($my_path =~ /^$my_url\/(.*\.git)\/(.*\.html)$/) {
+ $action = "blob_html";
+ $project = validate_input($1);
+ $file_name = validate_input($2);
+ $hash = "html:$file_name";
+} elsif ($my_path =~ /^$my_url\/(.*\.git)\/(HEAD|objects\/info\/packs|info\/refs|refs\/.*)$/) {
+ $action = "direct_text";
+ $project = validate_input($1);
+ $file_name = validate_input($2);
+} elsif ($my_path =~ /^$my_url\/(.*\.git)\/(objects\/.*)$/) {
+ $action = "direct_object";
+ $project = validate_input($1);
+ $file_name = validate_input($2);
+}
+
# input validation and dispatch
-my $action = $cgi->param('a');
+$action ||= $cgi->param('a');
if (defined $action) {
if ($action =~ m/[^0-9a-zA-Z\.\-_]/) {
undef $action;
@@ -66,7 +89,7 @@ if (defined $order) {
}
}
-my $project = $cgi->param('p');
+$project ||= $cgi->param('p');
if (defined $project) {
$project = validate_input($project);
if (!defined($project)) {
@@ -88,7 +111,7 @@ if (defined $project) {
exit;
}
-my $file_name = $cgi->param('f');
+$file_name ||= $cgi->param('f');
if (defined $file_name) {
$file_name = validate_input($file_name);
if (!defined($file_name)) {
@@ -96,7 +119,7 @@ if (defined $file_name) {
}
}
-my $hash = $cgi->param('h');
+$hash ||= $cgi->param('h');
if (defined $hash) {
$hash = validate_input($hash);
if (!defined($hash)) {
@@ -167,6 +190,9 @@ if (!defined $action || $action eq "summ
} elsif ($action eq "blob_plain") {
git_blob_plain();
exit;
+} elsif ($action eq "blob_html") {
+ git_blob_html();
+ exit;
} elsif ($action eq "tree") {
git_tree();
exit;
@@ -203,6 +229,10 @@ if (!defined $action || $action eq "summ
} elsif ($action eq "tag") {
git_tag();
exit;
+} elsif ($action eq "direct_text") {
+ git_direct_text();
+} elsif ($action eq "direct_object") {
+ git_direct_object();
} else {
undef $action;
die_error(undef, "Unknown action.");
@@ -1423,6 +1453,28 @@ sub git_blob_plain {
close $fd;
}
+sub git_blob_html {
+ my $save_as = "$hash";
+ if (defined $file_name) {
+ $save_as = $file_name;
+ }
+ print $cgi->header(-type => "text/html", -charset => 'utf-8', '-content-disposition' => "inline; filename=\"$save_as\"");
+ open my $fd, "-|", "$gitbin/git-cat-file blob $hash" or return;
+ undef $/;
+ print <$fd>;
+ $/ = "\n";
+ close $fd;
+}
+
+sub git_direct_text {
+ print $cgi->header(-type => "test/plain");
+ exec("cat", "$projectroot/$project/$file_name");
+}
+sub git_direct_object {
+ print $cgi->header(-type => "application/binary", -expires => "+1y");
+ exec("cat", "$projectroot/$project/$file_name");
+}
+
sub git_tree {
if (!defined $hash) {
$hash = git_read_head($project);
--
1.3.1.g6ef7
--
Martin Waitz
^ permalink raw reply related
* [ANNOUNCE] Git wiki
From: Petr Baudis @ 2006-05-02 23:25 UTC (permalink / raw)
To: git
Hi,
I have just set up a (fairly crude, but hey, it seems to work) wiki at
http://git.or.cz/gitwiki
It's slow and ugly but if it becomes popular, I will move it to
something better than Apache CGI. ;-) I also haven't written more than
an introductory paragraph on the front page, the rest is up to you.
I'm personally not exceptionally fond of wikis (other than Wikipedia)
but a wish to have one has been expressed several times and I hope it
will be helpful for the Git community; not only the newbies might dig
(and especially exchange!) some useful information, tips'n'trick and
such. Ideally, it could become a melting pot for the Documentation/
directories or the rather austere (I take patches) Git homepage - or
something entirely different. Whatever _you_ make from it.
Editally yours,
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Right now I am having amnesia and deja-vu at the same time. I think
I have forgotten this before.
^ permalink raw reply
* Re: [PATCH] built-in "git grep" (git grip).
From: Linus Torvalds @ 2006-05-02 23:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vbqugks8j.fsf@assigned-by-dhcp.cox.net>
On Tue, 2 May 2006, Junio C Hamano wrote:
>
> On a related tangent, ever since I started using the built-in
> grep with ls-files like wildcard, I find myself typing something
> like this by mistake (this is from my day-job work project that
> has src/mx.js and src/mxstyle.css among other things):
>
> git diff 268a94 -- 'src/mx*'
>
> I am tempted to suggest switching pathspecs used by diff and log
> family to do the same wildcarding, perhaps after tightening the
> wildcard vs directory prefix logic used in the builtin-grep of
> the current "next" tip, which is a bit looser than necessary.
Yeah, the wildcarding is nice. You need to be very careful about it,
though, to make sure that you take full advantage of the path
component optimizations _before_ the wildcards, so that when you do
something like the above ('src/mx*'), you do the "src/" part with the
tree-level optimizations, and only the latter part with the pattern
matching (because you do _not_ want to expand the whole tree when you
don't want to).
That "ls-files.c" thing already does part of this (that whole "prefix_len"
thing for the "longest common prefix").
Linus
^ permalink raw reply
* Re: Features ask for git-send-email
From: Bertrand Jacquin @ 2006-05-02 22:46 UTC (permalink / raw)
To: David Woodhouse; +Cc: Git Mailing List
In-Reply-To: <1146573417.14059.21.camel@pmac.infradead.org>
On 5/2/06, David Woodhouse <dwmw2@infradead.org> wrote:
> On Sat, 2006-04-29 at 15:30 +0200, Bertrand Jacquin wrote:
> > Could it be possible to add a features in git-send-email.perl to
> > accept a differrent charset as iso-8859-1 ? I would like to send
> > fr_FR.utf8 mail as I use git to manager a latex files tree which are
> > written in utf8.
> >
> > Any objection ?
>
> Seems reasonable. I think we just forgot to include the Content-Type:
> header. This fixes it...
I tryed it. I used this patch again master git git release
And I got the following with git-send-email :
Use of uninitialized value in hash element at /usr/bin/git-send-email line 437.
Use of uninitialized value in hash element at /usr/bin/git-send-email line 437.
<>: missing or malformed local part
Use of uninitialized value in hash element at /usr/bin/git-send-email line 437.
Use of uninitialized value in hash element at /usr/bin/git-send-email line 437.
<>: missing or malformed local part
And with my smtp server :
2006-05-03 00:44:01 unexpected disconnection while reading SMTP
command from localhost (localhost.localdomain) [127.0.0.1]
Is it a known bug ? I can't send mail with patch thow :/ I tried to
add Mime-Version: 1.0 too but I got the sam.
--
Beber
#e.fr@freenode
^ permalink raw reply
* Re: cg-mkpatch use case
From: Petr Baudis @ 2006-05-02 22:34 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Belmar-Letelier, git
In-Reply-To: <46a038f90605021519x5ee680b0v78dd5c092e1b191f@mail.gmail.com>
Dear diary, on Wed, May 03, 2006 at 12:19:00AM CEST, I got a letter
where Martin Langhoff <martin.langhoff@gmail.com> said that...
> On 5/3/06, Petr Baudis <pasky@suse.cz> wrote:
> >not many people actually use it nowadays, I believe. You can apply it
> >back using cg-patch (or even patch itself, or git-apply if you are
> >lucky), but it won't automagically extract the commit message and
> >authorship information.
>
> Erm... I don't personally use it, but cg-patch --long-help tells me...
>
> -c::
> Automatically extract the commit message and authorship information
> (if provided) from the patch and commit it after applying it
> successfuly.
>
> Truth in advertising? ;-)
Uhm, no, it just didn't stick in my mind in the storm of cg-patch
improvements. :-) Oops.
So, YES, there IS a way to apply cg-mkpatches preserving autorship and
everything - cg-patch -c. Sorry for the confusion. ;-)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Right now I am having amnesia and deja-vu at the same time. I think
I have forgotten this before.
^ permalink raw reply
* Re: cg-mkpatch use case
From: Martin Langhoff @ 2006-05-02 22:19 UTC (permalink / raw)
To: Petr Baudis; +Cc: Belmar-Letelier, git
In-Reply-To: <20060502215703.GK27689@pasky.or.cz>
On 5/3/06, Petr Baudis <pasky@suse.cz> wrote:
> not many people actually use it nowadays, I believe. You can apply it
> back using cg-patch (or even patch itself, or git-apply if you are
> lucky), but it won't automagically extract the commit message and
> authorship information.
Erm... I don't personally use it, but cg-patch --long-help tells me...
-c::
Automatically extract the commit message and authorship information
(if provided) from the patch and commit it after applying it
successfuly.
Truth in advertising? ;-)
cheers,
martin
^ 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