* Re: [PATCH] Add a new lstat and fstat implementation based on Win32 API
From: Marius Storm-Olsen @ 2007-09-04 13:56 UTC (permalink / raw)
To: Johannes Sixt, Johannes Schindelin; +Cc: Johannes Sixt, Git Mailing List
In-Reply-To: <46DD473A.8010602@trolltech.com>
[-- Attachment #1: Type: text/plain, Size: 548 bytes --]
Marius Storm-Olsen said the following on 04.09.2007 13:53:
> In the meantime, I've pushed out a new patch
> http://repo.or.cz/w/git/mingw/4msysgit.git?a=commitdiff;h=683775c00d9fb95bcbe4632f95b67a96b902fa59
>
> /me starts another test run, to see how our tests are doing now..
Neat, with the custom stat() changes cherry-picked on top of
4msysgit.git 'devel' branch, I only have one failing testcase
t6024-recursive-merge.sh
when running
$ NO_SYMLINKS=1 make -k
The rest are passing with flying colors!
--
.marius
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 187 bytes --]
^ permalink raw reply
* (unknown)
From: Russ Brown @ 2007-09-04 13:59 UTC (permalink / raw)
To: git
subscribe git
^ permalink raw reply
* Re: HFS+ Unicode weirdness
From: Wincent Colaiuta @ 2007-09-04 13:59 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0709041359310.28586@racer.site>
El 4/9/2007, a las 15:00, Johannes Schindelin escribió:
> Hi,
>
> On Tue, 4 Sep 2007, Wincent Colaiuta wrote:
>
>> On a brand new clone of git.git the file "gitweb/test/M?rchen" is
>> provoking
>> some weird behaviour running on Mac OS X and the toy HFS+ filesystem.
>
> Please search the mail archives. This has come up quite a couple of
> times.
Finally found it: for the record this thread seems to be relevant:
<http://marc.info/?l=git&m=117053359117549&w=2>
For what it's worth Subversion has exactly the same kind of problem
when only some developers in a team work on HFS. For example:
<http://svn.haxx.se/users/archive-2005-12/0373.shtml>
<http://subversion.tigris.org/issues/show_bug.cgi?id=2464>
Hopefully the wait for Apple to release a non-broken filesystem won't
be too long, ZFS being the most likely candidate at this stage.
Cheers,
Wincent
^ permalink raw reply
* [PATCH] Use proper strbuf API, and also simplify cmd_data code.
From: Pierre Habouzit @ 2007-09-04 14:01 UTC (permalink / raw)
To: git; +Cc: Pierre Habouzit
In-Reply-To: <20070904115317.GA3381@artemis.corp>
This patch features the use of strbuf_detach, and prevent the programmer
to mess with allocation directly. The code is as efficent as before, just
more concise and more straightforward.
---
fast-import.c | 29 ++++++++++++-----------------
1 files changed, 12 insertions(+), 17 deletions(-)
diff --git a/fast-import.c b/fast-import.c
index 2f7baf4..1a02481 100644
--- a/fast-import.c
+++ b/fast-import.c
@@ -340,7 +340,7 @@ static struct tag *last_tag;
/* Input stream parsing */
static whenspec_type whenspec = WHENSPEC_RAW;
-static struct strbuf command_buf;
+static struct strbuf command_buf = STRBUF_INIT;
static int unread_command_buf;
static struct recent_command cmd_hist = {&cmd_hist, &cmd_hist, NULL};
static struct recent_command *cmd_tail = &cmd_hist;
@@ -1638,17 +1638,15 @@ static void cmd_mark(void)
static void *cmd_data (size_t *size)
{
- size_t length;
- char *buffer;
+ struct strbuf buffer = STRBUF_INIT;
if (prefixcmp(command_buf.buf, "data "))
die("Expected 'data n' command, found: %s", command_buf.buf);
if (!prefixcmp(command_buf.buf + 5, "<<")) {
char *term = xstrdup(command_buf.buf + 5 + 2);
- size_t sz = 8192, term_len = command_buf.len - 5 - 2;
- length = 0;
- buffer = xmalloc(sz);
+ size_t term_len = command_buf.len - 5 - 2;
+
for (;;) {
read_line(&command_buf, stdin, '\n');
if (command_buf.eof)
@@ -1656,21 +1654,18 @@ static void *cmd_data (size_t *size)
if (term_len == command_buf.len
&& !strcmp(term, command_buf.buf))
break;
- ALLOC_GROW(buffer, length + command_buf.len + 1, sz);
- memcpy(buffer + length,
- command_buf.buf,
- command_buf.len);
- length += command_buf.len;
- buffer[length++] = '\n';
+ strbuf_addbuf(&buffer, &command_buf);
+ strbuf_addch(&buffer, '\n');
}
free(term);
}
else {
- size_t n = 0;
+ size_t n = 0, length;
+
length = strtoul(command_buf.buf + 5, NULL, 10);
- buffer = xmalloc(length);
+
while (n < length) {
- size_t s = fread(buffer + n, 1, length - n, stdin);
+ size_t s = strbuf_fread(&buffer, length - n, stdin);
if (!s && feof(stdin))
die("EOF in data (%lu bytes remaining)",
(unsigned long)(length - n));
@@ -1679,8 +1674,8 @@ static void *cmd_data (size_t *size)
}
skip_optional_lf();
- *size = length;
- return buffer;
+ *size = buffer.len;
+ return strbuf_detach(&buffer);
}
static int validate_raw_date(const char *src, char *result, int maxlen)
--
1.5.3
^ permalink raw reply related
* [PATCH] Simplify strbuf uses in fast-import.c using the proper functions.
From: Pierre Habouzit @ 2007-09-04 14:01 UTC (permalink / raw)
To: git; +Cc: Pierre Habouzit
In-Reply-To: <20070904115317.GA3381@artemis.corp>
This is just cleaner way to deal with strbufs, using its API rather than
reinventing it in the module (e.g. strbuf_append_string is just the plain
strbuf_addstr function, and it was used to perform what strbuf_addch does
anyways).
---
archive-tar.c | 65 ++++++++++++++-------------------------------------------
1 files changed, 16 insertions(+), 49 deletions(-)
diff --git a/archive-tar.c b/archive-tar.c
index a0763c5..c84d7c0 100644
--- a/archive-tar.c
+++ b/archive-tar.c
@@ -78,19 +78,6 @@ static void write_trailer(void)
}
}
-static void strbuf_append_string(struct strbuf *sb, const char *s)
-{
- int slen = strlen(s);
- int total = sb->len + slen;
- if (total + 1 > sb->alloc) {
- sb->buf = xrealloc(sb->buf, total + 1);
- sb->alloc = total + 1;
- }
- memcpy(sb->buf + sb->len, s, slen);
- sb->len = total;
- sb->buf[total] = '\0';
-}
-
/*
* pax extended header records have the format "%u %s=%s\n". %u contains
* the size of the whole string (including the %u), the first %s is the
@@ -100,26 +87,17 @@ static void strbuf_append_string(struct strbuf *sb, const char *s)
static void strbuf_append_ext_header(struct strbuf *sb, const char *keyword,
const char *value, unsigned int valuelen)
{
- char *p;
- int len, total, tmp;
+ int len, tmp;
/* "%u %s=%s\n" */
len = 1 + 1 + strlen(keyword) + 1 + valuelen + 1;
for (tmp = len; tmp > 9; tmp /= 10)
len++;
- total = sb->len + len;
- if (total > sb->alloc) {
- sb->buf = xrealloc(sb->buf, total);
- sb->alloc = total;
- }
-
- p = sb->buf;
- p += sprintf(p, "%u %s=", len, keyword);
- memcpy(p, value, valuelen);
- p += valuelen;
- *p = '\n';
- sb->len = total;
+ strbuf_grow(sb, len);
+ strbuf_addf(sb, "%u %s=", len, keyword);
+ strbuf_add(sb, value, valuelen);
+ strbuf_addch(sb, '\n');
}
static unsigned int ustar_header_chksum(const struct ustar_header *header)
@@ -153,8 +131,7 @@ static void write_entry(const unsigned char *sha1, struct strbuf *path,
struct strbuf ext_header;
memset(&header, 0, sizeof(header));
- ext_header.buf = NULL;
- ext_header.len = ext_header.alloc = 0;
+ strbuf_init(&ext_header);
if (!sha1) {
*header.typeflag = TYPEFLAG_GLOBAL_HEADER;
@@ -225,8 +202,8 @@ static void write_entry(const unsigned char *sha1, struct strbuf *path,
if (ext_header.len > 0) {
write_entry(sha1, NULL, 0, ext_header.buf, ext_header.len);
- free(ext_header.buf);
}
+ strbuf_release(&ext_header);
write_blocked(&header, sizeof(header));
if (S_ISREG(mode) && buffer && size > 0)
write_blocked(buffer, size);
@@ -235,11 +212,11 @@ static void write_entry(const unsigned char *sha1, struct strbuf *path,
static void write_global_extended_header(const unsigned char *sha1)
{
struct strbuf ext_header;
- ext_header.buf = NULL;
- ext_header.len = ext_header.alloc = 0;
+
+ strbuf_init(&ext_header);
strbuf_append_ext_header(&ext_header, "comment", sha1_to_hex(sha1), 40);
write_entry(NULL, NULL, 0, ext_header.buf, ext_header.len);
- free(ext_header.buf);
+ strbuf_release(&ext_header);
}
static int git_tar_config(const char *var, const char *value)
@@ -260,28 +237,18 @@ static int write_tar_entry(const unsigned char *sha1,
const char *base, int baselen,
const char *filename, unsigned mode, int stage)
{
- static struct strbuf path;
+ static struct strbuf path = STRBUF_INIT;
int filenamelen = strlen(filename);
void *buffer;
enum object_type type;
unsigned long size;
- if (!path.alloc) {
- path.buf = xmalloc(PATH_MAX);
- path.alloc = PATH_MAX;
- path.len = path.eof = 0;
- }
- if (path.alloc < baselen + filenamelen + 1) {
- free(path.buf);
- path.buf = xmalloc(baselen + filenamelen + 1);
- path.alloc = baselen + filenamelen + 1;
- }
- memcpy(path.buf, base, baselen);
- memcpy(path.buf + baselen, filename, filenamelen);
- path.len = baselen + filenamelen;
- path.buf[path.len] = '\0';
+ strbuf_grow(&path, MAX(PATH_MAX, baselen + filenamelen + 1));
+ strbuf_reset(&path);
+ strbuf_add(&path, base, baselen);
+ strbuf_add(&path, filename, filenamelen);
if (S_ISDIR(mode) || S_ISGITLINK(mode)) {
- strbuf_append_string(&path, "/");
+ strbuf_addch(&path, '/');
buffer = NULL;
size = 0;
} else {
--
1.5.3
^ permalink raw reply related
* [PATCH] Rework strbuf API and semantics.
From: Pierre Habouzit @ 2007-09-04 14:01 UTC (permalink / raw)
To: git; +Cc: Pierre Habouzit
In-Reply-To: <20070904115317.GA3381@artemis.corp>
A strbuf can be used to store byte arrays, or as an extended string
library. The `buf' member can be passed to any C legacy string function,
because strbuf operations always ensure there is a terminating \0 at the end
of the buffer, not accounted in the `len' field of the structure.
A strbuf can be used to generate a string/buffer whose final size is not
really known, and then "strbuf_detach" can be used to get the built buffer,
and keep the wrapping "strbuf" structure usable for further work again.
Other interesting feature: strbuf_grow(sb, size) ensure that there is
enough allocated space in `sb' to put `size' new octets of data in the
buffer. It helps avoiding reallocating data for nothing when the problem the
strbuf helps to solve has a known typical size.
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
---
archive-tar.c | 2 +-
fast-import.c | 15 +++++-----
mktree.c | 4 +--
strbuf.c | 85 +++++++++++++++++++++++++++++++++++++++++++++++---------
strbuf.h | 41 ++++++++++++++++++++++++++-
5 files changed, 119 insertions(+), 28 deletions(-)
diff --git a/archive-tar.c b/archive-tar.c
index 66fe3e3..a0763c5 100644
--- a/archive-tar.c
+++ b/archive-tar.c
@@ -166,7 +166,7 @@ static void write_entry(const unsigned char *sha1, struct strbuf *path,
sprintf(header.name, "%s.paxheader", sha1_to_hex(sha1));
} else {
if (verbose)
- fprintf(stderr, "%.*s\n", path->len, path->buf);
+ fprintf(stderr, "%.*s\n", (int)path->len, path->buf);
if (S_ISDIR(mode) || S_ISGITLINK(mode)) {
*header.typeflag = TYPEFLAG_DIR;
mode = (mode | 0777) & ~tar_umask;
diff --git a/fast-import.c b/fast-import.c
index 078079d..2f7baf4 100644
--- a/fast-import.c
+++ b/fast-import.c
@@ -1595,7 +1595,7 @@ static void read_next_command(void)
} else {
struct recent_command *rc;
- command_buf.buf = NULL;
+ strbuf_detach(&command_buf);
read_line(&command_buf, stdin, '\n');
if (command_buf.eof)
return;
@@ -1649,7 +1649,6 @@ static void *cmd_data (size_t *size)
size_t sz = 8192, term_len = command_buf.len - 5 - 2;
length = 0;
buffer = xmalloc(sz);
- command_buf.buf = NULL;
for (;;) {
read_line(&command_buf, stdin, '\n');
if (command_buf.eof)
@@ -1657,11 +1656,11 @@ static void *cmd_data (size_t *size)
if (term_len == command_buf.len
&& !strcmp(term, command_buf.buf))
break;
- ALLOC_GROW(buffer, length + command_buf.len, sz);
+ ALLOC_GROW(buffer, length + command_buf.len + 1, sz);
memcpy(buffer + length,
command_buf.buf,
- command_buf.len - 1);
- length += command_buf.len - 1;
+ command_buf.len);
+ length += command_buf.len;
buffer[length++] = '\n';
}
free(term);
@@ -2101,7 +2100,7 @@ static void cmd_new_commit(void)
}
/* file_change* */
- while (!command_buf.eof && command_buf.len > 1) {
+ while (!command_buf.eof && command_buf.len > 0) {
if (!prefixcmp(command_buf.buf, "M "))
file_change_m(b);
else if (!prefixcmp(command_buf.buf, "D "))
@@ -2256,7 +2255,7 @@ static void cmd_reset_branch(void)
else
b = new_branch(sp);
read_next_command();
- if (!cmd_from(b) && command_buf.len > 1)
+ if (!cmd_from(b) && command_buf.len > 0)
unread_command_buf = 1;
}
@@ -2273,7 +2272,7 @@ static void cmd_checkpoint(void)
static void cmd_progress(void)
{
- fwrite(command_buf.buf, 1, command_buf.len - 1, stdout);
+ fwrite(command_buf.buf, 1, command_buf.len, stdout);
fputc('\n', stdout);
fflush(stdout);
skip_optional_lf();
diff --git a/mktree.c b/mktree.c
index d86dde8..86de5eb 100644
--- a/mktree.c
+++ b/mktree.c
@@ -92,7 +92,6 @@ int main(int ac, char **av)
strbuf_init(&sb);
while (1) {
- int len;
char *ptr, *ntr;
unsigned mode;
enum object_type type;
@@ -101,7 +100,6 @@ int main(int ac, char **av)
read_line(&sb, stdin, line_termination);
if (sb.eof)
break;
- len = sb.len;
ptr = sb.buf;
/* Input is non-recursive ls-tree output format
* mode SP type SP sha1 TAB name
@@ -111,7 +109,7 @@ int main(int ac, char **av)
die("input format error: %s", sb.buf);
ptr = ntr + 1; /* type */
ntr = strchr(ptr, ' ');
- if (!ntr || sb.buf + len <= ntr + 41 ||
+ if (!ntr || sb.buf + sb.len <= ntr + 40 ||
ntr[41] != '\t' ||
get_sha1_hex(ntr + 1, sha1))
die("input format error: %s", sb.buf);
diff --git a/strbuf.c b/strbuf.c
index e33d06b..db19007 100644
--- a/strbuf.c
+++ b/strbuf.c
@@ -1,41 +1,98 @@
#include "cache.h"
#include "strbuf.h"
+#define STRBUF_GROW_STEP (1 << 10) /* must be a power of 2 */
+
void strbuf_init(struct strbuf *sb) {
- sb->buf = NULL;
- sb->eof = sb->alloc = sb->len = 0;
+ memset(sb, 0, sizeof(*sb));
}
-static void strbuf_begin(struct strbuf *sb) {
+void strbuf_release(struct strbuf *sb) {
free(sb->buf);
+ memset(sb, 0, sizeof(*sb));
+}
+
+void strbuf_reset(struct strbuf *sb) {
+ if (sb->len)
+ sb->buf[sb->len = 0] = '\0';
+}
+
+char *strbuf_detach(struct strbuf *sb) {
+ char *res = sb->buf;
strbuf_init(sb);
+ return res;
+}
+
+void strbuf_grow(struct strbuf *sb, size_t extra) {
+ if (sb->len + extra + STRBUF_GROW_STEP < sb->len)
+ die("you want to use way to much memory");
+
+ sb->alloc = ((sb->len + extra) + STRBUF_GROW_STEP) & ~(STRBUF_GROW_STEP - 1);
+ sb->buf = xrealloc(sb->buf, sb->alloc);
+}
+
+void strbuf_add(struct strbuf *sb, const void *data, size_t len) {
+ strbuf_grow(sb, len);
+ memcpy(sb->buf + sb->len, data, len);
+ sb->len += len;
+ sb->buf[sb->len] = '\0';
}
-static void inline strbuf_add(struct strbuf *sb, int ch) {
- if (sb->alloc <= sb->len) {
- sb->alloc = sb->alloc * 3 / 2 + 16;
- sb->buf = xrealloc(sb->buf, sb->alloc);
+void strbuf_addvf(struct strbuf *sb, const char *fmt, va_list ap)
+{
+ size_t len;
+ va_list ap2;
+
+ va_copy(ap2, ap);
+
+ len = vsnprintf(sb->buf + sb->len, sb->alloc - sb->len, fmt, ap);
+ if (len < 0) {
+ len = 0;
+ }
+ if (len >= sb->alloc - sb->len) {
+ strbuf_grow(sb, len);
+ len = vsnprintf(sb->buf + sb->len, sb->alloc - sb->len, fmt, ap2);
+ if (len >= sb->alloc - sb->len) {
+ len = sb->alloc - sb->len - 1;
+ }
}
- sb->buf[sb->len++] = ch;
+ sb->len = sb->len + len;
+ sb->buf[sb->len] = '\0';
}
-static void strbuf_end(struct strbuf *sb) {
- strbuf_add(sb, 0);
+size_t strbuf_fread(struct strbuf *sb, size_t size, FILE *f) {
+ size_t res;
+
+ strbuf_grow(sb, size);
+ res = fread(sb->buf + sb->len, 1, size, f);
+ if (res > 0) {
+ sb->len += res;
+ sb->buf[sb->len] = '\0';
+ }
+ return res;
}
void read_line(struct strbuf *sb, FILE *fp, int term) {
int ch;
- strbuf_begin(sb);
if (feof(fp)) {
+ strbuf_release(sb);
sb->eof = 1;
return;
}
+
+ strbuf_reset(sb);
while ((ch = fgetc(fp)) != EOF) {
if (ch == term)
break;
- strbuf_add(sb, ch);
+ strbuf_grow(sb, 1);
+ sb->buf[sb->len++] = ch;
}
- if (ch == EOF && sb->len == 0)
+ if (ch == EOF && sb->len == 0) {
+ strbuf_release(sb);
sb->eof = 1;
- strbuf_end(sb);
+ }
+
+ strbuf_grow(sb, 1);
+ sb->buf[sb->len] = '\0';
}
+
diff --git a/strbuf.h b/strbuf.h
index 74cc012..ec50eeb 100644
--- a/strbuf.h
+++ b/strbuf.h
@@ -1,13 +1,50 @@
#ifndef STRBUF_H
#define STRBUF_H
struct strbuf {
- int alloc;
- int len;
+ size_t alloc;
+ size_t len;
int eof;
char *buf;
};
+#define STRBUF_INIT { 0, 0, 0, NULL }
+
+/* strbuf life cycle */
extern void strbuf_init(struct strbuf *);
+extern void strbuf_release(struct strbuf *);
+extern void strbuf_reset(struct strbuf *);
+extern char *strbuf_detach(struct strbuf *);
+
+
+extern void strbuf_grow(struct strbuf *, size_t);
+extern void strbuf_add(struct strbuf *, const void *, size_t);
+
+static inline void strbuf_addstr(struct strbuf *sb, const char *s) {
+ strbuf_add(sb, s, strlen(s));
+}
+static inline void strbuf_addbuf(struct strbuf *sb, struct strbuf *sb2) {
+ strbuf_add(sb, sb2->buf, sb2->len);
+}
+static inline void strbuf_addch(struct strbuf *sb, size_t c) {
+ strbuf_grow(sb, 1);
+ sb->buf[sb->len++] = c;
+ sb->buf[sb->len] = '\0';
+}
+
+__attribute__((format(printf,2,0)))
+extern void strbuf_addvf(struct strbuf *, const char *, va_list);
+
+static inline __attribute__((format(printf,2,3)))
+void strbuf_addf(struct strbuf *sb, const char *fmt, ...) {
+ va_list ap;
+ va_start(ap, fmt);
+ strbuf_addvf(sb, fmt, ap);
+ va_end(ap);
+}
+
+
+extern size_t strbuf_fread(struct strbuf *, size_t, FILE *);
+
extern void read_line(struct strbuf *, FILE *, int);
#endif /* STRBUF_H */
--
1.5.3
^ permalink raw reply related
* Re: [PATCH] Add a new lstat and fstat implementation based on Win32 API
From: Johannes Sixt @ 2007-09-04 14:07 UTC (permalink / raw)
To: Marius Storm-Olsen; +Cc: Johannes Schindelin, Johannes Sixt, Git Mailing List
In-Reply-To: <46DD63F5.5050002@trolltech.com>
Marius Storm-Olsen schrieb:
> Marius Storm-Olsen said the following on 04.09.2007 13:53:
>> In the meantime, I've pushed out a new patch
>> http://repo.or.cz/w/git/mingw/4msysgit.git?a=commitdiff;h=683775c00d9fb95bcbe4632f95b67a96b902fa59
>>
>>
>> /me starts another test run, to see how our tests are doing now..
>
> Neat, with the custom stat() changes cherry-picked on top of
> 4msysgit.git 'devel' branch, I only have one failing testcase
> t6024-recursive-merge.sh
> when running
> $ NO_SYMLINKS=1 make -k
>
> The rest are passing with flying colors!
And that one will eventually pass if only you try it often enough. See
71ee4210c in mingw.git.
-- Hannes
^ permalink raw reply
* Re: [PATCH] Add a new lstat and fstat implementation based on Win32 API
From: Johannes Schindelin @ 2007-09-04 14:16 UTC (permalink / raw)
To: Marius Storm-Olsen; +Cc: Johannes Sixt, Johannes Sixt, Git Mailing List
In-Reply-To: <46DD63F5.5050002@trolltech.com>
Hi,
On Tue, 4 Sep 2007, Marius Storm-Olsen wrote:
> Marius Storm-Olsen said the following on 04.09.2007 13:53:
> > In the meantime, I've pushed out a new patch
> > http://repo.or.cz/w/git/mingw/4msysgit.git?a=commitdiff;h=683775c00d9fb95bcbe4632f95b67a96b902fa59
> >
> > /me starts another test run, to see how our tests are doing now..
>
> Neat, with the custom stat() changes cherry-picked on top of 4msysgit.git
> 'devel' branch, I only have one failing testcase
> t6024-recursive-merge.sh
> when running
> $ NO_SYMLINKS=1 make -k
>
> The rest are passing with flying colors!
Really? It is failing again? IIRC it was Linus' patch (which I
cherry-picked into 59f8c189a5) that fixed it for me.
Ciao,
Dscho
^ permalink raw reply
* Re: Calculating tree nodes
From: Jon Smirl @ 2007-09-04 14:19 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Andreas Ericsson, David Tweed, Git Mailing List
In-Reply-To: <20070904061611.GY18160@spearce.org>
On 9/4/07, Shawn O. Pearce <spearce@spearce.org> wrote:
> Andreas Ericsson <ae@op5.se> wrote:
> > Jon Smirl wrote:
> > >On 9/4/07, David Tweed <david.tweed@gmail.com> wrote:
> > >>On 9/4/07, Jon Smirl <jonsmirl@gmail.com> wrote:
> > >>>Git has picked up the hierarchical storage scheme since it was built
> > >>>on a hierarchical file system.
> ...
> > >>One of the nice things about tree nodes is that for doing a diff
> > >>between versions you can, to overwhelming probability, decide
> > >>equality/inequality of two arbitrarily deep and complicated subtrees
> > >>by comparing 40 characters, regardless of how remote and convoluted
> > >>their common ancestry. With delta chains don't you end up having to
> > >>trace back to a common "entry" in the history? (Of course, I don't
> > >>know how packs affect this - presumably there's some delta chasing to
> > >>get to the bare objects as well.)
> > >
> > >While it is a 40 character compare, how many disk accesses were needed
> > >to get those two SHAs into memory?
> >
> > One more than there would have been to read only the commit, and one more
> > per level of recursion, assuming you never ever pack your repository.
> >
> > If you *do* pack it, the tree(s) needed to compare are likely already
> > inside the sliding packfile window. In that case, there are no extra
> > disk accesses.
>
> Even better, lets do some back of the napkin math on the Linux
> kernel tree. My local (out of date but close enough) copy has
> 22,730 files in the tip revision. Values shown are uncompressed
> and compressed (gzip -9 | wc -c), but are excluding deltification.
>
> Current Scheme Jon's Flat Scheme
> ----------------- -----------------
> commit raw 932 932 + 22,730*20 = 455,532
> (compressed) 521 456,338
>
> root tree raw 876 0
> (compressed) 805 0
This is not a fair comparison. The current scheme is effectively
diffed against the previous version. You aren't showing an equivalent
diff for the flat scheme. Both schemes are dealing with the same
22,000 SHAs.
The size win is from diffing, not compressing.
> I'm not even bothering with the individual subtrees. The numbers
> will fall off quickly when you start to do subtree elimination and
> only load the levels you need.
>
> You are talking about doing disk IO for less than 4KiB with
> the current scheme, and almost 456 KiB for the flat scheme.
> That's before deltification. So if you also assume deltification
> its going to be higher as you need to read back to a base object
> that is roughly the final size and then unpack the smaller deltas
> to reach the real commit.
>
> Remember, SHA-1s can be stored as 20 bytes of binary data but they
> are also generally uncompressible. That's why the root tree does
> not compress very well, the SHA-1 data inside the tree cannot be
> compressed and only the filenames have any shot at being compressed.
>
> --
> Shawn.
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [PATCH] Functions for updating refs.
From: Johannes Sixt @ 2007-09-04 14:28 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Carlos Rica, git, Junio C Hamano
In-Reply-To: <Pine.LNX.4.64.0709041444070.28586@racer.site>
Johannes Schindelin schrieb:
> On Tue, 4 Sep 2007, Carlos Rica wrote:
>> +int update_ref_or_die(const char *action, const char *refname,
>> + const unsigned char *sha1,
>> + const unsigned char *oldval, int flags)
>
> Should this not be "void"? And should it not use update_ref_or_error()?
It should not use *_error() directly because then it would print two error
messages in a row.
-- Hannes
^ permalink raw reply
* Re: [PATCH] Add a new lstat and fstat implementation based on Win32 API
From: Johannes Schindelin @ 2007-09-04 14:30 UTC (permalink / raw)
To: Marius Storm-Olsen; +Cc: Johannes Sixt, Johannes Sixt, Git Mailing List
In-Reply-To: <46DD63F5.5050002@trolltech.com>
Hi,
On Tue, 4 Sep 2007, Marius Storm-Olsen wrote:
> Marius Storm-Olsen said the following on 04.09.2007 13:53:
> > In the meantime, I've pushed out a new patch
> > http://repo.or.cz/w/git/mingw/4msysgit.git?a=commitdiff;h=683775c00d9fb95bcbe4632f95b67a96b902fa59
> >
> > /me starts another test run, to see how our tests are doing now..
>
> Neat, with the custom stat() changes cherry-picked on top of 4msysgit.git
> 'devel' branch, I only have one failing testcase
> t6024-recursive-merge.sh
> when running
> $ NO_SYMLINKS=1 make -k
>
> The rest are passing with flying colors!
Bad news. I do not know if it was the newest version I tried, but I could
no longer fetch... said something about some bad file.
Ciao,
Dscho
^ permalink raw reply
* Re: Calculating tree nodes
From: Jon Smirl @ 2007-09-04 14:31 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Martin Langhoff, Shawn O. Pearce, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0709041131030.28586@racer.site>
On 9/4/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Tue, 4 Sep 2007, Jon Smirl wrote:
>
> > In my scheme the path info is moved into the file object nodes and the
> > SHA list is in the commit node.
>
> And how should this "SHA list" be any different from a single tree object,
> except that you now merge it with the commit object?
>
> Really, go back to the mail Martin mentioned. Having all objects in one
> list kills performance.
You are ignoring the fact the in this scheme temp indexes can be
created as needed. These temp indexes could look just like tree nodes.
I'm saying that it may be a mistake to be recording the indexes (aka
file names) as part of the commit when they really aren't. The
essential part of the commit is the SHA1 list. The path names belong
to the file objects and should be stored there.
>
> > Diffing two trees in the scheme is quite fast. Just get their commit
> > objects into RAM and compare the lists of SHAs.
>
> No, it is not fast. Just loading the complete list into RAM is likely
> much, much slower than a simple diff _right_ _now_.
>
> Hth,
> Dscho
>
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [PATCH] Add a new lstat and fstat implementation based on Win32 API
From: Johannes Schindelin @ 2007-09-04 14:32 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Marius Storm-Olsen, Johannes Sixt, Git Mailing List
In-Reply-To: <46DD6694.6030701@eudaptics.com>
Hi,
On Tue, 4 Sep 2007, Johannes Sixt wrote:
> Marius Storm-Olsen schrieb:
> > Marius Storm-Olsen said the following on 04.09.2007 13:53:
> > > In the meantime, I've pushed out a new patch
> > > http://repo.or.cz/w/git/mingw/4msysgit.git?a=commitdiff;h=683775c00d9fb95bcbe4632f95b67a96b902fa59
> > >
> > > /me starts another test run, to see how our tests are doing now..
> >
> > Neat, with the custom stat() changes cherry-picked on top of 4msysgit.git
> > 'devel' branch, I only have one failing testcase
> > t6024-recursive-merge.sh
> > when running
> > $ NO_SYMLINKS=1 make -k
> >
> > The rest are passing with flying colors!
>
> And that one will eventually pass if only you try it often enough. See
> 71ee4210c in mingw.git.
Do you have Linus' patch applied? The one where the config is read at the
start of write-tree?
The problem only occurred since we have core.crlf = input unilaterally
now.
Ciao,
Dscho
^ permalink raw reply
* Re: Calculating tree nodes
From: Andreas Ericsson @ 2007-09-04 14:41 UTC (permalink / raw)
To: Jon Smirl; +Cc: Shawn O. Pearce, David Tweed, Git Mailing List
In-Reply-To: <9e4733910709040719n135a1c2dw3a2d5c470b74791a@mail.gmail.com>
Jon Smirl wrote:
> On 9/4/07, Shawn O. Pearce <spearce@spearce.org> wrote:
>> Andreas Ericsson <ae@op5.se> wrote:
>>> Jon Smirl wrote:
>>>> On 9/4/07, David Tweed <david.tweed@gmail.com> wrote:
>>>>> On 9/4/07, Jon Smirl <jonsmirl@gmail.com> wrote:
>>>>>> Git has picked up the hierarchical storage scheme since it was built
>>>>>> on a hierarchical file system.
>> ...
>>>>> One of the nice things about tree nodes is that for doing a diff
>>>>> between versions you can, to overwhelming probability, decide
>>>>> equality/inequality of two arbitrarily deep and complicated subtrees
>>>>> by comparing 40 characters, regardless of how remote and convoluted
>>>>> their common ancestry. With delta chains don't you end up having to
>>>>> trace back to a common "entry" in the history? (Of course, I don't
>>>>> know how packs affect this - presumably there's some delta chasing to
>>>>> get to the bare objects as well.)
>>>> While it is a 40 character compare, how many disk accesses were needed
>>>> to get those two SHAs into memory?
>>> One more than there would have been to read only the commit, and one more
>>> per level of recursion, assuming you never ever pack your repository.
>>>
>>> If you *do* pack it, the tree(s) needed to compare are likely already
>>> inside the sliding packfile window. In that case, there are no extra
>>> disk accesses.
>> Even better, lets do some back of the napkin math on the Linux
>> kernel tree. My local (out of date but close enough) copy has
>> 22,730 files in the tip revision. Values shown are uncompressed
>> and compressed (gzip -9 | wc -c), but are excluding deltification.
>>
>> Current Scheme Jon's Flat Scheme
>> ----------------- -----------------
>> commit raw 932 932 + 22,730*20 = 455,532
>> (compressed) 521 456,338
>>
>> root tree raw 876 0
>> (compressed) 805 0
>
> This is not a fair comparison. The current scheme is effectively
> diffed against the previous version. You aren't showing an equivalent
> diff for the flat scheme. Both schemes are dealing with the same
> 22,000 SHAs.
>
How, with your scheme, would you solve
git diff -M master pu
in the git repo?
You'd have to build both trees completely, utilizing the last known
complete tree-listing (the root commit, since you propose to do away
with trees altogether) and then applying diffs on top of that to
finally generate an in-memory tree-structure in which you will have
to compare every single file against every single other file to find
out which code has been moved/copied/renamed/whatever.
That's (n*(n+1))/2 operations for file-level diffs alone. For the
kernels 22730 files, you're looking at 258337815 file comparisons
without the tree objects.
Sure, you can probably shave away quite a few of those comparisons
at the expense of computing the tree-hashes on the fly, but in that
case, why get rid of them in the first place?
> The size win is from diffing, not compressing.
>
It was declared in May 2006 by someone insightful that diskspace
and bandwidth are cheap, while human time is priceless.
IOW, size wins had better be proportionally huge to justify slowing
git down and thereby taking more than necessary of the users' time.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* git-svn and a nested branches folder
From: Russ Brown @ 2007-09-04 14:42 UTC (permalink / raw)
To: git
Hi,
I'm having some trouble with using git-svn to fetch a repository, and I
think it's because the repository doesn't store branches as a flat list
directly under the 'branches' directory.
Basically, we have a structure like this:
|
+-trunk
+-tags
+-branches
+ category-a
+ branch-a
+ branch-b
+ category-b
+ branch-c
+ branch-d
etc. category-a and category-b are simple directories created using svn
mkdir. The branches are created using svn cp.
It helps us to organise the branches better, but the rationale is
besides the point. The problem is that git-svn seems to want to treat
category-a and category-b as branches, which isn't right at all. As a
result, git-svn seems to skip most (if not all) revisions that occur in
these directories and creates a lot of entries in unhandled.log.
I've also encountered an index corruption in one of the
.git/svn/<branch>/index files which I think it probably related.
I've had a quick look at the source myself, but perl isn't my strong
point. What I think it should do is something like recurse down the tree
from the directory given looking for folders that copy from trunk (or
some other branch that already exists). That would work perfectly well
for the default flat branch storage method as well as the one we use.
The only other problem is in branch naming, which could clash if you
only use the outer-most directory name, so I'd suggest something that
involves concatenating the folders in the path relative to 'branches' to
keep them unique (if git can handle slashes in branch names then all the
better).
Thanks for reading.
--
Russ
^ permalink raw reply
* Re: [PATCH] Add a new lstat and fstat implementation based on Win32 API
From: Marius Storm-Olsen @ 2007-09-04 14:43 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Johannes Sixt, Johannes Sixt, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0709041529191.28586@racer.site>
[-- Attachment #1: Type: text/plain, Size: 906 bytes --]
Johannes Schindelin wrote:
> On Tue, 4 Sep 2007, Marius Storm-Olsen wrote:
>> Neat, with the custom stat() changes cherry-picked on top of
>> 4msysgit.git 'devel' branch, I only have one failing testcase
>> t6024-recursive-merge.sh when running $ NO_SYMLINKS=1 make -k
>>
>> The rest are passing with flying colors!
>
> Bad news. I do not know if it was the newest version I tried, but I
> could no longer fetch... said something about some bad file.
Then you're missing this patch:
http://repo.or.cz/w/git/mingw/4msysgit.git?a=commitdiff;h=f15974add93bdfa92775c77c00e7c65aefd42127
I guess the quickest way is to manually apply this patch and recompile.
(or add the '#undef fstat', and have git_fstat just 'return fstat(fd, buf)')
The problem is that without this patch fstat(0, buf) would fail with bad
filedescriptor instead of returning the st_mode = S_IFIFO.
--
.marius
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 187 bytes --]
^ permalink raw reply
* Re: git-svn and a nested branches folder
From: David Kastrup @ 2007-09-04 14:46 UTC (permalink / raw)
To: git
In-Reply-To: <46DD6EEA.9010304@gmail.com>
Russ Brown <pickscrape@gmail.com> writes:
> I'm having some trouble with using git-svn to fetch a repository, and I
> think it's because the repository doesn't store branches as a flat list
> directly under the 'branches' directory.
>
> Basically, we have a structure like this:
>
> |
> +-trunk
> +-tags
> +-branches
> + category-a
> + branch-a
> + branch-b
> + category-b
> + branch-c
> + branch-d
>
> etc. category-a and category-b are simple directories created using svn
> mkdir. The branches are created using svn cp.
>
> It helps us to organise the branches better, but the rationale is
> besides the point. The problem is that git-svn seems to want to
> treat category-a and category-b as branches, which isn't right at
> all. As a result, git-svn seems to skip most (if not all) revisions
> that occur in these directories and creates a lot of entries in
> unhandled.log.
So what did you specify in your .git/config file regarding the svn
structure?
--
David Kastrup
^ permalink raw reply
* Re: [PATCH] Add a new lstat and fstat implementation based on Win32 API
From: Johannes Schindelin @ 2007-09-04 14:48 UTC (permalink / raw)
To: Marius Storm-Olsen; +Cc: Johannes Sixt, Johannes Sixt, Git Mailing List
In-Reply-To: <46DD6F2B.3060001@trolltech.com>
Hi,
On Tue, 4 Sep 2007, Marius Storm-Olsen wrote:
> Johannes Schindelin wrote:
> > On Tue, 4 Sep 2007, Marius Storm-Olsen wrote:
> >> Neat, with the custom stat() changes cherry-picked on top of
> >> 4msysgit.git 'devel' branch, I only have one failing testcase
> >> t6024-recursive-merge.sh when running $ NO_SYMLINKS=1 make -k
> >>
> >> The rest are passing with flying colors!
> >
> > Bad news. I do not know if it was the newest version I tried, but I
> > could no longer fetch... said something about some bad file.
>
> Then you're missing this patch:
> http://repo.or.cz/w/git/mingw/4msysgit.git?a=commitdiff;h=f15974add93bdfa92775c77c00e7c65aefd42127
>
> I guess the quickest way is to manually apply this patch and recompile.
> (or add the '#undef fstat', and have git_fstat just 'return fstat(fd, buf)')
>
> The problem is that without this patch fstat(0, buf) would fail with bad
> filedescriptor instead of returning the st_mode = S_IFIFO.
I guessed as much, but could not fetch the patch, since fetch was broken
;-)
For some utterly strange reason, "git fetch" accessed "git-fetch" in the
cwd, not in /bin/... Funny.
Ciao,
Dscho
^ permalink raw reply
* git pull fails with http urls?
From: Richard Purdie @ 2007-09-04 14:10 UTC (permalink / raw)
To: Git Mailing List
I've noticed a problem with pulling http urls. I can clone them fine:
git clone http://www.gnome.org/~alexl/git/gio.git/
and I can pull with:
git pull
which works as expected however if I try:
git pull http://www.gnome.org/~alexl/git/gio.git/
it fails with:
error: pick-rref: HEAD not found
No such ref HEAD at http://www.gnome.org/~alexl/git/gio.git/
The HEAD file is there at http://www.gnome.org/~alexl/git/gio.git/HEAD
and:
git pull http://www.gnome.org/~alexl/git/gio.git/ master
works. It seems git just doesn't want to see/understand the HEAD file?
Is the above supposed to work or is something wrong with the above
commands? I see this with git 1.5.2.3 and 1.5.3, google suggests this
might have worked with 1.4.x and broke in 1.5...
Regards,
Richard
^ permalink raw reply
* git-commit: if run with <file> arguments, include files removed through git rm
From: Gerrit Pape @ 2007-09-04 14:43 UTC (permalink / raw)
To: git
If git-commit is given a directory as argument to be included in the
commit, it uses git ls-files to find out which files to include; this
misses files previously removed from the working tree and the index
through git rm:
% git init-db
Initialized empty Git repository in .git/
% mkdir bar baz
% touch bar/file1 baz/file1 baz/file2
% git add . && git commit -mcommit1
Created initial commit 1d7dee4: commit1
0 files changed, 0 insertions(+), 0 deletions(-)
create mode 100644 bar/file1
create mode 100644 baz/file1
create mode 100644 baz/file2
% git rm baz/file1
rm 'baz/file1'
% git commit -- baz/
# On branch master
# Changed but not updated:
# (use "git add/rm <file>..." to update what will be committed)
#
# deleted: baz/file1
#
no changes added to commit (use "git add" and/or "git commit -a")
This patch lets it additionally use git ls-tree to look for the files in
the HEAD tree, but I guess there's a smarter way to fix this.
---
git-commit.sh | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/git-commit.sh b/git-commit.sh
index 1d04f1f..3ac7c4f 100755
--- a/git-commit.sh
+++ b/git-commit.sh
@@ -381,6 +381,7 @@ t,)
fi
TMP_INDEX="$GIT_DIR/tmp-index$$"
commit_only=`git ls-files --error-unmatch -- "$@"` || exit
+ commit_only="$commit_only "`git ls-tree -r --name-only HEAD -- "$@"` || exit
# Build a temporary index and update the real index
# the same way.
--
1.5.3
^ permalink raw reply related
* Re: [PATCH] Add a new lstat and fstat implementation based on Win32 API
From: Johannes Sixt @ 2007-09-04 14:52 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Marius Storm-Olsen, Johannes Sixt, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0709041530560.28586@racer.site>
Johannes Schindelin schrieb:
> Hi,
>
> On Tue, 4 Sep 2007, Johannes Sixt wrote:
>
>> Marius Storm-Olsen schrieb:
>>> Marius Storm-Olsen said the following on 04.09.2007 13:53:
>>>> In the meantime, I've pushed out a new patch
>>>> http://repo.or.cz/w/git/mingw/4msysgit.git?a=commitdiff;h=683775c00d9fb95bcbe4632f95b67a96b902fa59
>>>>
>>>> /me starts another test run, to see how our tests are doing now..
>>> Neat, with the custom stat() changes cherry-picked on top of 4msysgit.git
>>> 'devel' branch, I only have one failing testcase
>>> t6024-recursive-merge.sh
>>> when running
>>> $ NO_SYMLINKS=1 make -k
>>>
>>> The rest are passing with flying colors!
>> And that one will eventually pass if only you try it often enough. See
>> 71ee4210c in mingw.git.
>
> Do you have Linus' patch applied? The one where the config is read at the
> start of write-tree?
>
> The problem only occurred since we have core.crlf = input unilaterally
> now.
Yes, I have that patch, but I don't have core.crlf set.
There are a lot of tests that do a series of commits in a row, with file
changes such that the file size does _not_ change, aka "racy git" problem.
This problem is obviously not 100% fixed on MSys: We do not correctly detect
that there are files that might be modified ("racily clean" files). Some
tests are prone to trigger the bug, others not.
-- Hannes
^ permalink raw reply
* Re: git-svn and a nested branches folder
From: Russ Brown @ 2007-09-04 14:54 UTC (permalink / raw)
To: git
In-Reply-To: <86veaqebf1.fsf@lola.quinscape.zz>
David Kastrup wrote:
> Russ Brown <pickscrape@gmail.com> writes:
>
>> I'm having some trouble with using git-svn to fetch a repository, and I
>> think it's because the repository doesn't store branches as a flat list
>> directly under the 'branches' directory.
>>
>> Basically, we have a structure like this:
>>
>> |
>> +-trunk
>> +-tags
>> +-branches
>> + category-a
>> + branch-a
>> + branch-b
>> + category-b
>> + branch-c
>> + branch-d
>>
>> etc. category-a and category-b are simple directories created using svn
>> mkdir. The branches are created using svn cp.
>>
>> It helps us to organise the branches better, but the rationale is
>> besides the point. The problem is that git-svn seems to want to
>> treat category-a and category-b as branches, which isn't right at
>> all. As a result, git-svn seems to skip most (if not all) revisions
>> that occur in these directories and creates a lot of entries in
>> unhandled.log.
>
> So what did you specify in your .git/config file regarding the svn
> structure?
>
I specified the 'branches' directory, but that's because earlier in the
life of the repo we did just do the flat branch layout, but decided to
make it more structured once that got unwieldy.
Is it possible to specify more than one folder for the branches option?
--
Russ
^ permalink raw reply
* Re: [PATCH] Functions for updating refs.
From: Johannes Schindelin @ 2007-09-04 14:58 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Carlos Rica, git, Junio C Hamano
In-Reply-To: <46DD6B93.10005@eudaptics.com>
Hi,
On Tue, 4 Sep 2007, Johannes Sixt wrote:
> Johannes Schindelin schrieb:
> > On Tue, 4 Sep 2007, Carlos Rica wrote:
> > > +int update_ref_or_die(const char *action, const char *refname,
> > > + const unsigned char *sha1,
> > > + const unsigned char *oldval, int flags)
> >
> > Should this not be "void"? And should it not use update_ref_or_error()?
>
> It should not use *_error() directly because then it would print two error
> messages in a row.
Well, my idea was to let _error() print the message, and just die().
Ciao,
Dscho
^ permalink raw reply
* Re: git-svn and a nested branches folder
From: David Kastrup @ 2007-09-04 15:01 UTC (permalink / raw)
To: git
In-Reply-To: <46DD718C.7060908@gmail.com>
Russ Brown <pickscrape@gmail.com> writes:
> David Kastrup wrote:
>> Russ Brown <pickscrape@gmail.com> writes:
>>
>>> I'm having some trouble with using git-svn to fetch a repository, and I
>>> think it's because the repository doesn't store branches as a flat list
>>> directly under the 'branches' directory.
>>>
>>> Basically, we have a structure like this:
>>>
>>> |
>>> +-trunk
>>> +-tags
>>> +-branches
>>> + category-a
>>> + branch-a
>>> + branch-b
>>> + category-b
>>> + branch-c
>>> + branch-d
>>>
>>> etc. category-a and category-b are simple directories created using svn
>>> mkdir. The branches are created using svn cp.
>>>
>>> It helps us to organise the branches better, but the rationale is
>>> besides the point. The problem is that git-svn seems to want to
>>> treat category-a and category-b as branches, which isn't right at
>>> all. As a result, git-svn seems to skip most (if not all) revisions
>>> that occur in these directories and creates a lot of entries in
>>> unhandled.log.
>>
>> So what did you specify in your .git/config file regarding the svn
>> structure?
>
> I specified the 'branches' directory, but that's because earlier in
> the life of the repo we did just do the flat branch layout, but
> decided to make it more structured once that got unwieldy.
Cough, cough. _What_ did you specify in your .git/config file
regarding the svn structure? Please quote the section.
> Is it possible to specify more than one folder for the branches
> option?
It is possible to adapt the config section to the actual layout. If
not otherwise, by starting with
git svn init
with a clean slate, editing the config file, and only then actually
fetching stuff.
However, git-svn will not magically start guessing that you changed
your structure around. You have to edit the configuration
appropriately.
--
David Kastrup
^ permalink raw reply
* Re: Calculating tree nodes
From: Johannes Schindelin @ 2007-09-04 15:05 UTC (permalink / raw)
To: Jon Smirl; +Cc: Martin Langhoff, Shawn O. Pearce, Git Mailing List
In-Reply-To: <9e4733910709040731s2695ab14kb9750923fcac007@mail.gmail.com>
Hi,
On Tue, 4 Sep 2007, Jon Smirl wrote:
> On 9/4/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
> > On Tue, 4 Sep 2007, Jon Smirl wrote:
> >
> > > In my scheme the path info is moved into the file object nodes and
> > > the SHA list is in the commit node.
> >
> > And how should this "SHA list" be any different from a single tree
> > object, except that you now merge it with the commit object?
> >
> > Really, go back to the mail Martin mentioned. Having all objects in
> > one list kills performance.
>
> You are ignoring the fact the in this scheme temp indexes can be
> created as needed. These temp indexes could look just like tree nodes.
>
> I'm saying that it may be a mistake to be recording the indexes (aka
> file names) as part of the commit when they really aren't.
You still have not acknowledged that you want to do (in essence) _exactly_
the same. Your "temp indexes" awfully remind me of tree objects.
And that is no wonder, since you _need_ something like that, however you
want to avoid it. Just admit it that you found -- again -- that flat
directory structure does not work, and you therefore need some smaller
structures. We just happen to call them "tree objects", and for ease of
concept we wrap directories in them.
Hth,
Dscho
^ 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