* 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: [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
* 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: 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
* 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: [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: 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: 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: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: [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: 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
* [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
* [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
* 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
* 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] 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
* 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: Problem using GIT CVS-server
From: Andreas Ericsson @ 2006-05-03 8:17 UTC (permalink / raw)
To: Panagiotis Issaris; +Cc: git
In-Reply-To: <445865A5.5030700@lumumba.uhasselt.be>
Panagiotis Issaris wrote:
> 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.
>
...
> 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
Drop -z3 from command-line. git-cvsserver has no compression support.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Problem using GIT CVS-server
From: Panagiotis Issaris @ 2006-05-03 8:26 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <4458670A.4080205@op5.se>
Hi,
Andreas Ericsson wrote:
> [...]
>
> Drop -z3 from command-line. git-cvsserver has no compression support.
Thanks!
Ahum, painful. That should have been obvious :), but I'm kinda programmed
to use "-z3 -PAd" whenever I do a cvs update. I didn't even notice the
z3 in
my own typing :->
Without the z3, it gives the same error/warning as on checkout:
takis@issaris:/tmp/a/b/project-master$ cvs update -PAd
takis@localhost's password:
closing dbh with active statement handles
takis@issaris:/tmp/a/b/project-master$
With friendly regards,
Takis
^ permalink raw reply
* [PATCH 1/2] Add .gitignore files, list generated files there
From: Pavel Roskin @ 2006-05-03 8:29 UTC (permalink / raw)
To: Catalin Marinas, git
From: Pavel Roskin <proski@gnu.org>
Signed-off-by: Pavel Roskin <proski@gnu.org>
---
.gitignore | 1 +
doc/.gitignore | 2 ++
stgit/.gitignore | 1 +
3 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/.gitignore b/.gitignore
new file mode 100644
index 0000000..378eac2
--- /dev/null
+++ b/.gitignore
@@ -0,0 +1 @@
+build
diff --git a/doc/.gitignore b/doc/.gitignore
new file mode 100644
index 0000000..15ba6af
--- /dev/null
+++ b/doc/.gitignore
@@ -0,0 +1,2 @@
+tutorial.html
+tutorial.pdf
diff --git a/stgit/.gitignore b/stgit/.gitignore
new file mode 100644
index 0000000..0d20b64
--- /dev/null
+++ b/stgit/.gitignore
@@ -0,0 +1 @@
+*.pyc
^ permalink raw reply related
* [PATCH 2/2] Improve "Technical Information" in the tutorial
From: Pavel Roskin @ 2006-05-03 8:29 UTC (permalink / raw)
To: Catalin Marinas, git
In-Reply-To: <20060503082931.1548.14118.stgit@dv.roinet.com>
From: Pavel Roskin <proski@gnu.org>
In the "StGIT patch theory", use traditional (old, new) argument order
of diff. Make formulas more readable. Add more description.
In the "Layout of the .git directory", update the layout, add more
descriptions, organize layout as a table. Sort entries alphabetically -
it's easier to find them this way.
Signed-off-by: Pavel Roskin <proski@gnu.org>
---
doc/tutorial.txt | 123 +++++++++++++++++++++++++++++++-----------------------
1 files changed, 70 insertions(+), 53 deletions(-)
diff --git a/doc/tutorial.txt b/doc/tutorial.txt
index 5899c38..ddc0cf9 100644
--- a/doc/tutorial.txt
+++ b/doc/tutorial.txt
@@ -339,75 +339,92 @@ A bit of StGIT patch theory
---------------------------
We assume that a patch is a diff between two nodes - bottom and top. A
-node is a commit SHA1 id or tree SHA1 id in the GIT terminology:
+node is a commit SHA1 ID or tree SHA1 ID in the GIT terminology:
- P - patch
- N - node
-
- P = diff(Nt, Nb)
+ P = diff(Nb, Nt)
- Nb - bottom (start) node
- Nt - top (end) node
- Nf - first node (for log generation)
+ P - patch
+ Nb - bottom (start) node
+ Nt - top (end) node
-For an ordered stack of patches:
+The order of diff parameters is (old, new). We use "+" for superposition
+of patches. For an ordered stack of patches:
- P1 = diff(N1, N0)
- P2 = diff(N2, N1)
+ P1 = diff(N0, N1)
+ P2 = diff(N1, N2)
...
+ Ps = P1 + P2 + P3 + ... + Pn = diff(Nsb, Nst)
+ Ps - the big patch of the whole stack
+ Nsb - bottom stack node (= N0)
+ Nst - top stack node (= Nn)
- Ps = P1 + P2 + P3 + ... = diff(Nst, Nsb)
+When pushing a patch P from the stack, it may happen that the patch
+bottom Nb is different from the stack top Nst, i.e. the patch was
+originally applied to a different node. The patch needs to be adjusted
+to its new position in the stack. First, the new stack top is calculated
+by diff3 merging:
- Ps - the big patch of the whole stack
- Nsb - bottom stack node (= N0)
- Nst - top stack node (= Nn)
+ Nst' = diff3(Nst, Nb, Nt)
-Applying (pushing) a patch on the stack (Nst can differ from Nb) is done
-by diff3 merging. The new patch becomes:
+The order of diff3 parameters is (branch1, ancestor, branch2). If the
+merge succeeds, the patch is adjusted as following:
- P' = diff(Nt', Nb')
Nb' = Nst
- Nt' = diff3(Nst, Nb, Nt)
+ Nt' = Nst'
+ P' = diff(Nb', Nt')
-(note that the diff3 parameters order is: branch1, ancestor, branch2)
-The above operation allows easy patch re-ordering.
Removing (popping) a patch from the stack is done by simply setting the
Nst to Nb.
+This approach allows easy reordering of patches. To reorder applied
+patches, user should pop them first and then push them back to the stack
+in the desired order. Unless the patches modify the same or adjacent
+lines in the same files, StGIT should be able to adjust the patches
+automatically for the new order.
+
Layout of the .git directory
----------------------------
- HEAD -> refs/heads/<something>
- objects/
- ??/
- ...
- refs/
- heads/
- master - the master commit id
- ...
- bases/
- master - the bottom id of the stack (to get a big diff)
- ...
- tags/
- ...
- branches/
- ...
- patches/
- master/
- applied - list of applied patches
- unapplied - list of not-yet applied patches
- current - name of the topmost patch
- patch1/
- bottom - the bottom id of the patch
- top - the top id of the patch
- description - the patch description
- authname - author's name
- authemail - author's e-mail
- commname - committer's name
- commemail - committer's e-mail
- patch2/
- ...
- ...
- ...
+`-----------------------`----------------------------------------------
+`branches/` remote branches to pull (deprecated)
+`hooks/` scripts executed by git on some events
+`info/`
+` exclude` list of files ignored for the purpose of commit
+` refs` list of commit IDs from refs/ (used on servers)
+`objects/` git objects
+` ??/` unpacked objects
+` info/`
+` packs` list of object packs
+` pack/` object packs
+` *.idx` index files
+` *.pack` actual pack files
+`patches/` storage for StGIT patches
+` master/` patches for the master branch
+` patches/` storage for individual patches
+` patch1/` one of the StGIT patches
+` authdate` patch date
+` authemail` author's e-mail
+` authname` author's name
+` bottom` bottom ID of the patch
+` bottom.old` old bottom ID of the patch (for undo)
+` commemail` committer's e-mail
+` commname` committer's name
+` description` patch description
+` top` top ID of the patch
+` top.old` old top ID of the patch (for undo)
+` patch2/` another StGIT patch
+` ...`
+` applied` list of applied patches
+` description` branch description
+` current` name of the topmost patch
+` unapplied` list of unapplied patches
+`refs/` various significant commit IDs
+` bases/` bottom commit IDs of the patch stacks
+` heads/` top commit IDs of branches
+` patches/` commit IDs of StGIT patches
+` tags/` commit IDs of tags (commit and tag objects)
+`remotes/` remote branches to pull and push
+`HEAD` reference to the current branch
+-----------------------------------------------------------------------
^ permalink raw reply related
* segfault bug in internal git grep from next
From: Marco Roeland @ 2006-05-03 8:32 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 1148 bytes --]
Hello!
I'm using the next branch as of commit 6a40327d242dac9f85c6d63c94d537b45ba86e89
A segfault occurs in using the new builtin grep when using it on a
binary file, so no regular \n endings.
A testcase is the attached (if it survives the vger filters) "git.png"
icon as it is used for example on the http://www.kernel.org/git website.
I tried the obvious, this is the line that gives the segfault:
diff --git a/builtin-grep.c b/builtin-grep.c
index 09e3677..5d4f319 100644
--- a/builtin-grep.c
+++ b/builtin-grep.c
@@ -121,7 +121,7 @@ static void compile_patterns(struct grep
static char *end_of_line(char *cp, unsigned long *left)
{
unsigned long l = *left;
- while (l && *cp != '\n') {
+ while (l && *cp && *cp != '\n') {
l--;
cp++;
}
but it did not solve the problem. Unfortunately I have no time at the
moment to investigate further, so just this report at the moment.
On a side-note it might be handy to add the icon to the main git
repository and to use it in (new) test cases for git grep. Of course
grepping in binary files is mostly not very useful, but lots of
real-world repo's have some binaries.
--
Marco Roeland
[-- Attachment #2: git.png --]
[-- Type: image/png, Size: 208 bytes --]
^ permalink raw reply related
* Re: [ANNOUNCE] Git wiki
From: Paolo Ciarrocchi @ 2006-05-03 8:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Petr Baudis, git
In-Reply-To: <7virooj92i.fsf@assigned-by-dhcp.cox.net>
On 5/3/06, Junio C Hamano <junkio@cox.net> wrote:
> 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?
Junio, would be possible for you to write a Roadmap in a Wiki page,
similar to what Mercurial did here:
http://www.selenic.com/mercurial/wiki/index.cgi/RoadMap ?
BTW, do you know why GIT has not been selected as SCM for OpenSolaris?
(they choose Mercurial).
Ciao,
--
Paolo
http://paolociarrocchi.googlepages.com
^ permalink raw reply
* Re: Problem using GIT CVS-server
From: Andreas Ericsson @ 2006-05-03 8:44 UTC (permalink / raw)
To: Panagiotis Issaris; +Cc: git
In-Reply-To: <4458691A.4010007@lumumba.uhasselt.be>
Panagiotis Issaris wrote:
> Hi,
>
> Andreas Ericsson wrote:
>
>> [...]
>>
>> Drop -z3 from command-line. git-cvsserver has no compression support.
>
>
> Thanks!
>
> Ahum, painful. That should have been obvious :), but I'm kinda programmed
> to use "-z3 -PAd" whenever I do a cvs update. I didn't even notice the
> z3 in
> my own typing :->
>
>
> Without the z3, it gives the same error/warning as on checkout:
> takis@issaris:/tmp/a/b/project-master$ cvs update -PAd
> takis@localhost's password:
> closing dbh with active statement handles
> takis@issaris:/tmp/a/b/project-master$
>
That error message comes from your client. I have no idea why, and now
that I'm a git fanatic I'll stay blissfully ignorant of CVS' internal
workings. Martyn and Martin (the dynamic duo that wrote the cvsserver
thingie) might be able to tell you more.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [ANNOUNCE] Git wiki
From: Petr Baudis @ 2006-05-03 9:00 UTC (permalink / raw)
To: Paolo Ciarrocchi; +Cc: Junio C Hamano, git
In-Reply-To: <4d8e3fd30605030139k33c5a404k54861fdd02c87134@mail.gmail.com>
Dear diary, on Wed, May 03, 2006 at 10:39:07AM CEST, I got a letter
where Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com> said that...
> On 5/3/06, Junio C Hamano <junkio@cox.net> wrote:
> >I'd love to see somebody volunteer to act as an editor to feed
> >cooked topics for inclusion of the Documentation/ set. Anybody?
I think this has time and someone might emerge naturally.
> Junio, would be possible for you to write a Roadmap in a Wiki page,
> similar to what Mercurial did here:
> http://www.selenic.com/mercurial/wiki/index.cgi/RoadMap ?
You can already find a similar (albeit a bit more low-level) document at
http://kernel.org/git/?p=git/git.git;a=blob;hb=todo;f=TODO
but you can certainly add a link to it to the wiki. ;-)
> BTW, do you know why GIT has not been selected as SCM for OpenSolaris?
> (they choose Mercurial).
I think it's explained somewhere in their forums (or mailing lists or
whatever they actually _are_).
--
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
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