* 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
* Re: [ANNOUNCE] Git wiki
From: Paolo Ciarrocchi @ 2006-05-03 9:13 UTC (permalink / raw)
To: Petr Baudis; +Cc: Junio C Hamano, git
In-Reply-To: <20060503090007.GM27689@pasky.or.cz>
On 5/3/06, Petr Baudis <pasky@suse.cz> wrote:
> 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. ;-)
I was looking for something more "high level but I'll try to add that
link to the wiki as soon as I back home from work.
> > 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_).
I only found the announcement, not the rationales.
Ciao,
--
Paolo
http://paolociarrocchi.googlepages.com
^ permalink raw reply
* Re: Problem using GIT CVS-server
From: Martin Langhoff @ 2006-05-03 10:11 UTC (permalink / raw)
To: Panagiotis Issaris; +Cc: git
In-Reply-To: <445865A5.5030700@lumumba.uhasselt.be>
On 5/3/06, Panagiotis Issaris <takis@lumumba.uhasselt.be> wrote:
> I've tried using git-cvsserver, but keep running into problems:
Panagiotis,
thanks a lot for the feedback! cvsserver has mainly been
tried/debugged with a few repositories, mainly the moodle.git
repository that we host, which is an import from a CVS repo.
> 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.
Hmmm. 100% reproduceable -- looking at it now.
> When doing a subsequent update, it doesn't seem to do anything,
> but reports two error messages/warnings.
...
> closing dbh with active statement handles
I thought we had gotten rid of those. In any case, I don't see that
error, and it's just a silly warning from DBI, as we are using cached
statements. As it happens when cvsserver is shutting down, it doesn't
actually break the protocol.
> server doesn't support gzip-file-contents
That warning is harmless, and always there. I did look once at
implementing gzip compression, but in some cases it implies creating
extra temp files to calculate the size, so I've opted to leave it for
some other day.
OTOH, we could declare that we handle it, and never actually send a
gzipped file ;-) as long as we can handle gzipped content from the
client.
cheers,
martin
^ permalink raw reply
* [PATCH] fix various typos in documentation
From: Matthias Kestenholz @ 2006-05-03 10:51 UTC (permalink / raw)
To: git
Signed-off-by: Matthias Kestenholz <matthias@spinlock.ch>
---
Documentation/git-diff-tree.txt | 2 +-
Documentation/git-update-index.txt | 2 +-
revision.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
3b68af9927782ef8b602cca0cdcc446c4dd468ca
diff --git a/Documentation/git-diff-tree.txt b/Documentation/git-diff-tree.txt
index 2169169..906830d 100644
--- a/Documentation/git-diff-tree.txt
+++ b/Documentation/git-diff-tree.txt
@@ -92,7 +92,7 @@ separated with a single space are given.
Furthermore, it lists only files which were modified
from all parents.
--cc::
+--cc::
This flag changes the way a merge commit patch is displayed,
in a similar way to the '-c' option. It implies the '-c'
and '-p' options and further compresses the patch output
diff --git a/Documentation/git-update-index.txt b/Documentation/git-update-index.txt
index d4137fc..74844d1 100644
--- a/Documentation/git-update-index.txt
+++ b/Documentation/git-update-index.txt
@@ -11,7 +11,7 @@ SYNOPSIS
[verse]
'git-update-index'
[--add] [--remove | --force-remove] [--replace]
- [--refresh [-q] [--unmerged] [--ignore-missing]]
+ [--refresh] [-q] [--unmerged] [--ignore-missing]
[--cacheinfo <mode> <object> <file>]\*
[--chmod=(+|-)x]
[--assume-unchanged | --no-assume-unchanged]
diff --git a/revision.c b/revision.c
index ad78efd..c6e8702 100644
--- a/revision.c
+++ b/revision.c
@@ -574,7 +574,7 @@ int setup_revisions(int argc, const char
revs->max_count = atoi(arg + 12);
continue;
}
- /* accept -<digit>, like traditilnal "head" */
+ /* accept -<digit>, like traditional "head" */
if ((*arg == '-') && isdigit(arg[1])) {
revs->max_count = atoi(arg + 1);
continue;
--
1.3.1.g7464
^ permalink raw reply related
* [PATCH] add documentation for update-index --unresolve
From: Matthias Kestenholz @ 2006-05-03 10:53 UTC (permalink / raw)
To: git, junkio
Signed-off-by: Matthias Kestenholz <matthias@spinlock.ch>
---
I am not sure if this is already clear enough. Maybe this needs more
explanation in the manpage?
---
Documentation/git-update-index.txt | 6 +++++-
update-index.c | 2 +-
2 files changed, 6 insertions(+), 2 deletions(-)
aa88546740e88b674335e26e342b53e623dcb5c6
diff --git a/Documentation/git-update-index.txt b/Documentation/git-update-index.txt
index 74844d1..a5afaaf 100644
--- a/Documentation/git-update-index.txt
+++ b/Documentation/git-update-index.txt
@@ -15,7 +15,7 @@ SYNOPSIS
[--cacheinfo <mode> <object> <file>]\*
[--chmod=(+|-)x]
[--assume-unchanged | --no-assume-unchanged]
- [--really-refresh]
+ [--really-refresh] [--unresolve]
[--info-only] [--index-info]
[-z] [--stdin]
[--verbose]
@@ -80,6 +80,10 @@ OPTIONS
filesystem that has very slow lstat(2) system call
(e.g. cifs).
+--unresolve::
+ Restores the 'unmerged' or 'needs updating' state of a
+ file during a merge if it was cleared by accident.
+
--info-only::
Do not create objects in the object database for all
<file> arguments that follow this flag; just insert
diff --git a/update-index.c b/update-index.c
index facec8d..9fa3d2b 100644
--- a/update-index.c
+++ b/update-index.c
@@ -473,7 +473,7 @@ static void read_index_info(int line_ter
}
static const char update_index_usage[] =
-"git-update-index [-q] [--add] [--replace] [--remove] [--unmerged] [--refresh] [--cacheinfo] [--chmod=(+|-)x] [--info-only] [--force-remove] [--stdin] [--index-info] [--ignore-missing] [-z] [--verbose] [--] <file>...";
+"git-update-index [-q] [--add] [--replace] [--remove] [--unmerged] [--refresh] [--really-refresh] [--cacheinfo] [--chmod=(+|-)x] [--assume-unchanged] [--info-only] [--force-remove] [--stdin] [--index-info] [--unresolve] [--ignore-missing] [-z] [--verbose] [--] <file>...";
static unsigned char head_sha1[20];
static unsigned char merge_head_sha1[20];
--
1.3.1.g7464
^ permalink raw reply related
* Re: Problem using GIT CVS-server
From: Martin Langhoff @ 2006-05-03 11:11 UTC (permalink / raw)
To: Panagiotis Issaris; +Cc: git
In-Reply-To: <46a038f90605030311s4e05de2dr90277f97a3a5c223@mail.gmail.com>
On 5/3/06, Martin Langhoff <martin.langhoff@gmail.com> wrote:
> Hmmm. 100% reproduceable -- looking at it now.
Grumble. Some recent change has broken cvsserver -- if I rewind to the
commit I made of cvsserver, the checkout works correctly. I suspect
changes to git-diff-tree. However, I'll play dumb and try bisect to
see where it leads...
(Nice thing about bisecting with C code is that as you get closer the
delta is smaller, and the recompile is smaller too ;-)
Ok -- an hour's gone by and I'm still fidgeting with bisect. It seems
to have been broken soon after v1.3.0 but I'm having trouble nailing
the commit, and understanding WRF has changed.
Can you test with git v1.3.0?
martin
^ permalink raw reply
* Re: Problem using GIT CVS-server
From: Panagiotis Issaris @ 2006-05-03 11:36 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git
In-Reply-To: <46a038f90605030411o29af1d1bra3276353347516f6@mail.gmail.com>
Hi,
Martin Langhoff wrote:
> On 5/3/06, Martin Langhoff <martin.langhoff@gmail.com> wrote:
>
>> Hmmm. 100% reproduceable -- looking at it now.
>
>
> Grumble. Some recent change has broken cvsserver -- if I rewind to the
> commit I made of cvsserver, the checkout works correctly. I suspect
> changes to git-diff-tree. However, I'll play dumb and try bisect to
> see where it leads...
>
> (Nice thing about bisecting with C code is that as you get closer the
> delta is smaller, and the recompile is smaller too ;-)
>
> Ok -- an hour's gone by and I'm still fidgeting with bisect. It seems
> to have been broken soon after v1.3.0 but I'm having trouble nailing
> the commit, and understanding WRF has changed.
>
> Can you test with git v1.3.0?
Yes, I installed 1.3.0 using "make prefix=/tmp/testje install"
but, I'm getting the same problem (other then my failing typing
skills ;-) :
takis@issaris:/tmp/a/c$ export PATH=/tmp/testje/bin/:$PATH
takis@issaris:/tmp/a/c$ git --version
git version 1.3.0
takis@issaris:/tmp/a/c$ cvs co -d project-master master
takis@localhost's password:
Permission denied, please try again.
takis@localhost's password:
Permission denied, please try again.
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/c$ which git
/tmp/testje/bin//git
With friendly regards,
Takis
^ permalink raw reply
* Re: Problem using GIT CVS-server
From: Panagiotis Issaris @ 2006-05-03 11:41 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git
In-Reply-To: <46a038f90605030311s4e05de2dr90277f97a3a5c223@mail.gmail.com>
Hi,
Martin Langhoff wrote:
> [...]
> thanks a lot for the feedback! cvsserver has mainly been
> tried/debugged with a few repositories, mainly the moodle.git
> repository that we host, which is an import from a CVS repo.
I didnt even know it existed! :) I was looking for an Eclipse plugin
(anyone heard anything about such a beast after 20060313?), when
I accidently stumbled upon the git-cvsserver manpage, somewhere
on the web.
> [...]
> That warning is harmless, and always there. I did look once at
> implementing gzip compression, but in some cases it implies creating
> extra temp files to calculate the size, so I've opted to leave it for
> some other day.
>
> OTOH, we could declare that we handle it, and never actually send a
> gzipped file ;-) as long as we can handle gzipped content from the
> client.
Not really an issue imho :) I just automatically type -z3 whenever I do
a CVS update :)
BTW, thanks for writing git-cvsserver!
With friendly regards,
Takis
^ permalink raw reply
* Re: Problem using GIT CVS-server
From: Martin Langhoff @ 2006-05-03 11:42 UTC (permalink / raw)
To: Panagiotis Issaris; +Cc: git
In-Reply-To: <445895AC.6070109@lumumba.uhasselt.be>
On 5/3/06, Panagiotis Issaris <takis@lumumba.uhasselt.be> wrote:
> Yes, I installed 1.3.0 using "make prefix=/tmp/testje install"
> but, I'm getting the same problem (other then my failing typing
> skills ;-) :
The problem is that, while you are executing git-cvsserver from
/tmp/testje, git-cvsserver invokes git-log from the path, and that is
the "bad" git-log. Change your PATH in .bashrc so that the /tmp/testje
install takes precedence...
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