[PATCH 19/21] index-pack, pack-objects: allow creating .idx v2 with .pack v4
While .idx v3 is recommended because it's smaller, there is no reason
why .idx v2 can't use with .pack v4. Enable it, at least for the test
suite as some tests need to this kind of information from show-index
and show-index does not support .idx v3.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/index-pack.c | 14 ++
builtin/pack-objects.c | 14 ++
2 files changed, 20 insertions(+), 8 deletions(-)
diff --git a/builtin/index-pack.c b/builtin/index-pack.c
index 1895adf..4607dc6 100644
--- a/builtin/index-pack.c
+++ b/builtin/index-pack.c
@@ -89,7 +89,7 @@ static int verbose;
static int show_stat;
static int check_self_contained_and_connected;
static int packv4;
-
+static int idx_version_set;
static struct progress *progress;
/* We always read in 4kB chunks. */
@@ -1892,8 +1892,9 @@ static int git_index_pack_config(const char *k, const
char *v, void *cb)
if (!strcmp(k, "pack.indexversion")) {
opts->version = git_config_int(k, v);
- if (opts->version > 2)
+ if (opts->version > 3)
die(_("bad pack.indexversion=%"PRIu32), opts->version);
+ idx_version_set = 1;
return 0;
}
if (!strcmp(k, "pack.threads")) {
@@ -2107,12 +2108,13 @@ int cmd_index_pack(int argc, const char **argv, const
char *prefix)
} else if (!prefixcmp(arg, "--index-version=")) {
char *c;
opts.version = strtoul(arg + 16, &c, 10);
- if (opts.version > 2)
+ if (opts.version > 3)
die(_("bad %s"), arg);
if (*c == ',')
opts.off32_limit = strtoul(c+1, &c, 0);
if (*c || opts.off32_limit & 0x8000)
die(_("bad %s"), arg);
+ idx_version_set = 1;
} else
usage(index_pack_usage);
continue;
@@ -2151,6 +2153,7 @@ int cmd_index_pack(int argc, const char **argv, const
char *prefix)
if (!index_name)
die(_("--verify with no packfile name given"));
read_idx_option(&opts, index_name);
+ idx_version_set = 1;
opts.flags |= WRITE_IDX_VERIFY | WRITE_IDX_STRICT;
}
if (strict)
@@ -2167,6 +2170,9 @@ int cmd_index_pack(int argc, const char **argv, const
char *prefix)
curr_pack = open_pack_file(pack_name);
parse_pack_header();
+ if (!packv4 && opts.version >= 3)
+ die(_("pack idx version %d does not work with pack version %d"),
+ opts.version, 4);
objects = xcalloc(nr_objects + 1, sizeof(struct object_entry));
deltas = xcalloc(nr_objects, sizeof(struct delta_entry));
parse_dictionaries();
@@ -2180,7 +2186,7 @@ int cmd_index_pack(int argc, const char **argv, const
char *prefix)
if (show_stat)
show_pack_info(stat_only);
- if (packv4)
+ if (packv4 && !idx_version_set)
opts.version = 3;
idx_objects = xmalloc((nr_objects) * sizeof(struct pack_idx_entry *));
diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c
index ac25973..f604fa5 100644
--- a/builtin/pack-objects.c
+++ b/builtin/pack-objects.c
@@ -66,7 +66,7 @@ static uint32_t nr_objects, nr_alloc, nr_result, nr_written;
static struct packv4_tables v4;
-static int non_empty;
+static int non_empty, idx_version_set;
static int reuse_delta = 1, reuse_object = 1;
static int keep_unreachable, unpack_unreachable, include_tag;
static unsigned long unpack_unreachable_expiration;
@@ -2205,7 +2205,8 @@ static void prepare_pack(int window, int depth)
sort_dict_entries_by_hits(v4.commit_ident_table);
sort_dict_entries_by_hits(v4.tree_path_table);
v4.all_objs = xmalloc(nr_objects * sizeof(*v4.all_objs));
- pack_idx_opts.version = 3;
+ if (!idx_version_set)
+ pack_idx_opts.version = 3;
allow_ofs_delta = 0;
}
@@ -2319,9 +2320,10 @@ static int git_pack_config(const char *k, const char *v,
void *cb)
}
if (!strcmp(k, "pack.indexversion")) {
pack_idx_opts.version = git_config_int(k, v);
- if (pack_idx_opts.version > 2)
+ if (pack_idx_opts.version > 3)
die("bad pack.indexversion=%"PRIu32,
pack_idx_opts.version);
+ idx_version_set = 1;
return 0;
}
return git_default_config(k, v, cb);
@@ -2604,12 +2606,13 @@ static int option_parse_index_version(const struct
option *opt,
char *c;
const char *val = arg
[PATCH 21/21] t1050, t5500: replace the use of "show-index|wc -l" with verify-pack
Signed-off-by: Nguyễn Thái Ngọc Duy
---
t/t1050-large.sh | 9 +
t/t5500-fetch-pack.sh | 4 ++--
2 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/t/t1050-large.sh b/t/t1050-large.sh
index fd10528..829030b 100755
--- a/t/t1050-large.sh
+++ b/t/t1050-large.sh
@@ -32,7 +32,7 @@ test_expect_success 'add a large file or two' '
done &&
test -z "$bad" &&
test $count = 1 &&
- cnt=$(git show-index <"$idx" | wc -l) &&
+ cnt=$(git verify-pack -v "${idx/idx/pack}" | grep "^[0-9a-f]\{40\}" |
wc -l) &&
test $cnt = 2 &&
for l in .git/objects/??/??
do
@@ -93,11 +93,12 @@ test_expect_success 'packsize limit' '
) |
sort >expect &&
- for pi in .git/objects/pack/pack-*.idx
+ for pi in .git/objects/pack/pack-*.pack
do
- git show-index <"$pi"
+ git verify-pack -v "$pi"
done |
- sed -e "s/^[0-9]* \([0-9a-f]*\) .*/\1/" |
+ grep "^[0-9a-f]\{40\}" |
+ sed -e "s/^\([0-9a-f]\{40\}\) .*/\1/" |
sort >actual &&
test_cmp expect actual
diff --git a/t/t5500-fetch-pack.sh b/t/t5500-fetch-pack.sh
index fd2598e..f99cd14 100755
--- a/t/t5500-fetch-pack.sh
+++ b/t/t5500-fetch-pack.sh
@@ -60,8 +60,8 @@ pull_to_client () {
git unpack-objects <$p &&
git fsck --full &&
- idx=`echo pack-*.idx` &&
- pack_count=`git show-index <$idx | wc -l` &&
+ pack=`echo pack-*.pack` &&
+ pack_count=`git verify-pack -v $pack | grep
"^[0-9a-f]\{40\}" | wc -l` &&
test $pack_count = $count &&
rm -f pack-*
)
--
1.8.2.82.gc24b958
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 20/21] show-index: acknowledge that it does not read .idx v3
show-index takes .idx from stdin while v3 requires the .pack. It's
used for testing purposes only. Let those test scripts force .idx v2
with index-pack.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
show-index.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/show-index.c b/show-index.c
index 5a9eed7..2028e02 100644
--- a/show-index.c
+++ b/show-index.c
@@ -19,8 +19,10 @@ int main(int argc, char **argv)
die("unable to read header");
if (top_index[0] == htonl(PACK_IDX_SIGNATURE)) {
version = ntohl(top_index[1]);
- if (version < 2 || version > 2)
+ if (version < 2 || version > 3)
die("unknown index version");
+ if (version == 3)
+ die("show-index does not support .idx v3, convert to v2
instead");
if (fread(top_index, 256 * 4, 1, stdin) != 1)
die("unable to read index");
} else {
--
1.8.2.82.gc24b958
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 16/21] unpack-objects: decode v4 commits
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/unpack-objects.c | 60
1 file changed, 60 insertions(+)
diff --git a/builtin/unpack-objects.c b/builtin/unpack-objects.c
index f8442f4..6fc72c1 100644
--- a/builtin/unpack-objects.c
+++ b/builtin/unpack-objects.c
@@ -131,6 +131,15 @@ static const unsigned char *read_sha1ref(void)
return sha1_table + index * 20;
}
+static const unsigned char *read_dictref(struct packv4_dict *dict)
+{
+ unsigned int index = read_varint();
+ if (index >= dict->nb_entries)
+ die("bad index in read_dictref at %lu",
+ (unsigned long)consumed_bytes);
+ return dict->data + dict->offsets[index];
+}
+
static void *get_data(unsigned long size)
{
git_zstream stream;
@@ -467,6 +476,54 @@ static void unpack_delta_entry(enum object_type type,
unsigned long delta_size,
free(base);
}
+static void unpack_commit_v4(unsigned long size, unsigned long nr)
+{
+ unsigned int nb_parents;
+ const unsigned char *committer, *author, *ident;
+ unsigned long author_time, committer_time;
+ int16_t committer_tz, author_tz;
+ struct strbuf dst;
+ char *remaining;
+
+ strbuf_init(&dst, size);
+
+ strbuf_addf(&dst, "tree %s\n", sha1_to_hex(read_sha1ref()));
+ nb_parents = read_varint();
+ while (nb_parents--)
+ strbuf_addf(&dst, "parent %s\n", sha1_to_hex(read_sha1ref()));
+
+ committer_time = read_varint();
+ ident = read_dictref(name_dict);
+ committer_tz = (ident[0] << 8) | ident[1];
+ committer = ident + 2;
+
+ author_time = read_varint();
+ ident = read_dictref(name_dict);
+ author_tz = (ident[0] << 8) | ident[1];
+ author = ident + 2;
+
+ if (author_time & 1)
+ author_time = committer_time + (author_time >> 1);
+ else
+ author_time = committer_time - (author_time >> 1);
+
+ strbuf_addf(&dst,
+ "author %s %lu %+05d\n"
+ "committer %s %lu %+05d\n",
+ author, author_time, author_tz,
+ committer, committer_time, committer_tz);
+
+ if (dst.len > size)
+ die("bad commit");
+
+ remaining = get_data(size - dst.len);
+ strbuf_add(&dst, remaining, size - dst.len);
+ if (!dry_run)
+ write_object(nr, OBJ_COMMIT, dst.buf, dst.len);
+ else
+ strbuf_release(&dst);
+}
+
static void read_typesize_v2(enum object_type *type, unsigned long *size)
{
unsigned char c = *(char*)fill_and_use(1);
@@ -511,6 +568,9 @@ static int unpack_one(unsigned nr)
case OBJ_OFS_DELTA:
unpack_delta_entry(type, size, nr);
break;
+ case OBJ_PV4_COMMIT:
+ unpack_commit_v4(size, nr);
+ break;
default:
error("bad object type %d", type);
has_errors = 1;
--
1.8.2.82.gc24b958
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 18/21] unpack-objects: decode v4 trees
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/unpack-objects.c | 191 ++-
1 file changed, 189 insertions(+), 2 deletions(-)
diff --git a/builtin/unpack-objects.c b/builtin/unpack-objects.c
index 044a087..9fd5640 100644
--- a/builtin/unpack-objects.c
+++ b/builtin/unpack-objects.c
@@ -12,6 +12,7 @@
#include "decorate.h"
#include "packv4-parse.h"
#include "fsck.h"
+#include "varint.h"
static int dry_run, quiet, recover, has_errors, strict;
static const char unpack_usage[] = "git unpack-objects [-n] [-q] [-r]
[--strict] < pack-file";
@@ -148,6 +149,27 @@ static const unsigned char *read_sha1ref(void)
return sha1_table + index * 20;
}
+static void check_against_sha1table(const unsigned char *sha1)
+{
+ const unsigned char *found;
+ if (!packv4)
+ return;
+
+ found = bsearch(sha1, sha1_table, nr_objects, 20,
+ (int (*)(const void *, const void *))hashcmp);
+ if (!found)
+ die(_("object %s not found in SHA-1 table"),
+ sha1_to_hex(sha1));
+}
+
+static const unsigned char *read_sha1table_ref(void)
+{
+ const unsigned char *sha1 = read_sha1ref();
+ if (sha1 < sha1_table || sha1 >= sha1_table + nr_objects * 20)
+ check_against_sha1table(sha1);
+ return sha1;
+}
+
static const unsigned char *read_dictref(struct packv4_dict *dict)
{
unsigned int index = read_varint();
@@ -327,6 +349,84 @@ static void write_object(unsigned nr, enum object_type
type,
}
}
+static void resolve_tree_v4(unsigned long nr_obj,
+ const void *tree,
+ unsigned long tree_len,
+ const unsigned char *base_sha1,
+ const void *base,
+ unsigned long base_size)
+{
+ int nr;
+ struct strbuf sb = STRBUF_INIT;
+ const unsigned char *p = tree;
+ const unsigned char *end = p + tree_len;
+
+ nr = decode_varint(&p);
+ while (nr > 0 && p < end) {
+ unsigned int copy_start_or_path = decode_varint(&p);
+ if (copy_start_or_path & 1) { /* copy_start */
+ struct tree_desc desc;
+ struct name_entry entry;
+ unsigned int copy_count = decode_varint(&p);
+ unsigned int copy_start = copy_start_or_path >> 1;
+ if (!base_sha1)
+ die("we are not supposed to copy from another
tree!");
+ if (copy_count & 1) { /* first delta */
+ unsigned int id = decode_varint(&p);
+ const unsigned char *last_base;
+ if (!id) {
+ last_base = p;
+ p += 20;
+ } else
+ last_base = sha1_table + (id - 1) * 20;
+ if (hashcmp(last_base, base_sha1))
+ die("bad base tree in resolve_tree_v4");
+ }
+
+ copy_count >>= 1;
+ nr -= copy_count;
+
+ init_tree_desc(&desc, base, base_size);
+ while (tree_entry(&desc, &entry)) {
+ if (copy_start)
+ copy_start--;
+ else if (copy_count) {
+ strbuf_addf(&sb, "%o %s%c",
+ entry.mode, entry.path,
'\0');
+ strbuf_add(&sb, entry.sha1, 20);
+ copy_count--;
+ } else
+ break;
+ }
+ } else {/* path */
+ unsigned int path_idx = copy_start_or_path >> 1;
+ const unsigned char *path;
+ unsigned mode;
+ unsigned int id;
+ const unsigned char *entry_sha1;
+
+ id = decode_varint(&p);
+ if (!id) {
+ entry_sha1 = p;
+ p += 20;
+ } else
+ entry_sha1 = sha1_table + (id - 1) * 20;
+ nr--;
+
+ path = path_dict->data + path_dict->offsets[path_idx];
+ mode = (path[0] << 8) | path[1];
+ strbuf_addf(&sb, "%o %s%c", mode, path+2, '\0');
+ strbuf_add(&sb, entry_sha1, 20);
+ }
+ }
+ if (nr != 0 || p != end)
+ die(_("bad delta tree"));
+ if (!dr
[PATCH 17/21] unpack-objects: allow to save processed bytes to a buffer
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/unpack-objects.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/builtin/unpack-objects.c b/builtin/unpack-objects.c
index 6fc72c1..044a087 100644
--- a/builtin/unpack-objects.c
+++ b/builtin/unpack-objects.c
@@ -54,6 +54,9 @@ static void add_object_buffer(struct object *object, char
*buffer, unsigned long
die("object %s tried to add buffer twice!",
sha1_to_hex(object->sha1));
}
+static struct strbuf back_buffer = STRBUF_INIT;
+static int save_to_back_buffer;
+
/*
* Make sure at least "min" bytes are available in the buffer, and
* return the pointer to the buffer.
@@ -66,6 +69,8 @@ static void *fill(int min)
die("cannot fill %d bytes", min);
if (offset) {
git_SHA1_Update(&ctx, buffer, offset);
+ if (save_to_back_buffer)
+ strbuf_add(&back_buffer, buffer, offset);
memmove(buffer, buffer + offset, len);
offset = 0;
}
@@ -81,6 +86,18 @@ static void *fill(int min)
return buffer;
}
+static void copy_back_buffer(int set)
+{
+ if (offset) {
+ git_SHA1_Update(&ctx, buffer, offset);
+ if (save_to_back_buffer)
+ strbuf_add(&back_buffer, buffer, offset);
+ memmove(buffer, buffer + offset, len);
+ offset = 0;
+ }
+ save_to_back_buffer = set;
+}
+
static void use(int bytes)
{
if (bytes > len)
--
1.8.2.82.gc24b958
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 11/21] unpack-objects: report missing object name
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/unpack-objects.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/unpack-objects.c b/builtin/unpack-objects.c
index 2217d7b..6d0a65c 100644
--- a/builtin/unpack-objects.c
+++ b/builtin/unpack-objects.c
@@ -193,7 +193,7 @@ static int check_object(struct object *obj, int type, void
*data)
unsigned long size;
int type = sha1_object_info(obj->sha1, &size);
if (type != obj->type || type <= 0)
- die("object of unexpected type");
+ die("object %s of unexpected type",
sha1_to_hex(obj->sha1));
obj->flags |= FLAG_WRITTEN;
return 0;
}
--
1.8.2.82.gc24b958
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 12/21] unpack-objects: recognize end-of-pack in v4 thin pack
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/unpack-objects.c | 18 +-
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/builtin/unpack-objects.c b/builtin/unpack-objects.c
index 6d0a65c..c9eb31d 100644
--- a/builtin/unpack-objects.c
+++ b/builtin/unpack-objects.c
@@ -20,6 +20,7 @@ static unsigned char buffer[4096];
static unsigned int offset, len;
static off_t consumed_bytes;
static git_SHA_CTX ctx;
+static int packv4;
/*
* When running under --strict mode, objects whose reachability are
@@ -421,7 +422,7 @@ static void unpack_delta_entry(enum object_type type,
unsigned long delta_size,
free(base);
}
-static void unpack_one(unsigned nr)
+static int unpack_one(unsigned nr)
{
unsigned shift;
unsigned char *pack;
@@ -431,6 +432,10 @@ static void unpack_one(unsigned nr)
obj_list[nr].offset = consumed_bytes;
pack = fill(1);
+ if (packv4 && *(char*)fill(1) == 0) {
+ use(1);
+ return -1;
+ }
c = *pack;
use(1);
type = (c >> 4) & 7;
@@ -450,18 +455,19 @@ static void unpack_one(unsigned nr)
case OBJ_BLOB:
case OBJ_TAG:
unpack_non_delta_entry(type, size, nr);
- return;
+ break;
case OBJ_REF_DELTA:
case OBJ_OFS_DELTA:
unpack_delta_entry(type, size, nr);
- return;
+ break;
default:
error("bad object type %d", type);
has_errors = 1;
if (recover)
- return;
+ break;
exit(1);
}
+ return 0;
}
static void unpack_all(void)
@@ -477,13 +483,15 @@ static void unpack_all(void)
if (!pack_version_ok(hdr->hdr_version))
die("unknown pack file version %"PRIu32,
ntohl(hdr->hdr_version));
+ packv4 = ntohl(hdr->hdr_version) == 4;
use(sizeof(struct pack_header));
if (!quiet)
progress = start_progress("Unpacking objects", nr_objects);
obj_list = xcalloc(nr_objects, sizeof(*obj_list));
for (i = 0; i < nr_objects; i++) {
- unpack_one(i);
+ if (unpack_one(i))
+ break;
display_progress(progress, i + 1);
}
stop_progress(&progress);
--
1.8.2.82.gc24b958
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 13/21] unpack-objects: read v4 dictionaries
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/unpack-objects.c | 50
1 file changed, 50 insertions(+)
diff --git a/builtin/unpack-objects.c b/builtin/unpack-objects.c
index c9eb31d..1a3c30e 100644
--- a/builtin/unpack-objects.c
+++ b/builtin/unpack-objects.c
@@ -10,6 +10,7 @@
#include "tree-walk.h"
#include "progress.h"
#include "decorate.h"
+#include "packv4-parse.h"
#include "fsck.h"
static int dry_run, quiet, recover, has_errors, strict;
@@ -20,7 +21,10 @@ static unsigned char buffer[4096];
static unsigned int offset, len;
static off_t consumed_bytes;
static git_SHA_CTX ctx;
+
static int packv4;
+static unsigned char *sha1_table;
+static struct packv4_dict *name_dict, *path_dict;
/*
* When running under --strict mode, objects whose reachability are
@@ -89,6 +93,28 @@ static void use(int bytes)
consumed_bytes += bytes;
}
+static inline void *fill_and_use(int bytes)
+{
+ void *p = fill(bytes);
+ use(bytes);
+ return p;
+}
+
+static uintmax_t read_varint(void)
+{
+ unsigned char c = *(char*)fill_and_use(1);
+ uintmax_t val = c & 127;
+ while (c & 128) {
+ val += 1;
+ if (!val || MSB(val, 7))
+ die("offset overflow in read_varint at %lu",
+ (unsigned long)consumed_bytes);
+ c = *(char*)fill_and_use(1);
+ val = (val << 7) + (c & 127);
+ }
+ return val;
+}
+
static void *get_data(unsigned long size)
{
git_zstream stream;
@@ -470,6 +496,20 @@ static int unpack_one(unsigned nr)
return 0;
}
+static struct packv4_dict *read_dict(void)
+{
+ unsigned long size;
+ unsigned char *data;
+ struct packv4_dict *dict;
+
+ size = read_varint();
+ data = get_data(size);
+ dict = pv4_create_dict(data, size);
+ if (!dict)
+ die("unable to parse dictionary");
+ return dict;
+}
+
static void unpack_all(void)
{
int i;
@@ -486,6 +526,16 @@ static void unpack_all(void)
packv4 = ntohl(hdr->hdr_version) == 4;
use(sizeof(struct pack_header));
+ if (packv4) {
+ sha1_table = xmalloc(20 * nr_objects);
+ for (i = 0; i < nr_objects; i++) {
+ unsigned char *p = sha1_table + i * 20;
+ hashcpy(p, fill_and_use(20));
+ }
+ name_dict = read_dict();
+ path_dict = read_dict();
+ }
+
if (!quiet)
progress = start_progress("Unpacking objects", nr_objects);
obj_list = xcalloc(nr_objects, sizeof(*obj_list));
--
1.8.2.82.gc24b958
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 15/21] unpack-objects: decode v4 ref-delta
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/unpack-objects.c | 25 ++---
1 file changed, 22 insertions(+), 3 deletions(-)
diff --git a/builtin/unpack-objects.c b/builtin/unpack-objects.c
index a906a98..f8442f4 100644
--- a/builtin/unpack-objects.c
+++ b/builtin/unpack-objects.c
@@ -23,6 +23,7 @@ static off_t consumed_bytes;
static git_SHA_CTX ctx;
static int packv4;
+static unsigned nr_objects;
static unsigned char *sha1_table;
static struct packv4_dict *name_dict, *path_dict;
@@ -115,6 +116,21 @@ static uintmax_t read_varint(void)
return val;
}
+static const unsigned char *read_sha1ref(void)
+{
+ unsigned int index = read_varint();
+ if (!index) {
+ static unsigned char sha1[20];
+ hashcpy(sha1, fill_and_use(20));
+ return sha1;
+ }
+ index--;
+ if (index >= nr_objects)
+ die("bad index in read_sha1ref at %lu",
+ (unsigned long)consumed_bytes);
+ return sha1_table + index * 20;
+}
+
static void *get_data(unsigned long size)
{
git_zstream stream;
@@ -185,7 +201,6 @@ struct obj_info {
#define FLAG_WRITTEN (1u<<21)
static struct obj_info *obj_list;
-static unsigned nr_objects;
/*
* Called only from check_object() after it verified this object
@@ -361,8 +376,12 @@ static void unpack_delta_entry(enum object_type type,
unsigned long delta_size,
unsigned char base_sha1[20];
if (type == OBJ_REF_DELTA) {
- hashcpy(base_sha1, fill(20));
- use(20);
+ if (packv4)
+ hashcpy(base_sha1, read_sha1ref());
+ else {
+ hashcpy(base_sha1, fill(20));
+ use(20);
+ }
delta_data = get_data(delta_size);
if (dry_run || !delta_data) {
free(delta_data);
--
1.8.2.82.gc24b958
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 14/21] unpack-objects: decode v4 object header
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/unpack-objects.c | 38 ++
1 file changed, 22 insertions(+), 16 deletions(-)
diff --git a/builtin/unpack-objects.c b/builtin/unpack-objects.c
index 1a3c30e..a906a98 100644
--- a/builtin/unpack-objects.c
+++ b/builtin/unpack-objects.c
@@ -448,32 +448,38 @@ static void unpack_delta_entry(enum object_type type,
unsigned long delta_size,
free(base);
}
-static int unpack_one(unsigned nr)
+static void read_typesize_v2(enum object_type *type, unsigned long *size)
{
+ unsigned char c = *(char*)fill_and_use(1);
unsigned shift;
- unsigned char *pack;
- unsigned long size, c;
+
+ *type = (c >> 4) & 7;
+ *size = (c & 15);
+ shift = 4;
+ while (c & 128) {
+ c = *(char*)fill_and_use(1);
+ *size += (c & 0x7f) << shift;
+ shift += 7;
+ }
+}
+
+static int unpack_one(unsigned nr)
+{
+ unsigned long size;
enum object_type type;
obj_list[nr].offset = consumed_bytes;
- pack = fill(1);
if (packv4 && *(char*)fill(1) == 0) {
use(1);
return -1;
}
- c = *pack;
- use(1);
- type = (c >> 4) & 7;
- size = (c & 15);
- shift = 4;
- while (c & 0x80) {
- pack = fill(1);
- c = *pack;
- use(1);
- size += (c & 0x7f) << shift;
- shift += 7;
- }
+ if (packv4) {
+ uintmax_t val = read_varint();
+ type = val & 15;
+ size = val >> 4;
+ } else
+ read_typesize_v2(&type, &size);
switch (type) {
case OBJ_COMMIT:
--
1.8.2.82.gc24b958
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 10/21] pack v4: add a note that streaming does not support OBJ_PV4_*
Signed-off-by: Nguyễn Thái Ngọc Duy
---
streaming.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/streaming.c b/streaming.c
index debe904..c7edebb 100644
--- a/streaming.c
+++ b/streaming.c
@@ -437,7 +437,7 @@ static open_method_decl(pack_non_delta)
unuse_pack(&window);
switch (in_pack_type) {
default:
- return -1; /* we do not do deltas for now */
+ return -1; /* we do not do deltas nor pv4 types for now */
case OBJ_COMMIT:
case OBJ_TREE:
case OBJ_BLOB:
--
1.8.2.82.gc24b958
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 08/21] pack-objects: respect compression level in v4
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/pack-objects.c | 5 +++--
packv4-create.c| 17 ++---
packv4-create.h| 6 --
test-packv4.c | 9 +
4 files changed, 22 insertions(+), 15 deletions(-)
diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c
index 39d1e08..63c9b9e 100644
--- a/builtin/pack-objects.c
+++ b/builtin/pack-objects.c
@@ -295,7 +295,8 @@ static unsigned long write_no_reuse_object(struct sha1file
*f, struct object_ent
datalen = size;
else if (pack_version == 4 && entry->type == OBJ_COMMIT) {
datalen = size;
- result = pv4_encode_commit(&v4, buf, &datalen);
+ result = pv4_encode_commit(&v4, buf, &datalen,
+ pack_compression_level);
if (result) {
free(buf);
buf = result;
@@ -857,7 +858,7 @@ static void write_pack_file(void)
if (!offset)
die_errno("unable to write pack header");
if (pack_version == 4)
- offset += packv4_write_tables(f, &v4);
+ offset += packv4_write_tables(f, &v4,
pack_compression_level);
nr_written = 0;
for (; i < nr_objects; i++) {
struct object_entry *e = write_order[i];
diff --git a/packv4-create.c b/packv4-create.c
index 83a6336..3acd10f 100644
--- a/packv4-create.c
+++ b/packv4-create.c
@@ -18,8 +18,6 @@
#include "packv4-create.h"
-int pack_compression_seen;
-int pack_compression_level = Z_DEFAULT_COMPRESSION;
int min_tree_copy = 1;
struct data_entry {
@@ -285,7 +283,8 @@ int encode_sha1ref(const struct packv4_tables *v4,
* regenerated and produce the same hash.
*/
void *pv4_encode_commit(const struct packv4_tables *v4,
- void *buffer, unsigned long *sizep)
+ void *buffer, unsigned long *sizep,
+ int pack_compression_level)
{
unsigned long size = *sizep;
char *in, *tail, *end;
@@ -611,7 +610,8 @@ void *pv4_encode_tree(const struct packv4_tables *v4,
return buffer;
}
-static unsigned long write_dict_table(struct sha1file *f, struct dict_table *t)
+static unsigned long write_dict_table(struct sha1file *f, struct dict_table *t,
+ int pack_compression_level)
{
unsigned char buffer[1024];
unsigned hdrlen;
@@ -661,7 +661,8 @@ static unsigned long write_dict_table(struct sha1file *f,
struct dict_table *t)
}
unsigned long packv4_write_tables(struct sha1file *f,
- const struct packv4_tables *v4)
+ const struct packv4_tables *v4,
+ int pack_compression_level)
{
unsigned nr_objects = v4->all_objs_nr;
struct pack_idx_entry *objs = v4->all_objs;
@@ -676,10 +677,12 @@ unsigned long packv4_write_tables(struct sha1file *f,
written = 20 * nr_objects;
/* Then the commit dictionary table */
- written += write_dict_table(f, commit_ident_table);
+ written += write_dict_table(f, commit_ident_table,
+ pack_compression_level);
/* Followed by the path component dictionary table */
- written += write_dict_table(f, tree_path_table);
+ written += write_dict_table(f, tree_path_table,
+ pack_compression_level);
return written;
}
diff --git a/packv4-create.h b/packv4-create.h
index ba4929a..4ac4d71 100644
--- a/packv4-create.h
+++ b/packv4-create.h
@@ -25,9 +25,11 @@ void sort_dict_entries_by_hits(struct dict_table *t);
int encode_sha1ref(const struct packv4_tables *v4,
const unsigned char *sha1, unsigned char *buf);
unsigned long packv4_write_tables(struct sha1file *f,
- const struct packv4_tables *v4);
+ const struct packv4_tables *v4,
+ int pack_compression_level);
void *pv4_encode_commit(const struct packv4_tables *v4,
- void *buffer, unsigned long *sizep);
+ void *buffer, unsigned long *sizep,
+ int pack_compression_level);
void *pv4_encode_tree(const struct packv4_tables *v4,
void *_buffer, unsigned long *sizep,
void *delta, unsigned long delta_size,
diff --git a/test-packv4.c b/test-packv4.c
index 3b0d7a2..b50422a 100644
--- a/test-packv4.c
+++ b/test-packv4.c
@@ -5,8 +5,8 @@
#include "varint.h"
#include "packv4-create.h"
-extern int pack_compression_seen;
-extern int pack_compression_level;
+static int pack_compression_seen;
+static int pack_compression_level = Z_DEFAULT_COMPRESSION;
extern int min_tree_copy;
static struct pack_idx_entry *get_packed_object_list(struct pac
[PATCH 02/21] fixup! pack-objects: support writing pack v4
Signed-off-by: Nguyễn Thái Ngọc Duy
---
by setting usable_delta to zero, I disable tree delta in
pack-objects. Some test cases spotted this.
builtin/pack-objects.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c
index 945b817..b60b1a0 100644
--- a/builtin/pack-objects.c
+++ b/builtin/pack-objects.c
@@ -256,7 +256,12 @@ static unsigned long write_no_reuse_object(struct sha1file
*f, struct object_ent
struct git_istream *st = NULL;
char *result = "OK";
- if (!usable_delta) {
+ if (!usable_delta ||
+ /*
+* Force loading canonical tree. In future we may want to
+* read v4 trees directly instead.
+*/
+ (pack_version == 4 && entry->type == OBJ_TREE)) {
if (entry->type == OBJ_BLOB &&
entry->size > big_file_threshold &&
(st = open_istream(entry->idx.sha1, &type, &size, NULL)) !=
NULL)
@@ -518,9 +523,6 @@ static unsigned long write_object(struct sha1file *f,
else
usable_delta = 0; /* base could end up in another pack */
- if (pack_version == 4 && entry->type == OBJ_TREE)
- usable_delta = 0;
-
if (!reuse_object)
to_reuse = 0; /* explicit */
else if (!entry->in_pack)
--
1.8.2.82.gc24b958
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 04/21] fixup! index-pack: parse v4 header and dictionaries
Signed-off-by: Nguyễn Thái Ngọc Duy
---
empty pack case
builtin/index-pack.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/builtin/index-pack.c b/builtin/index-pack.c
index 8a6e2a3..89bc708 100644
--- a/builtin/index-pack.c
+++ b/builtin/index-pack.c
@@ -1474,7 +1474,8 @@ static void parse_dictionaries(void)
return;
sha1_table = xmalloc(20 * nr_objects_final);
- hashcpy(sha1_table, fill_and_use(20));
+ if (nr_objects_final)
+ hashcpy(sha1_table, fill_and_use(20));
for (i = 1; i < nr_objects_final; i++) {
unsigned char *p = sha1_table + i * 20;
hashcpy(p, fill_and_use(20));
--
1.8.2.82.gc24b958
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 07/21] pack v4: move pv4 objhdr parsing code to packv4-parse.c
Signed-off-by: Nguyễn Thái Ngọc Duy
---
packv4-parse.c | 12
packv4-parse.h | 5 +
sha1_file.c| 9 ++---
3 files changed, 19 insertions(+), 7 deletions(-)
diff --git a/packv4-parse.c b/packv4-parse.c
index 80ad6fc..7a43635 100644
--- a/packv4-parse.c
+++ b/packv4-parse.c
@@ -570,3 +570,15 @@ void *pv4_get_tree(struct packed_git *p, struct
pack_window **w_curs,
}
return dst;
}
+
+unsigned long pv4_unpack_object_header_buffer(const unsigned char *base,
+ unsigned long len,
+ enum object_type *type,
+ unsigned long *sizep)
+{
+ const unsigned char *cp = base;
+ uintmax_t val = decode_varint(&cp);
+ *type = val & 0xf;
+ *sizep = val >> 4;
+ return cp - base;
+}
diff --git a/packv4-parse.h b/packv4-parse.h
index e6719f6..52f52f5 100644
--- a/packv4-parse.h
+++ b/packv4-parse.h
@@ -10,6 +10,11 @@ struct packv4_dict {
struct packv4_dict *pv4_create_dict(const unsigned char *data, int dict_size);
void pv4_free_dict(struct packv4_dict *dict);
+unsigned long pv4_unpack_object_header_buffer(const unsigned char *base,
+ unsigned long len,
+ enum object_type *type,
+ unsigned long *sizep);
+
void *pv4_get_commit(struct packed_git *p, struct pack_window **w_curs,
off_t offset, unsigned long size);
void *pv4_get_tree(struct packed_git *p, struct pack_window **w_curs,
diff --git a/sha1_file.c b/sha1_file.c
index 1528e28..038e22e 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -1736,13 +1736,8 @@ int unpack_object_header(struct packed_git *p,
base = use_pack(p, w_curs, *curpos, &left);
if (p->version < 4) {
used = unpack_object_header_buffer(base, left, &type, sizep);
- } else {
- const unsigned char *cp = base;
- uintmax_t val = decode_varint(&cp);
- used = cp - base;
- type = val & 0xf;
- *sizep = val >> 4;
- }
+ } else
+ used = pv4_unpack_object_header_buffer(base, left, &type,
sizep);
if (!used) {
type = OBJ_BAD;
} else
--
1.8.2.82.gc24b958
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 03/21] fixup! pack v4: support "end-of-pack" indicator in index-pack and pack-objects
Signed-off-by: Nguyễn Thái Ngọc Duy
---
nr_objects contains a lot more than the number of objects to be
written.
builtin/pack-objects.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c
index b60b1a0..39d1e08 100644
--- a/builtin/pack-objects.c
+++ b/builtin/pack-objects.c
@@ -872,7 +872,7 @@ static void write_pack_file(void)
* Pack v4 thin pack is terminated by a "type
* 0, size 0" in variable length encoding
*/
- if (pack_version == 4 && nr_written < nr_objects)
+ if (pack_version == 4 && nr_written < v4.all_objs_nr)
sha1write(f, &type_zero, 1);
sha1close(f, sha1, CSUM_CLOSE);
} else if (nr_written == nr_remaining) {
--
1.8.2.82.gc24b958
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 09/21] pack-objects: recognize v4 as pack source
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/pack-objects.c | 28 +---
packv4-parse.h | 2 ++
2 files changed, 27 insertions(+), 3 deletions(-)
diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c
index 63c9b9e..ac25973 100644
--- a/builtin/pack-objects.c
+++ b/builtin/pack-objects.c
@@ -19,6 +19,8 @@
#include "streaming.h"
#include "thread-utils.h"
#include "packv4-create.h"
+#include "packv4-parse.h"
+#include "varint.h"
static const char *pack_usage[] = {
N_("git pack-objects --stdout [options...] [< ref-list | <
object-list]"),
@@ -1397,9 +1399,14 @@ static void check_object(struct object_entry *entry)
* We want in_pack_type even if we do not reuse delta
* since non-delta representations could still be reused.
*/
- used = unpack_object_header_buffer(buf, avail,
- &entry->in_pack_type,
- &entry->size);
+ if (p->version < 4)
+ used = unpack_object_header_buffer(buf, avail,
+ &entry->in_pack_type,
+ &entry->size);
+ else
+ used = pv4_unpack_object_header_buffer(buf, avail,
+
&entry->in_pack_type,
+ &entry->size);
if (used == 0)
goto give_up;
@@ -1417,7 +1424,22 @@ static void check_object(struct object_entry *entry)
goto give_up;
unuse_pack(&w_curs);
return;
+ case OBJ_PV4_COMMIT:
+ case OBJ_PV4_TREE:
+ entry->type = entry->in_pack_type - 8;
+ entry->in_pack_header_size = used;
+ unuse_pack(&w_curs);
+ return;
case OBJ_REF_DELTA:
+ if (p->version == 4) {
+ const unsigned char *sha1, *cp;
+ cp = buf + used;
+ sha1 = get_sha1ref(p, &cp);
+ entry->in_pack_header_size = cp - buf;;
+ if (reuse_delta && !entry->preferred_base)
+ base_ref = sha1;
+ break;
+ }
if (reuse_delta && !entry->preferred_base)
base_ref = use_pack(p, &w_curs,
entry->in_pack_offset + used,
NULL);
diff --git a/packv4-parse.h b/packv4-parse.h
index 52f52f5..d674a3f 100644
--- a/packv4-parse.h
+++ b/packv4-parse.h
@@ -14,6 +14,8 @@ unsigned long pv4_unpack_object_header_buffer(const unsigned
char *base,
unsigned long len,
enum object_type *type,
unsigned long *sizep);
+const unsigned char *get_sha1ref(struct packed_git *p,
+const unsigned char **bufp);
void *pv4_get_commit(struct packed_git *p, struct pack_window **w_curs,
off_t offset, unsigned long size);
--
1.8.2.82.gc24b958
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 05/21] fixup! index-pack: record all delta bases in v4 (tree and ref-delta)
Signed-off-by: Nguyễn Thái Ngọc Duy
---
compiler warning fix
builtin/index-pack.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/index-pack.c b/builtin/index-pack.c
index 89bc708..1895adf 100644
--- a/builtin/index-pack.c
+++ b/builtin/index-pack.c
@@ -776,7 +776,7 @@ static void *unpack_raw_entry(struct object_entry *obj,
case OBJ_OFS_DELTA:
if (packv4)
die(_("pack version 4 does not support ofs-delta type
(offset %lu)"),
- obj->idx.offset);
+ (unsigned long)obj->idx.offset);
offset = obj->idx.offset - read_varint();
if (offset <= 0 || offset >= obj->idx.offset)
bad_object(obj->idx.offset,
--
1.8.2.82.gc24b958
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 00/21] np/pack-v4 updates
This contains fixups for some of my patches, some of Nico's, adds v4 support to unpack-objects because the test suite needs it. With these, when force generating pack v4 unconditionally, the remaining failed tests are: - t5300-pack-object: ofs-delta tests fail (not surprising). core.packsizelimit also fails. Kinda expected, but not my top priority. - t5302-pack-index: mainly to test .idx v2, expected - t5303-pack-corruption-resilience: if I force generating .idx v2 with .pack v4, I could get to 1/3 of it. Need a deeper look. So v4 code is in pretty good shape in terms of correctness and near function complete. Brave souls should try it out. Nguyễn Thái Ngọc Duy (21): fixup! pack-objects: prepare SHA-1 table in v4 fixup! pack-objects: support writing pack v4 fixup! pack v4: support "end-of-pack" indicator in index-pack and pack-objects fixup! index-pack: parse v4 header and dictionaries fixup! index-pack: record all delta bases in v4 (tree and ref-delta) pack v4: lift dict size check in load_dict() pack v4: move pv4 objhdr parsing code to packv4-parse.c pack-objects: respect compression level in v4 pack-objects: recognize v4 as pack source pack v4: add a note that streaming does not support OBJ_PV4_* unpack-objects: report missing object name unpack-objects: recognize end-of-pack in v4 thin pack unpack-objects: read v4 dictionaries unpack-objects: decode v4 object header unpack-objects: decode v4 ref-delta unpack-objects: decode v4 commits unpack-objects: allow to save processed bytes to a buffer unpack-objects: decode v4 trees index-pack, pack-objects: allow creating .idx v2 with .pack v4 show-index: acknowledge that it does not read .idx v3 t1050, t5500: replace the use of "show-index|wc -l" with verify-pack builtin/index-pack.c | 19 ++- builtin/pack-objects.c | 60 +-- builtin/unpack-objects.c | 395 --- packv4-create.c | 17 +- packv4-create.h | 6 +- packv4-parse.c | 16 +- packv4-parse.h | 7 + sha1_file.c | 9 +- show-index.c | 4 +- streaming.c | 2 +- t/t1050-large.sh | 9 +- t/t5500-fetch-pack.sh| 4 +- test-packv4.c| 9 +- 13 files changed, 480 insertions(+), 77 deletions(-) -- 1.8.2.82.gc24b958 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 06/21] pack v4: lift dict size check in load_dict()
A pack with no trees (or an empty pack) could have zero-sized name
dictionary.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
packv4-parse.c | 4
1 file changed, 4 deletions(-)
diff --git a/packv4-parse.c b/packv4-parse.c
index f96acc1..80ad6fc 100644
--- a/packv4-parse.c
+++ b/packv4-parse.c
@@ -87,10 +87,6 @@ static struct packv4_dict *load_dict(struct packed_git *p,
off_t *offset)
src = use_pack(p, &w_curs, curpos, &avail);
cp = src;
dict_size = decode_varint(&cp);
- if (dict_size < 3) {
- error("bad dict size");
- return NULL;
- }
curpos += cp - src;
data = xmallocz(dict_size);
--
1.8.2.82.gc24b958
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 01/21] fixup! pack-objects: prepare SHA-1 table in v4
Signed-off-by: Nguyễn Thái Ngọc Duy
---
remove debugging code
builtin/pack-objects.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c
index 1efb728..945b817 100644
--- a/builtin/pack-objects.c
+++ b/builtin/pack-objects.c
@@ -816,7 +816,6 @@ static void prepare_sha1_table(uint32_t start, struct
object_entry **write_order
struct object_entry *e = write_order[i];
if (e->idx.offset > 0) {
v4.all_objs[v4.all_objs_nr++] = e->idx;
- fprintf(stderr, "%s in\n", sha1_to_hex(e->idx.sha1));
e->idx.offset = 0;
}
}
--
1.8.2.82.gc24b958
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] reset: handle submodule with trailing slash
Am 10.09.2013 21:13, schrieb John Keeping:
> When using tab-completion, a directory path will often end with a
> trailing slash which currently confuses "git rm" when dealing with
> submodules. Now that we have parse_pathspec we can easily handle this
> by simply adding the PATHSPEC_STRIP_SUBMODULE_SLASH_CHEAP flag.
>
> Signed-off-by: John Keeping
> ---
> builtin/reset.c| 5 +
> t/t7400-submodule-basic.sh | 6 --
> 2 files changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/builtin/reset.c b/builtin/reset.c
> index 5e4c551..9efac0f 100644
> --- a/builtin/reset.c
> +++ b/builtin/reset.c
> @@ -220,8 +220,13 @@ static void parse_args(struct pathspec *pathspec,
> }
> }
> *rev_ret = rev;
> +
> + if (read_cache() < 0)
> + die(_("index file corrupt"));
When the index is now read here, I would have expected hunk in this
patch that removes a read_cache() invocation.
> +
> parse_pathspec(pathspec, 0,
> PATHSPEC_PREFER_FULL |
> +PATHSPEC_STRIP_SUBMODULE_SLASH_CHEAP |
> (patch_mode ? PATHSPEC_PREFIX_ORIGIN : 0),
> prefix, argv);
> }
> diff --git a/t/t7400-submodule-basic.sh b/t/t7400-submodule-basic.sh
> index 4192fe0..c268d3c 100755
> --- a/t/t7400-submodule-basic.sh
> +++ b/t/t7400-submodule-basic.sh
> @@ -481,7 +481,7 @@ test_expect_success 'do not add files from a submodule' '
>
> '
>
> -test_expect_success 'gracefully add submodule with a trailing slash' '
> +test_expect_success 'gracefully add/reset submodule with a trailing slash' '
>
> git reset --hard &&
> git commit -m "commit subproject" init &&
> @@ -495,7 +495,9 @@ test_expect_success 'gracefully add submodule with a
> trailing slash' '
> git add init/ &&
> test_must_fail git diff --exit-code --cached init &&
> test $commit = $(git ls-files --stage |
> - sed -n "s/^16 \([^ ]*\).*/\1/p")
> + sed -n "s/^16 \([^ ]*\).*/\1/p") &&
> + git reset init/ &&
> + git diff --exit-code --cached init
>
> '
>
>
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Regression in e02ca72: git svn rebase is broken on Windows
Am 11.09.2013 05:19, schrieb Jiang Xin:
> I tested 'relative_path' function using 'test-path-utils', and got the
> following result:
>
> $ ./test-path-utils relative_path 'C:/a/b' 'D:/x/y'
> ../../../C:/a/b
>
> $ ./test-path-utils relative_path '/a/b' 'x/y'
> ../..//a/b
>
> $ ./test-path-utils relative_path 'a/b' '/x/y'
> ../../../a/b
>
> For the first case, in and prefix are on different ROOT, and for the other
> two cases, one path is a relative path, and another is an absolute path.
>
> I write a patch to test whether two paths (in and prefix) have the same
> root. The result after applied the patch:
>
> $ ./test-path-utils relative_path 'C:/a/b' 'C:/x/y'
> ../../a/b
>
> $ ./test-path-utils relative_path 'C:/a/b' 'D:/x/y'
> C:/a/b
>
> $ ./test-path-utils relative_path '/a/b' 'x/y'
> /a/b
>
> $ ./test-path-utils relative_path 'a/b' '/x/y'
> a/b
>
>
> diff --git a/path.c b/path.c
> index 7f3324a..51f5d28 100644
> --- a/path.c
> +++ b/path.c
> @@ -441,6 +441,25 @@ int adjust_shared_perm(const char *path)
> return 0;
> }
>
> +static int have_same_root(const char *path1, const char *path2)
> +{
> + /* for POSIX:
> +
> + return ((path1 && is_dir_sep(*path1)) ^
> + (path2 && is_dir_sep(*path2))) == 0;
> + */
> + return path1 && path2 && *path1 && *path2 && (
> + (is_dir_sep(*path1) &&
> +is_dir_sep(*path2)) ||
> + (*(path1+1) == ':' &&
> +*(path2+1) == ':' &&
> +!strncasecmp(path1, path2, 1)) ||
> + (!is_dir_sep(*path1) &&
> +!is_dir_sep(*path2) &&
> +*(path1+1) != ':' &&
> +*(path2+1) != ':'));
I think this can be simplified to
return path1 && path2 &&
is_absolute_path(path1) &&
is_absolute_path(path2) &&
!strncasecmp(path1, path2, 1);
which would not mistake a path D:/foo on Unix as an absolute path.
> +}
-- Hannes
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Regression in e02ca72: git svn rebase is broken on Windows
2013/9/11 Karsten Blees : > Junio C Hamano pobox.com> writes: > >> The suspect commit and symptom look consistent. You started from a >> directory whose absolute path is "w:/work/..." and the updated code >> mistakenly thoguht that something that begins with "w" (not '/') is >> not an absolute, so added a series of ../ to make it relative, or >> something silly like that. >> >> Jiang? >> > > Indeed, this patch seems to change relative_path in a way that breaks git > initialization, not just on Windows. > > Previously, relative_path was always called with two absolute paths, and it > only returned a relative path if the first was a subdir of the second (so a > better name would probably have been 'relative_path_if_subdir'). The purpose > was to improve performance by making GIT_DIR shorter if it was a subdir of > GIT_WORK_TREE. Yes, it's what commit v1.5.6-1-g044bbbc says. > After this patch, relative_path always tries to return a relative path, even > if both absolute paths are completely disjunct. This not only defeats the > purpose (by making GIT_DIR longer, thus hurting performance), it is also not Sometimes longer, sometimes shorter maybe. > possible in general. POSIX explicitly allows for '//hostname' notation > referring to network resources that are not explicitly mounted under '/'. > I.e. given two absolute paths '//hostname1/a' and '//hostname2/b', there is > no relative path from a to b or vice versa. Yes, path like "//hostname/path" can be used on Windows. My hack "have_same_root" does not cover this case, so using a "simple_relative_path" function instead of "relative_path" in setup.c may be the better. -- Jiang Xin -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Regression in e02ca72: git svn rebase is broken on Windows
2013/9/11 Junio C Hamano :
> Tvangeste writes:
>
>> Hi,
>>
>> After bisecting this problem I ended up with the mentioned commit that
>> completely breaks git-svn for me on Windows (mingw/msys version).
>>
>> ==
>> #> git svn rebase
>> warning: unable to access '': Invalid argument
>> warning: unable to access '': Invalid argument
>> fatal: unable to access '../../../../w:/work/my/repo.git/.git/config':
>> Invalid argument
>> fatal: index file open failed: Invalid argument
>> Cannot rebase: You have unstaged changes.
>> Please commit or stash them.
>> rebase refs/remotes/trunk: command returned error: 1
>> ==
>>
>> Please note that I use the official git repository as-is, this one (no
>> additional patches):
>> git://git.kernel.org/pub/scm/git/git.git
>>
>> e02ca72f70ed8f0268a81f72cb3230c72e538e77 is the first bad commit
>> commit e02ca72f70ed8f0268a81f72cb3230c72e538e77
>> Author: Jiang Xin
>> Date: Tue Jun 25 23:53:43 2013 +0800
>>
>> path.c: refactor relative_path(), not only strip prefix
>>
>> Thanks,
>> --Tvangeste
>
> The suspect commit and symptom look consistent. You started from a
> directory whose absolute path is "w:/work/..." and the updated code
> mistakenly thoguht that something that begins with "w" (not '/') is
> not an absolute, so added a series of ../ to make it relative, or
> something silly like that.
>
> Jiang?
I tested 'relative_path' function using 'test-path-utils', and got the
following result:
$ ./test-path-utils relative_path 'C:/a/b' 'D:/x/y'
../../../C:/a/b
$ ./test-path-utils relative_path '/a/b' 'x/y'
../..//a/b
$ ./test-path-utils relative_path 'a/b' '/x/y'
../../../a/b
For the first case, in and prefix are on different ROOT, and for the other
two cases, one path is a relative path, and another is an absolute path.
I write a patch to test whether two paths (in and prefix) have the same
root. The result after applied the patch:
$ ./test-path-utils relative_path 'C:/a/b' 'C:/x/y'
../../a/b
$ ./test-path-utils relative_path 'C:/a/b' 'D:/x/y'
C:/a/b
$ ./test-path-utils relative_path '/a/b' 'x/y'
/a/b
$ ./test-path-utils relative_path 'a/b' '/x/y'
a/b
diff --git a/path.c b/path.c
index 7f3324a..51f5d28 100644
--- a/path.c
+++ b/path.c
@@ -441,6 +441,25 @@ int adjust_shared_perm(const char *path)
return 0;
}
+static int have_same_root(const char *path1, const char *path2)
+{
+ /* for POSIX:
+
+ return ((path1 && is_dir_sep(*path1)) ^
+ (path2 && is_dir_sep(*path2))) == 0;
+ */
+ return path1 && path2 && *path1 && *path2 && (
+ (is_dir_sep(*path1) &&
+is_dir_sep(*path2)) ||
+ (*(path1+1) == ':' &&
+*(path2+1) == ':' &&
+!strncasecmp(path1, path2, 1)) ||
+ (!is_dir_sep(*path1) &&
+!is_dir_sep(*path2) &&
+*(path1+1) != ':' &&
+*(path2+1) != ':'));
+}
+
/*
* Give path as relative to prefix.
*
@@ -461,6 +480,9 @@ const char *relative_path(const char *in, const
char *prefix,
else if (!prefix_len)
return in;
+ if (!have_same_root(in, prefix))
+ return in;
+
Should I write the function have_same_root as inline function or macro
like 'is_dir_sep'?
--
Jiang Xin
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Documentation/git-checkout: Move `--detach` flag in synopsis to correct command
>From a33659535cb0eac92bed42d5e494dbb8f5d9ab20 Mon Sep 17 00:00:00 2001 From: Benjamin Bergman Date: Tue, 10 Sep 2013 16:00:29 -0500 Subject: [PATCH] Documentation/git-checkout: Move `--detach` flag in synopsis to correct command Detailed description of `--detach` states that it is default for `` but needs to be specified for ``. The old man page synopsis showed the reverse. --- Documentation/git-checkout.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt index ca118ac..dee95e8 100644 --- a/Documentation/git-checkout.txt +++ b/Documentation/git-checkout.txt @@ -8,8 +8,8 @@ git-checkout - Checkout a branch or paths to the working tree SYNOPSIS [verse] -'git checkout' [-q] [-f] [-m] [] -'git checkout' [-q] [-f] [-m] [--detach] [] +'git checkout' [-q] [-f] [-m] [--detach] [] +'git checkout' [-q] [-f] [-m] [] 'git checkout' [-q] [-f] [-m] [[-b|-B|--orphan] ] [] 'git checkout' [-f|--ours|--theirs|-m|--conflict=
Re: [PATCH] http-backend: provide Allow header for 405
On Sun, Sep 08, 2013 at 09:18:12PM -0700, Jonathan Nieder wrote:
> > --- a/http-backend.c
> > +++ b/http-backend.c
> > @@ -594,8 +594,11 @@ int main(int argc, char **argv)
> >
> > if (strcmp(method, c->method)) {
> > const char *proto = getenv("SERVER_PROTOCOL");
> > - if (proto && !strcmp(proto, "HTTP/1.1"))
> > + if (proto && !strcmp(proto, "HTTP/1.1")) {
> > http_status(405, "Method Not Allowed");
> > + hdr_str("Allow", !strcmp("GET",
> > c->method) ?
> > + "GET, HEAD" : c->method);
> > + }
> > else
>
> Small style nit: the closing brace should go on the same line as the
> "else", like so:
>
> if (proto && ...) {
> ...
> } else
> http_status(400, "Bad Request");
>
> Another micronit: the comparison should be !strcmp(c->method, "GET")
> --- variable first, then constant it is being compared to.
>
> The functional change looks good.
I plan on doing a reroll tomorrow.
--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187
signature.asc
Description: Digital signature
Re: push.default=upstream doesn't play nicely with remote.pushdefault/branch.*.pushremote
On Tue, Sep 10, 2013 at 8:10 AM, Ximin Luo wrote: > (Please CC me as I am not subscribed.) No need to say that, Git mailing list is sane and doesn't do reply-to munging. > The question here then is, what remote branch should git push to - since > pushremote only specifies a repo? I can suggest two options: > > - A: push to branch.*.merge if it's defined; otherwise push to branch> (like push.default=current) > - B: push to regardless Or C: introduce the concept of a publish branch to complement pushremote: http://article.gmane.org/gmane.comp.version-control.git/233572 -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] MSVC: fix stat definition hell
On Tue, Sep 10, 2013 at 7:23 PM, Karsten Blees wrote: > In msvc.h, there's a couple of stat related functions defined diffently s/diffently/differently/ > from mingw.h. When we remove these definitions, the only problem we get is > "warning C4005: '_stati64' : macro redefinition" for this line in mingw.h: > > #define _stati64(x,y) mingw_stat(x,y) > > The reason is that as of MSVCR80.dll (distributed with MSVC 2005), the > original _stati64 family of functions was renamed to _stat32i64, and the > former function names became macros (pointing to the appropriate function > based on the definition of _USE_32BIT_TIME_T). > > Defining _stati64 works on MinGW because MinGW by default compiles against > the MSVCRT.DLL that is part of Windows (i.e. _stati64 is a function rather > than a macro). > > Note: MinGW *can* compile for newer MSVC runtime versions, and MSVC > apparently can also compile for the Windows MSVCRT.DLL via the DDK (see > http://www.syndicateofideas.com/posts/fighting-the-msvcrt-dll-hell ). > > Remove the stat definitions from msvc.h, as they are not compiler related. > > In mingw.h, determine the runtime version in use from the definitions of > _stati64 and _USE_32BIT_TIME_T, and define stat() accordingly. > > This also fixes that stat() in MSVC builds still resolves to mingw_lstat() > instead of mingw_stat(). > > Signed-off-by: Karsten Blees -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH-v3] Allow git-filter-branch to process large repositories with lots of branches.
On 9/10/13 4:20 PM, "Junio C Hamano" wrote:
>Lee Carver writes:
>
>> As noted in several forums, a recommended way to move trees between
>> repositories
>> is to use git-filter-branch to revise the history for a single tree:
>>
>>
>>http://gbayer.com/development/moving-files-from-one-git-repository-to-ano
>>th
>> er-preserving-history/
>>
>>http://stackoverflow.com/questions/1365541/how-to-move-files-from-one-git
>>-r
>> epo-to-another-not-a-clone-preserving-history
>>
>> However, this can lead to argument list too long errors when the
>>original
>> repository has many retained branches (>6k)
>>
>> /usr/local/git/libexec/git-core/git-filter-branch: line 270:
>> /usr/local/git/libexec/git-core/git: Argument list too long
>> Could not get the commits
>>
>> Piping the saved output from git rev-parse into git rev-list avoids this
>> problem, since the rev-parse output is not processed as a command line
>> argument.
>> ---
>> git-filter-branch.sh | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/git-filter-branch.sh b/git-filter-branch.sh
>> index ac2a005..2091885 100755
>> --- a/git-filter-branch.shgit
>> +++ b/git-filter-branch.sh
>> @@ -255,7 +255,7 @@ else
>> remap_to_ancestor=t
>> fi
>>
>> -rev_args=$(git rev-parse --revs-only "$@")
>> +git rev-parse --revs-only "$@" > ../parse
>
>Where is this "rev-parse" command running? Is it always safe to
>clobber the file "../parse" like this?
It is using the same ${tempdir} working directory that git rev-list uses
below for the ../revs file
It's normally .git-rewrite/t, following the normal working directory setup
near line 205.
>
>>
>> case "$filter_subdir" in
>> "")
>> @@ -268,7 +268,7 @@ case "$filter_subdir" in
>> esac
>>
>> git rev-list --reverse --topo-order --default HEAD \
>> ---parents --simplify-merges $rev_args "$@" > ../revs ||
>> +--parents --simplify-merges --stdin "$@" < ../parse > ../revs ||
>> die "Could not get the commits"
>> commits=$(wc -l <../revs | tr -d " ")
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hello
Hello, You have won 1,000.000 great british pounds in the ongoing promo draw. For claims, contact Mr Jeremy via email on: jeremy-off...@qq.com Thanks, T. Stratford. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH/RFC 5/5] diffcore-rename.c: use new hash map implementation
Signed-off-by: Karsten Blees
---
diffcore-rename.c | 48 +---
1 file changed, 13 insertions(+), 35 deletions(-)
diff --git a/diffcore-rename.c b/diffcore-rename.c
index 82b7975..6271af9 100644
--- a/diffcore-rename.c
+++ b/diffcore-rename.c
@@ -4,7 +4,7 @@
#include "cache.h"
#include "diff.h"
#include "diffcore.h"
-#include "hash.h"
+#include "hashmap.h"
#include "progress.h"
/* Table of rename/copy destinations */
@@ -243,9 +243,9 @@ static int score_compare(const void *a_, const void *b_)
}
struct file_similarity {
+ hashmap_entry entry;
int index;
struct diff_filespec *filespec;
- struct file_similarity *next;
};
static unsigned int hash_filespec(struct diff_filespec *filespec)
@@ -260,21 +260,22 @@ static unsigned int hash_filespec(struct diff_filespec
*filespec)
return hash;
}
-static int find_identical_files(struct hash_table *srcs,
+static int find_identical_files(hashmap *srcs,
int dst_index,
struct diff_options *options)
{
int renames = 0;
struct diff_filespec *target = rename_dst[dst_index].two;
- struct file_similarity *p, *best;
+ struct file_similarity *p, *best, dst;
int i = 100, best_score = -1;
/*
* Find the best source match for specified destination.
*/
best = NULL;
- for (p = lookup_hash(hash_filespec(target), srcs); p; p = p->next) {
+ hashmap_entry_init(&dst, hash_filespec(target), 0);
+ for (p = hashmap_get(srcs, &dst); p; p = hashmap_get_next(srcs, p)) {
int score;
struct diff_filespec *source = p->filespec;
@@ -309,34 +310,15 @@ static int find_identical_files(struct hash_table *srcs,
return renames;
}
-static int free_similarity_list(void *p, void *unused)
+static void insert_file_table(hashmap *table, int index, struct diff_filespec
*filespec)
{
- while (p) {
- struct file_similarity *entry = p;
- p = entry->next;
- free(entry);
- }
- return 0;
-}
-
-static void insert_file_table(struct hash_table *table, int index, struct
diff_filespec *filespec)
-{
- void **pos;
- unsigned int hash;
struct file_similarity *entry = xmalloc(sizeof(*entry));
entry->index = index;
entry->filespec = filespec;
- entry->next = NULL;
-
- hash = hash_filespec(filespec);
- pos = insert_hash(hash, entry, table);
- /* We already had an entry there? */
- if (pos) {
- entry->next = *pos;
- *pos = entry;
- }
+ hashmap_entry_init(entry, hash_filespec(filespec), 0);
+ hashmap_add(table, entry);
}
/*
@@ -349,11 +331,10 @@ static void insert_file_table(struct hash_table *table,
int index, struct diff_f
static int find_exact_renames(struct diff_options *options)
{
int i, renames;
- struct hash_table file_table;
+ hashmap file_table;
/* Add all sources to the hash table */
- init_hash(&file_table);
- preallocate_hash(&file_table, rename_src_nr);
+ hashmap_init(&file_table, NULL, rename_src_nr);
for (i = 0; i < rename_src_nr; i++)
insert_file_table(&file_table, i, rename_src[i].p->one);
@@ -361,11 +342,8 @@ static int find_exact_renames(struct diff_options *options)
for (i = 0; i < rename_dst_nr; i++)
renames += find_identical_files(&file_table, i, options);
- /* Free source file_similarity chains */
- for_each_hash(&file_table, free_similarity_list, options);
-
- /* .. and free the hash data structure */
- free_hash(&file_table);
+ /* Free the hash data structure and entries */
+ hashmap_free(&file_table, free);
return renames;
}
--
1.8.4.8243.gbcbdefd
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH/RFC 4/5] diffcore-rename.c: simplify finding exact renames
The find_exact_renames function currently only uses the hash table for
grouping, i.e.:
1. add sources
2. add destinations
3. iterate all buckets, per bucket:
4. split sources from destinations
5. iterate destinations, per destination:
6. iterate sources to find best match
This can be simplified by utilizing the lookup functionality of the hash
table, i.e.:
1. add sources
2. iterate destinations, per destination:
3. lookup sources matching the current destination
4. iterate sources to find best match
This saves several iterations and file_similarity allocations for the
destinations.
Signed-off-by: Karsten Blees
---
diffcore-rename.c | 75 +++
1 file changed, 20 insertions(+), 55 deletions(-)
diff --git a/diffcore-rename.c b/diffcore-rename.c
index 008a60c..82b7975 100644
--- a/diffcore-rename.c
+++ b/diffcore-rename.c
@@ -243,7 +243,7 @@ static int score_compare(const void *a_, const void *b_)
}
struct file_similarity {
- int src_dst, index;
+ int index;
struct diff_filespec *filespec;
struct file_similarity *next;
};
@@ -260,25 +260,21 @@ static unsigned int hash_filespec(struct diff_filespec
*filespec)
return hash;
}
-static int find_identical_files(struct file_similarity *src,
- struct file_similarity *dst,
+static int find_identical_files(struct hash_table *srcs,
+ int dst_index,
struct diff_options *options)
{
int renames = 0;
- /*
-* Walk over all the destinations ...
-*/
- do {
- struct diff_filespec *target = dst->filespec;
+ struct diff_filespec *target = rename_dst[dst_index].two;
struct file_similarity *p, *best;
int i = 100, best_score = -1;
/*
-* .. to find the best source match
+* Find the best source match for specified destination.
*/
best = NULL;
- for (p = src; p; p = p->next) {
+ for (p = lookup_hash(hash_filespec(target), srcs); p; p = p->next) {
int score;
struct diff_filespec *source = p->filespec;
@@ -307,61 +303,28 @@ static int find_identical_files(struct file_similarity
*src,
break;
}
if (best) {
- record_rename_pair(dst->index, best->index, MAX_SCORE);
+ record_rename_pair(dst_index, best->index, MAX_SCORE);
renames++;
}
- } while ((dst = dst->next) != NULL);
return renames;
}
-static void free_similarity_list(struct file_similarity *p)
+static int free_similarity_list(void *p, void *unused)
{
while (p) {
struct file_similarity *entry = p;
- p = p->next;
+ p = entry->next;
free(entry);
}
+ return 0;
}
-static int find_same_files(void *ptr, void *data)
-{
- int ret;
- struct file_similarity *p = ptr;
- struct file_similarity *src = NULL, *dst = NULL;
- struct diff_options *options = data;
-
- /* Split the hash list up into sources and destinations */
- do {
- struct file_similarity *entry = p;
- p = p->next;
- if (entry->src_dst < 0) {
- entry->next = src;
- src = entry;
- } else {
- entry->next = dst;
- dst = entry;
- }
- } while (p);
-
- /*
-* If we have both sources *and* destinations, see if
-* we can match them up
-*/
- ret = (src && dst) ? find_identical_files(src, dst, options) : 0;
-
- /* Free the hashes and return the number of renames found */
- free_similarity_list(src);
- free_similarity_list(dst);
- return ret;
-}
-
-static void insert_file_table(struct hash_table *table, int src_dst, int
index, struct diff_filespec *filespec)
+static void insert_file_table(struct hash_table *table, int index, struct
diff_filespec *filespec)
{
void **pos;
unsigned int hash;
struct file_similarity *entry = xmalloc(sizeof(*entry));
- entry->src_dst = src_dst;
entry->index = index;
entry->filespec = filespec;
entry->next = NULL;
@@ -385,24 +348,26 @@ static void insert_file_table(struct hash_table *table,
int src_dst, int index,
*/
static int find_exact_renames(struct diff_options *options)
{
- int i;
+ int i, renames;
struct hash_table file_table;
+ /* Add all sources to the hash table */
init_hash(&file_table);
- preallocate_hash(&file_table, rename_src_nr + rename_dst_nr);
+ preallocate_hash(&file_table, rename_src_nr);
for (i = 0; i < rename_src_nr; i++)
- insert_file_table(&file_table, -1, i, rename_src[i].p->one);
+ insert_file_table(&file_tabl
[PATCH/RFC 3/5] diffcore-rename.c: move code around to prepare for the next patch
No actual code changes, just move hash_filespec up and outdent part of
find_identical_files.
Signed-off-by: Karsten Blees
---
diffcore-rename.c | 98 +++
1 file changed, 49 insertions(+), 49 deletions(-)
diff --git a/diffcore-rename.c b/diffcore-rename.c
index 6c7a72f..008a60c 100644
--- a/diffcore-rename.c
+++ b/diffcore-rename.c
@@ -248,6 +248,18 @@ struct file_similarity {
struct file_similarity *next;
};
+static unsigned int hash_filespec(struct diff_filespec *filespec)
+{
+ unsigned int hash;
+ if (!filespec->sha1_valid) {
+ if (diff_populate_filespec(filespec, 0))
+ return 0;
+ hash_sha1_file(filespec->data, filespec->size, "blob",
filespec->sha1);
+ }
+ memcpy(&hash, filespec->sha1, sizeof(hash));
+ return hash;
+}
+
static int find_identical_files(struct file_similarity *src,
struct file_similarity *dst,
struct diff_options *options)
@@ -258,46 +270,46 @@ static int find_identical_files(struct file_similarity
*src,
* Walk over all the destinations ...
*/
do {
- struct diff_filespec *target = dst->filespec;
- struct file_similarity *p, *best;
- int i = 100, best_score = -1;
-
- /*
-* .. to find the best source match
-*/
- best = NULL;
- for (p = src; p; p = p->next) {
- int score;
- struct diff_filespec *source = p->filespec;
-
- /* False hash collision? */
- if (hashcmp(source->sha1, target->sha1))
- continue;
- /* Non-regular files? If so, the modes must match! */
- if (!S_ISREG(source->mode) || !S_ISREG(target->mode)) {
- if (source->mode != target->mode)
- continue;
- }
- /* Give higher scores to sources that haven't been used
already */
- score = !source->rename_used;
- if (source->rename_used && options->detect_rename !=
DIFF_DETECT_COPY)
- continue;
- score += basename_same(source, target);
- if (score > best_score) {
- best = p;
- best_score = score;
- if (score == 2)
- break;
- }
+ struct diff_filespec *target = dst->filespec;
+ struct file_similarity *p, *best;
+ int i = 100, best_score = -1;
- /* Too many identical alternatives? Pick one */
- if (!--i)
- break;
+ /*
+* .. to find the best source match
+*/
+ best = NULL;
+ for (p = src; p; p = p->next) {
+ int score;
+ struct diff_filespec *source = p->filespec;
+
+ /* False hash collision? */
+ if (hashcmp(source->sha1, target->sha1))
+ continue;
+ /* Non-regular files? If so, the modes must match! */
+ if (!S_ISREG(source->mode) || !S_ISREG(target->mode)) {
+ if (source->mode != target->mode)
+ continue;
}
- if (best) {
- record_rename_pair(dst->index, best->index, MAX_SCORE);
- renames++;
+ /* Give higher scores to sources that haven't been used already
*/
+ score = !source->rename_used;
+ if (source->rename_used && options->detect_rename !=
DIFF_DETECT_COPY)
+ continue;
+ score += basename_same(source, target);
+ if (score > best_score) {
+ best = p;
+ best_score = score;
+ if (score == 2)
+ break;
}
+
+ /* Too many identical alternatives? Pick one */
+ if (!--i)
+ break;
+ }
+ if (best) {
+ record_rename_pair(dst->index, best->index, MAX_SCORE);
+ renames++;
+ }
} while ((dst = dst->next) != NULL);
return renames;
}
@@ -343,18 +355,6 @@ static int find_same_files(void *ptr, void *data)
return ret;
}
-static unsigned int hash_filespec(struct diff_filespec *filespec)
-{
- unsigned int hash;
- if (!filespec->sha1_valid) {
- if (diff_populate_filespec(filespec, 0))
- return 0;
- hash_sha1_file(filespec->data, filespec-
[PATCH/RFC 2/5] buitin/describe.c: use new hash map implementation
Signed-off-by: Karsten Blees
---
builtin/describe.c | 53 -
1 file changed, 24 insertions(+), 29 deletions(-)
diff --git a/builtin/describe.c b/builtin/describe.c
index 7d73722..bbc7159 100644
--- a/builtin/describe.c
+++ b/builtin/describe.c
@@ -6,7 +6,7 @@
#include "exec_cmd.h"
#include "parse-options.h"
#include "diff.h"
-#include "hash.h"
+#include "hashmap.h"
#include "argv-array.h"
#define SEEN (1u<<0)
@@ -25,7 +25,7 @@ static int longformat;
static int first_parent;
static int abbrev = -1; /* unspecified */
static int max_candidates = 10;
-static struct hash_table names;
+static hashmap names;
static int have_util;
static const char *pattern;
static int always;
@@ -38,7 +38,7 @@ static const char *diff_index_args[] = {
struct commit_name {
- struct commit_name *next;
+ hashmap_entry entry;
unsigned char peeled[20];
struct tag *tag;
unsigned prio:2; /* annotated tag = 2, tag = 1, head = 0 */
@@ -50,6 +50,11 @@ static const char *prio_names[] = {
"head", "lightweight", "annotated",
};
+static int commit_name_cmp(struct commit_name *cn1, struct commit_name *cn2)
+{
+ return hashcmp(cn1->peeled, cn2->peeled);
+}
+
static inline unsigned int hash_sha1(const unsigned char *sha1)
{
unsigned int hash;
@@ -59,21 +64,10 @@ static inline unsigned int hash_sha1(const unsigned char
*sha1)
static inline struct commit_name *find_commit_name(const unsigned char *peeled)
{
- struct commit_name *n = lookup_hash(hash_sha1(peeled), &names);
- while (n && !!hashcmp(peeled, n->peeled))
- n = n->next;
- return n;
-}
-
-static int set_util(void *chain, void *data)
-{
- struct commit_name *n;
- for (n = chain; n; n = n->next) {
- struct commit *c = lookup_commit_reference_gently(n->peeled, 1);
- if (c)
- c->util = n;
- }
- return 0;
+ struct commit_name key;
+ hashmap_entry_init(&key, hash_sha1(peeled), 0);
+ hashcpy(key.peeled, peeled);
+ return hashmap_get(&names, &key);
}
static int replace_name(struct commit_name *e,
@@ -118,16 +112,10 @@ static void add_to_known_names(const char *path,
struct tag *tag = NULL;
if (replace_name(e, prio, sha1, &tag)) {
if (!e) {
- void **pos;
e = xmalloc(sizeof(struct commit_name));
hashcpy(e->peeled, peeled);
- pos = insert_hash(hash_sha1(peeled), e, &names);
- if (pos) {
- e->next = *pos;
- *pos = e;
- } else {
- e->next = NULL;
- }
+ hashmap_entry_init(e, hash_sha1(peeled), 0);
+ hashmap_add(&names, e);
e->path = NULL;
}
e->tag = tag;
@@ -292,7 +280,14 @@ static void describe(const char *arg, int last_one)
fprintf(stderr, _("searching to describe %s\n"), arg);
if (!have_util) {
- for_each_hash(&names, set_util, NULL);
+ hashmap_iter iter;
+ struct commit *c;
+ struct commit_name *n = hashmap_iter_first(&names, &iter);
+ for (; n; n = hashmap_iter_next(&iter)) {
+ c = lookup_commit_reference_gently(n->peeled, 1);
+ if (c)
+ c->util = n;
+ }
have_util = 1;
}
@@ -463,9 +458,9 @@ int cmd_describe(int argc, const char **argv, const char
*prefix)
return cmd_name_rev(args.argc, args.argv, prefix);
}
- init_hash(&names);
+ hashmap_init(&names, (hashmap_cmp_fn) commit_name_cmp, 0);
for_each_rawref(get_name, NULL);
- if (!names.nr && !always)
+ if (!names.size && !always)
die(_("No names found, cannot describe anything."));
if (argc == 0) {
--
1.8.4.8243.gbcbdefd
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH/RFC 1/5] add a hashtable implementation that supports O(1) removal
The existing hashtable implementation (in hash.[ch]) uses open addressing
(i.e. resolve hash collisions by distributing entries across the table).
Thus, removal is difficult to implement with less than O(n) complexity.
Resolving collisions of entries with identical hashes (e.g. via chaining)
is left to the client code.
Add a hashtable implementation that supports O(1) removal and is slightly
easier to use due to builtin entry chaining.
Supports all basic operations init, free, get, add, remove and iteration.
Also includes ready-to-use hash functions based on the public domain FNV-1
algorithm (http://www.isthe.com/chongo/tech/comp/fnv).
The per-entry data structure (hashmap_entry) is meant to be piggybacked
in front of the client's data structure to save memory. See test-hashmap.c
for usage examples.
The hashtable is resized by a factor of four when 80% full. With these
settings, average memory consumption is about 2/3 of hash.[ch], and
insertion is about twice as fast due to less frequent resizing.
Signed-off-by: Karsten Blees
---
Makefile | 3 +
hashmap.c | 210 +++
hashmap.h | 200 +
t/t0011-hashmap.sh | 236
test-hashmap.c | 258 +
5 files changed, 907 insertions(+)
create mode 100644 hashmap.c
create mode 100644 hashmap.h
create mode 100755 t/t0011-hashmap.sh
create mode 100644 test-hashmap.c
diff --git a/Makefile b/Makefile
index 3588ca1..e6ad011 100644
--- a/Makefile
+++ b/Makefile
@@ -562,6 +562,7 @@ TEST_PROGRAMS_NEED_X += test-date
TEST_PROGRAMS_NEED_X += test-delta
TEST_PROGRAMS_NEED_X += test-dump-cache-tree
TEST_PROGRAMS_NEED_X += test-genrandom
+TEST_PROGRAMS_NEED_X += test-hashmap
TEST_PROGRAMS_NEED_X += test-index-version
TEST_PROGRAMS_NEED_X += test-line-buffer
TEST_PROGRAMS_NEED_X += test-match-trees
@@ -681,6 +682,7 @@ LIB_H += gpg-interface.h
LIB_H += graph.h
LIB_H += grep.h
LIB_H += hash.h
+LIB_H += hashmap.h
LIB_H += help.h
LIB_H += http.h
LIB_H += kwset.h
@@ -811,6 +813,7 @@ LIB_OBJS += gpg-interface.o
LIB_OBJS += graph.o
LIB_OBJS += grep.o
LIB_OBJS += hash.o
+LIB_OBJS += hashmap.o
LIB_OBJS += help.o
LIB_OBJS += hex.o
LIB_OBJS += ident.o
diff --git a/hashmap.c b/hashmap.c
new file mode 100644
index 000..686ee6f
--- /dev/null
+++ b/hashmap.c
@@ -0,0 +1,210 @@
+/*
+ * Generic implementation of hash-based key value mappings.
+ */
+#include "cache.h"
+#include "hashmap.h"
+
+#define FNV32_BASE ((unsigned int) 0x811c9dc5)
+#define FNV32_PRIME ((unsigned int) 0x01000193)
+
+unsigned int strhash(const char *str)
+{
+ unsigned int c, hash = FNV32_BASE;
+ while ((c = (unsigned char) *str++))
+ hash = (hash * FNV32_PRIME) ^ c;
+ return hash;
+}
+
+unsigned int strihash(const char *str)
+{
+ unsigned int c, hash = FNV32_BASE;
+ while ((c = (unsigned char) *str++)) {
+ if (c >= 'a' && c <= 'z')
+ c -= 'a' - 'A';
+ hash = (hash * FNV32_PRIME) ^ c;
+ }
+ return hash;
+}
+
+unsigned int memhash(const void *buf, size_t len)
+{
+ unsigned int hash = FNV32_BASE;
+ unsigned char *ucbuf = (unsigned char*) buf;
+ while (len--) {
+ unsigned int c = *ucbuf++;
+ hash = (hash * FNV32_PRIME) ^ c;
+ }
+ return hash;
+}
+
+unsigned int memihash(const void *buf, size_t len)
+{
+ unsigned int hash = FNV32_BASE;
+ unsigned char *ucbuf = (unsigned char*) buf;
+ while (len--) {
+ unsigned int c = *ucbuf++;
+ if (c >= 'a' && c <= 'z')
+ c -= 'a' - 'A';
+ hash = (hash * FNV32_PRIME) ^ c;
+ }
+ return hash;
+}
+
+#define HASHMAP_INITIAL_SIZE 64
+/* grow / shrink by 2^2 */
+#define HASHMAP_GROW 2
+/* grow if > 80% full (to 20%) */
+#define HASHMAP_GROW_AT 1.25
+/* shrink if < 16.6% full (to 66.6%) */
+#define HASHMAP_SHRINK_AT 6
+
+static inline int entry_equals(const hashmap *map, const hashmap_entry *e1,
+ const hashmap_entry *e2)
+{
+ return (e1 == e2) || (e1->hash == e2->hash && !(*map->cmpfn)(e1, e2));
+}
+
+static inline unsigned int bucket(const hashmap *map, const hashmap_entry *key)
+{
+ return key->hash & (map->tablesize - 1);
+}
+
+static void rehash(hashmap *map, unsigned int newsize)
+{
+ unsigned int i, oldsize = map->tablesize;
+ hashmap_entry **oldtable = map->table;
+
+ map->tablesize = newsize;
+ map->table = xcalloc(sizeof(hashmap_entry*), map->tablesize);
+ for (i = 0; i < oldsize; i++) {
+ hashmap_entry *e = oldtable[i];
+ while (e) {
+ hashmap_entry *next = e->next;
+ unsigned int b = bucket(map, e);
+ e->next = map->table[b];
+ map
[PATCH/RFC 0/5] New hash table implementation
Also here: https://github.com/kblees/git/tree/kb/hashmap Hi, this is a spin-off of my (very slowly progressing) msysgit fscache project. I needed to remove things from the hash table, which cannot be implemented efficiently in hash.[ch]. So I wrote hasmap.[ch], with these features: - O(1) remove - builtin entry chaining - ready-to-use FNV-1 hash functions - unit test - additions are ~twice as fast - uses less memory Patches 2 and 5 convert existing uses of hash.[ch] to hashmap.[ch]. Patches 3 and 4 are useful optimizations of their own. I haven't found the time to tackle name-hash.c yet, this is where remove() could come into play (to replace the CE_UNHASHED flag). Karsten Karsten Blees (5): add a hashtable implementation that supports O(1) removal buitin/describe.c: use new hash map implementation diffcore-rename.c: move code around to prepare for the next patch diffcore-rename.c: simplify finding exact renames diffcore-rename.c: use new hash map implementation Makefile | 3 + builtin/describe.c | 53 +-- diffcore-rename.c | 185 +- hashmap.c | 210 +++ hashmap.h | 200 + t/t0011-hashmap.sh | 236 test-hashmap.c | 258 + 7 files changed, 995 insertions(+), 150 deletions(-) create mode 100644 hashmap.c create mode 100644 hashmap.h create mode 100755 t/t0011-hashmap.sh create mode 100644 test-hashmap.c -- 1.8.4.8243.gbcbdefd -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] MSVC: fix stat definition hell
In msvc.h, there's a couple of stat related functions defined diffently from mingw.h. When we remove these definitions, the only problem we get is "warning C4005: '_stati64' : macro redefinition" for this line in mingw.h: #define _stati64(x,y) mingw_stat(x,y) The reason is that as of MSVCR80.dll (distributed with MSVC 2005), the original _stati64 family of functions was renamed to _stat32i64, and the former function names became macros (pointing to the appropriate function based on the definition of _USE_32BIT_TIME_T). Defining _stati64 works on MinGW because MinGW by default compiles against the MSVCRT.DLL that is part of Windows (i.e. _stati64 is a function rather than a macro). Note: MinGW *can* compile for newer MSVC runtime versions, and MSVC apparently can also compile for the Windows MSVCRT.DLL via the DDK (see http://www.syndicateofideas.com/posts/fighting-the-msvcrt-dll-hell ). Remove the stat definitions from msvc.h, as they are not compiler related. In mingw.h, determine the runtime version in use from the definitions of _stati64 and _USE_32BIT_TIME_T, and define stat() accordingly. This also fixes that stat() in MSVC builds still resolves to mingw_lstat() instead of mingw_stat(). Signed-off-by: Karsten Blees --- compat/mingw.h | 15 +++ compat/msvc.h | 15 --- 2 files changed, 11 insertions(+), 19 deletions(-) diff --git a/compat/mingw.h b/compat/mingw.h index 6b531e4..3c3a9d9 100644 --- a/compat/mingw.h +++ b/compat/mingw.h @@ -264,19 +264,26 @@ static inline int getrlimit(int resource, struct rlimit *rlp) return 0; } -/* Use mingw_lstat() instead of lstat()/stat() and - * mingw_fstat() instead of fstat() on Windows. +/* + * Use mingw specific stat()/lstat()/fstat() implementations on Windows. */ #define off_t off64_t #define lseek _lseeki64 -#ifndef ALREADY_DECLARED_STAT_FUNCS + +/* use struct stat with 64 bit st_size */ #define stat _stati64 int mingw_lstat(const char *file_name, struct stat *buf); int mingw_stat(const char *file_name, struct stat *buf); int mingw_fstat(int fd, struct stat *buf); #define fstat mingw_fstat #define lstat mingw_lstat -#define _stati64(x,y) mingw_stat(x,y) + +#ifndef _stati64 +# define _stati64(x,y) mingw_stat(x,y) +#elif defined (_USE_32BIT_TIME_T) +# define _stat32i64(x,y) mingw_stat(x,y) +#else +# define _stat64(x,y) mingw_stat(x,y) #endif int mingw_utime(const char *file_name, const struct utimbuf *times); diff --git a/compat/msvc.h b/compat/msvc.h index 96b6d60..580bb55 100644 --- a/compat/msvc.h +++ b/compat/msvc.h @@ -24,21 +24,6 @@ static __inline int strcasecmp (const char *s1, const char *s2) #undef ERROR -/* Use mingw_lstat() instead of lstat()/stat() and mingw_fstat() instead - * of fstat(). We add the declaration of these functions here, suppressing - * the corresponding declarations in mingw.h, so that we can use the - * appropriate structure type (and function) names from the msvc headers. - */ -#define stat _stat64 -int mingw_lstat(const char *file_name, struct stat *buf); -int mingw_fstat(int fd, struct stat *buf); -#define fstat mingw_fstat -#define lstat mingw_lstat -#define _stat64(x,y) mingw_lstat(x,y) -#define ALREADY_DECLARED_STAT_FUNCS - #include "compat/mingw.h" -#undef ALREADY_DECLARED_STAT_FUNCS - #endif -- 1.8.4.8243.gbcbdefd -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] MSVC: fix compile errors due to macro redefinitions
Skip errno.h definitions if they are already defined.
Signed-off-by: Karsten Blees
---
compat/mingw.h | 6 ++
1 file changed, 6 insertions(+)
diff --git a/compat/mingw.h b/compat/mingw.h
index bd0a88b..6b531e4 100644
--- a/compat/mingw.h
+++ b/compat/mingw.h
@@ -32,7 +32,9 @@ typedef int socklen_t;
#define WEXITSTATUS(x) ((x) & 0xff)
#define WTERMSIG(x) SIGTERM
+#ifndef EWOULDBLOCK
#define EWOULDBLOCK EAGAIN
+#endif
#define SHUT_WR SD_SEND
#define SIGHUP 1
@@ -46,8 +48,12 @@ typedef int socklen_t;
#define F_SETFD 2
#define FD_CLOEXEC 0x1
+#ifndef EAFNOSUPPORT
#define EAFNOSUPPORT WSAEAFNOSUPPORT
+#endif
+#ifndef ECONNABORTED
#define ECONNABORTED WSAECONNABORTED
+#endif
struct passwd {
char *pw_name;
--
1.8.4.8243.gbcbdefd
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] MSVC: fix compile errors due to missing libintl.h
Set NO_GETTEXT in config.mak.uname to get rid of libintl.h dependency. Signed-off-by: Karsten Blees --- config.mak.uname | 1 + 1 file changed, 1 insertion(+) diff --git a/config.mak.uname b/config.mak.uname index b27f51d..64b7f49 100644 --- a/config.mak.uname +++ b/config.mak.uname @@ -340,6 +340,7 @@ ifeq ($(uname_S),Windows) OBJECT_CREATION_USES_RENAMES = UnfortunatelyNeedsTo NO_REGEX = YesPlease NO_CURL = YesPlease + NO_GETTEXT = YesPlease NO_PYTHON = YesPlease BLK_SHA1 = YesPlease ETAGS_TARGET = ETAGS -- 1.8.4.8243.gbcbdefd -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/3] Fix MSVC compile errors and cleanup stat definitions
A few minor fixes for the MSVC build. Also here: https://github.com/kblees/git/tree/kb/fix-msvc-stat-definitions Karsten Blees (3): MSVC: fix compile errors due to missing libintl.h MSVC: fix compile errors due to macro redefinitions MSVC: fix stat definition hell compat/mingw.h | 21 + compat/msvc.h| 15 --- config.mak.uname | 1 + 3 files changed, 18 insertions(+), 19 deletions(-) -- 1.8.4.8243.gbcbdefd -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH-v3] Allow git-filter-branch to process large repositories with lots of branches.
Lee Carver writes: > As noted in several forums, a recommended way to move trees between > repositories > is to use git-filter-branch to revise the history for a single tree: > > http://gbayer.com/development/moving-files-from-one-git-repository-to-anoth > er-preserving-history/ > http://stackoverflow.com/questions/1365541/how-to-move-files-from-one-git-r > epo-to-another-not-a-clone-preserving-history > > However, this can lead to argument list too long errors when the original > repository has many retained branches (>6k) > > /usr/local/git/libexec/git-core/git-filter-branch: line 270: > /usr/local/git/libexec/git-core/git: Argument list too long > Could not get the commits > > Piping the saved output from git rev-parse into git rev-list avoids this > problem, since the rev-parse output is not processed as a command line > argument. > --- > git-filter-branch.sh | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/git-filter-branch.sh b/git-filter-branch.sh > index ac2a005..2091885 100755 > --- a/git-filter-branch.shgit > +++ b/git-filter-branch.sh > @@ -255,7 +255,7 @@ else > remap_to_ancestor=t > fi > > -rev_args=$(git rev-parse --revs-only "$@") > +git rev-parse --revs-only "$@" > ../parse Where is this "rev-parse" command running? Is it always safe to clobber the file "../parse" like this? > > case "$filter_subdir" in > "") > @@ -268,7 +268,7 @@ case "$filter_subdir" in > esac > > git rev-list --reverse --topo-order --default HEAD \ > - --parents --simplify-merges $rev_args "$@" > ../revs || > + --parents --simplify-merges --stdin "$@" < ../parse > ../revs || > die "Could not get the commits" > commits=$(wc -l <../revs | tr -d " ") -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 7/8] update-ref: support multiple simultaneous updates
On Mon, Sep 9, 2013 at 8:57 PM, Brad King wrote: > diff --git a/Documentation/git-update-ref.txt > b/Documentation/git-update-ref.txt > index 0df13ff..0a0a551 100644 > --- a/Documentation/git-update-ref.txt > +++ b/Documentation/git-update-ref.txt > @@ -58,6 +58,58 @@ archive by creating a symlink tree). > +option:: > + Modify behavior of the next command naming a . > + The only valid option is `no-deref` to avoid dereferencing > + a symbolic ref. > + > +Use 40 "0" or the empty string to specify a zero value, except that Did you want an 's' after the "0"? 0's "0"s "0"'s zeros zeroes > +with `-z` an empty is considered missing. > + > +If all s can be locked with matching s > +simultaneously, all modifications are performed. Otherwise, no > +modifications are performed. Note that while each individual > + is updated or deleted atomically, a concurrent reader may > +still see a subset of the modifications. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH-v3] Allow git-filter-branch to process large repositories with lots of branches.
As noted in several forums, a recommended way to move trees between repositories is to use git-filter-branch to revise the history for a single tree: http://gbayer.com/development/moving-files-from-one-git-repository-to-anoth er-preserving-history/ http://stackoverflow.com/questions/1365541/how-to-move-files-from-one-git-r epo-to-another-not-a-clone-preserving-history However, this can lead to argument list too long errors when the original repository has many retained branches (>6k) /usr/local/git/libexec/git-core/git-filter-branch: line 270: /usr/local/git/libexec/git-core/git: Argument list too long Could not get the commits Piping the saved output from git rev-parse into git rev-list avoids this problem, since the rev-parse output is not processed as a command line argument. --- git-filter-branch.sh | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/git-filter-branch.sh b/git-filter-branch.sh index ac2a005..2091885 100755 --- a/git-filter-branch.shgit +++ b/git-filter-branch.sh @@ -255,7 +255,7 @@ else remap_to_ancestor=t fi -rev_args=$(git rev-parse --revs-only "$@") +git rev-parse --revs-only "$@" > ../parse case "$filter_subdir" in "") @@ -268,7 +268,7 @@ case "$filter_subdir" in esac git rev-list --reverse --topo-order --default HEAD \ - --parents --simplify-merges $rev_args "$@" > ../revs || + --parents --simplify-merges --stdin "$@" < ../parse > ../revs || die "Could not get the commits" commits=$(wc -l <../revs | tr -d " ") -- 1.8.3.2 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: breakage in revision traversal with pathspec
On 10/09/2013 20:19, Junio C Hamano wrote: I am grumpy X-<. It appears that we introduced a large breakage during 1.8.4 cycle to the revision traversal machinery and made pathspec-limited "git log" pretty much useless. This command $ git log v1.8.3.1..v1.8.4 -- git-cvsserver.perl reports that a merge 766f0f8ef7 (which did not touch the specified path at all) touches it. Bisecting points at d0af663e (revision.c: Make --full-history consider more merges, 2013-05-16). That merge appearing *with* --full-history would seem like correct behaviour to me. Or at least it's what I intended. That merge *did* touch that path - that file differs between the two parents, and it resolved on one of them. This goes back to my original motivation for the change - the ability to find merges that resolved in unexpected ways - I want "--full-history" to show every merge where the end result is not identical to every parent. This does mean that "--full-history" will show more merges than it used to for a pathspec - it will show merges in from topic branches which didn't touch that pathspec, but where the mainline did change it. These extra merges can be pared back by "--simplify-merges", which will generally eliminate any irrelevant topic branches, although not for topic branches that are rooted older than your bottom commit, like in this example. However, your particular example occurs *without*--full-history, which suggests a problem. That merge is right near the bottom of the range. Its first parent is v1.8.3. It has an incoming pre-1.8.3 topic branch (fc/transport-helper-error-reporting) with an old version of git-cvsserver.perl (which the merge correctly didn't take). Display of that sort of bottom-of-range merge is a problem area I did try to address - it was problematic in older Git versions, but that problem was partially concealed by the overly-permissive "hide any merge identical to any one parent" logic, and became more exposed by my "show more merges". I'm pretty certain non-full "git log v1.8.3..v1.8.4" shouldn't show that merge. And indeed it doesn't. Yay! At this point the various "follow first parent if identical", "prioritise on-graph treesame" and "treat bottom commits as on-graph" rules are working. That merge is identical to v1.8.3, its first parent, and we've expressed an interest in v1.8.3, so that's treated as on-graph, so it doesn't get shown. (Oddly, "gitk v1.8.3..v1.8.4" fails and shows the merge. It seems gitk fails here because of the annotated tag: "gitk v1.8.3^0..v1.8.4" correctly shows nothing. So one apparent "failure to peel" bug somewhere. Can't seem to provoke this with git log.) "git log v1.8.3.1..v1.8.4" on the other hand I'm not so sure about. The "follow first treesame parent" logic doesn't kick in because the merge's only treesame parent (v1.8.3) is off-graph. The merge is not treesame to its only on-graph parent (fc/transport-helper-error-reporting), so that "default following" rule doesn't activate. I'm going to have to think a bit. "git log (--ancestry-path?) fc/transport-helper-error-reporting..v1.8.4" should definitely show that merge - we want to see how we got from the version of the file on the specified topic branch to the different version in v1.8.4. Maybe if the first-treesame-parent rule was reapplied again later after rewriting? After we've pruned away the topic branch by rewriting because its commits don't touch the pathspec, then our merge is left with two off-graph rewritten parents. At which point maybe it would be reasonable for the default log to reapply the "follow first treesame parent" rule if all remaining parents are off-graph. Does that make sense? Going to have to think harder. I note that "gitk v1.8.3^0..v1.8.4" and "git log --parents v1.8.3..v1.8.4" show that merge in Git 1.8.3, but not in Git 1.8.4. So we're going partially forwards, at least. Kevin -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 8/8] update-ref: add test cases covering --stdin signature
Eric Sunshine writes: > Thus printf provides all the functionality you require, and > print_nul() function can be dropped. So: > > printf '%s\0' foo bar baz > > is equivalent to: > > print_null foo bar baz Good eyes. Thanks, I missed them when I looked at the patches. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 8/8] update-ref: add test cases covering --stdin signature
On Mon, Sep 9, 2013 at 8:57 PM, Brad King wrote:
> Extend t/t1400-update-ref.sh to cover cases using the --stdin option.
>
> Signed-off-by: Brad King
> ---
> t/t1400-update-ref.sh | 639
> ++
> 1 file changed, 639 insertions(+)
>
> diff --git a/t/t1400-update-ref.sh b/t/t1400-update-ref.sh
> index e415ee0..a510500 100755
> --- a/t/t1400-update-ref.sh
> +++ b/t/t1400-update-ref.sh
> @@ -302,4 +302,643 @@ test_expect_success \
> 'git cat-file blob master@{2005-05-26 23:42}:F (expect OTHER)' \
> 'test OTHER = $(git cat-file blob "master@{2005-05-26 23:42}:F")'
>
> +a=refs/heads/a
> +b=refs/heads/b
> +c=refs/heads/c
> +E='""'
> +pws='path with space'
> +
> +print_nul() {
> + while test $# -gt 0; do
> + printf -- "$1" &&
> + printf -- "Q" | q_to_nul &&
> + shift || return
> + done
> +}
I believe that current fashion in git test scripts is to add a space
before () in the function declaration. Likewise, the 'do' should be on
the line following 'while' and aligned with 'while' (and drop the
semicolon).
The '--' option to printf is not likely portable. POSIX [1] certainly
does not mention it.
You can get printf to emit a NUL more naturally via \0, so q_to_nul is
unnecessary.
Finally, printf reuses its 'format' argument as many times as needed
to output all arguments, so the while loop is unneeded.
Thus printf provides all the functionality you require, and
print_nul() function can be dropped. So:
printf '%s\0' foo bar baz
is equivalent to:
print_null foo bar baz
[1]: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/printf.html
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git-cvsserver strips exec bit
Michael Cronenworth writes:
> Michael Cronenworth wrote:
>> This fix is close. Now all files are checked out with a mask of 555.
>
> Let me clarify.
>
> Git mask 755 => CVS mask 555
> Git mask 644 => CVS mask 444
>
> Thanks,
> Michael
Then what I wrote was actually relevant ;-)
I am not sure if we want to use the owner bit (i.e. 4th place)
instead of the other bit (i.e. the last place) like this patch does,
though. The old code in 1.8.1.x would have produced either "r" (for
100644) or "wx" (for 100755); I think that the result of applying
this patch would give us "r" (for 100644) or "rx" (for 100755).
This should then work, I would think.
-- >8 --
Subject: [PATCH v2] cvsserver: pick up the right mode bits
When determining the file mode from either ls-tree or diff-tree
output, we used to grab these octal mode string (typically 100644 or
100755) and then did
$git_perms .= "r" if ( $mode & 4 );
$git_perms .= "w" if ( $mode & 2 );
$git_perms .= "x" if ( $mode & 1 );
which was already wrong, as (100644 & 4) is very different from
oct("100644") & 4. An earlier refactoring 2c3af7e7 (cvsserver:
factor out git-log parsing logic, 2012-10-13) further changed it to
pick the third octal digit (10*0*644 or 10*0*755) from the left and
then do the above conversion, which does not make sense, either.
Let's use the third digit from the last of the octal mode string to
make sure we get the executable and read bits right.
Signed-off-by: Junio C Hamano
---
git-cvsserver.perl | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/git-cvsserver.perl b/git-cvsserver.perl
index a0d796e..67b1e7b 100755
--- a/git-cvsserver.perl
+++ b/git-cvsserver.perl
@@ -4167,7 +4167,7 @@ sub convertToDbMode
# this half-converted form, but it isn't currently worth the
# backwards compatibility headaches.
-$mode=~/^\d\d(\d)\d{3}$/;
+$mode=~/^\d{3}(\d)\d\d$/;
my $userBits=$1;
my $dbMode = "";
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL REQUEST] initial pack v4 support
On Tue, 10 Sep 2013, Junio C Hamano wrote:
> > packv4-parse.c: allow tree entry copying from a canonical tree object
>
> This one needed a small fix-up to make it compile.
>
> I do not particularly like reusing that "size" variable, but it
> seemed to be dead at that point, so...
>
> packv4-parse.c | 9 +
> 1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/packv4-parse.c b/packv4-parse.c
> index f96acc1..3f95ed4 100644
> --- a/packv4-parse.c
> +++ b/packv4-parse.c
> @@ -365,13 +365,14 @@ static int copy_canonical_tree_entries(struct
> packed_git *p, off_t offset,
> update_tree_entry(&desc);
> end = desc.buffer;
>
> - if (end - from > *sizep) {
> + size = (const char *)end - (const char *)from;
> + if (size > *sizep) {
BTW, a simpler fix might simply involve declaring those 2 variables as
const char * up front which would remove the need for any cast.
Nicolas
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] lookup_object: remove hashtable_index() and optimize hash_obj()
hashtable_index() appears to be a close duplicate of hash_obj().
Keep only the later and make it usable for all cases.
Also remove the modulus as this is an expansive operation.
The size argument is always a power of 2 anyway, so a simple
mask operation provides the same result.
On a 'git rev-list --all --objects' run this decreased the time spent
in lookup_object from 27.5% to 24.1%.
Signed-off-by: Nicolas Pitre
---
I discovered this patch in my git work tree dating from 2 years ago.
diff --git a/object.c b/object.c
index d8a4b1f..e2dae22 100644
--- a/object.c
+++ b/object.c
@@ -43,16 +43,16 @@ int type_from_string(const char *str)
die("invalid object type \"%s\"", str);
}
-static unsigned int hash_obj(struct object *obj, unsigned int n)
+static unsigned int hash_obj(const unsigned char *sha1, unsigned int n)
{
unsigned int hash;
- memcpy(&hash, obj->sha1, sizeof(unsigned int));
- return hash % n;
+ memcpy(&hash, sha1, sizeof(unsigned int));
+ return hash & (n - 1);
}
static void insert_obj_hash(struct object *obj, struct object **hash, unsigned
int size)
{
- unsigned int j = hash_obj(obj, size);
+ unsigned int j = hash_obj(obj->sha1, size);
while (hash[j]) {
j++;
@@ -62,13 +62,6 @@ static void insert_obj_hash(struct object *obj, struct
object **hash, unsigned i
hash[j] = obj;
}
-static unsigned int hashtable_index(const unsigned char *sha1)
-{
- unsigned int i;
- memcpy(&i, sha1, sizeof(unsigned int));
- return i % obj_hash_size;
-}
-
struct object *lookup_object(const unsigned char *sha1)
{
unsigned int i, first;
@@ -77,7 +70,7 @@ struct object *lookup_object(const unsigned char *sha1)
if (!obj_hash)
return NULL;
- first = i = hashtable_index(sha1);
+ first = i = hash_obj(sha1, obj_hash_size);
while ((obj = obj_hash[i]) != NULL) {
if (!hashcmp(sha1, obj->sha1))
break;
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 2/2] Add new @ shortcut for HEAD
Junio C Hamano writes:
> Felipe Contreras writes:
>
>>> Hmph, is the above sufficient? I added a case that mimics Stefano's
>>> original regression report (which is handled) and another that uses
>>> doubled "@" for the same purpose of introducing a "funny" hierarchy,
>>> and it appears that "checkout -b" chokes on it.
>>
>> This fixes it:
>>
>> --- a/sha1_name.c
>> +++ b/sha1_name.c
>> @@ -1014,6 +1014,8 @@ static int interpret_empty_at(const char *name,
>> int namelen, int len, struct str
>>
>> /* make sure it's a single @, or @@{.*}, not @foo */
>> next = strchr(name + len + 1, '@');
>> + if (next && next[1] != '{')
>> + return -1;
>> if (!next)
>> next = name + namelen;
>> if (next != name + 1)
>
> I think this should be sufficient for all cases, as the sequence
> "@{" cannot be a part of valid reference names.
>
> Thanks.
>
> I see v6 was posted yesterday after this message, but it does not
> seem to have this fix, nor the additional test case I gave you in
> the message upthread. Sent a wrong version of patch by mistake?
Ping?
I could squash the fixup at the tip of on fc/at-head in if you want
me to, but v6 seems to be a mistake to me.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] Reject non-ff pulls by default
Matthieu Moy writes: > Junio C Hamano writes: > >> You are in favor of an _option_ to allow people to forbid a pull in >> a non-ff situation, and I think other people are also in >> agreement. > > Yes. Having an option can't harm anybody, and there's a clear demand for > that. > >> So perhaps: >> >> - drop jc/pull-training-wheel and revert its merge from 'next'; >> >> - update Felipe's series with a bit of tweak to make it less >>impactful by demoting error into warning and advice. >> >> would be a good way forward? > > I didn't follow very closely the discussions and patch series, but that > would sound right to me. The last version of Felipes' patch series > already gives a warning only, but the wording and commit message implies > that this will become an error in the future (this is the part with > which I disagree). OK, the first step to drop jc/pull-training-wheel from 'next' has been done. I _think_ the one that starts at $gmane/234295 is the newer incarnation of the patches in this thread, but that seems to do a lot more than what the patches in this thread did, and it also badly interacts with another topic in flight that updates git-pull, so I have a topic branch for it but haven't merged to 'pu' yet. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] remote-bzr: reuse bzrlib transports when possible
Junio C Hamano writes:
> Richard Hansen writes:
>
>> def do_export(parser):
>> -global parsed_refs, dirname
>> +global parsed_refs, dirname, transports
>
> As this has been acked by Felipe who knows the script the best, I'll
> apply this directly to 'master'.
>
> These additions of "global transports" however have trivial
> interactions with fc/contrib-bzr-hg-fixes topic Felipe posted
> earlier, which I was planning to start merging down to 'next' and
> then to 'master'. Most funcions merely use the variable without
> assigning, so "global transports" can be removed, in line with the
> spirit of 641a2b5b (remote-helpers: cleanup more global variables,
> 2013-08-28), except for the obvious initialisation in main(), I
> think. Please double check the conflict resolution result in a
> commit on 'pu' with
>
> git show 'origin/pu^{/Merge fc/contrib-bzr}'
>
> when I push the result out.
>
> Thanks.
Ping? I'd like to merge fc/contrib-bzr.hg-fixes topic to 'next'
(and fast track it to 'master' after that), and it would be helpful
to get an Ack on the conflict resolution I have.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: breakage in revision traversal with pathspec
Kevin Bracey writes: > On 10/09/2013 20:19, Junio C Hamano wrote: >> I am grumpy X-<. >> >> It appears that we introduced a large breakage during 1.8.4 cycle to >> the revision traversal machinery and made pathspec-limited "git log" >> pretty much useless. >> >> This command >> >> $ git log v1.8.3.1..v1.8.4 -- git-cvsserver.perl >> >> reports that a merge 766f0f8ef7 (which did not touch the specified >> path at all) touches it. >> >> Bisecting points at d0af663e (revision.c: Make --full-history >> consider more merges, 2013-05-16). >> > That merge appearing *with* --full-history would seem like correct > behaviour to me. Or at least it's what I intended. Oh, of course. "--full-history" is about showing any pointless change, "the mainline was a lot more up-to-date and there were changes relative to a fork based on an older baseline", so your updated "log" should show that in the mainline git-cvsserver.perl has been more fresh when that merge happened. But it shouldn't appear if the user does not ask for "--full-history". > However, your particular example occurs *without*--full-history, which > suggests a problem. Yes. > I note that "gitk v1.8.3^0..v1.8.4" and "git log --parents > v1.8.3..v1.8.4" show that merge in Git 1.8.3, but not in Git 1.8.4. So > we're going partially forwards, at least. With the testcases demonstrating the cases your series fixed that all look sensible, I think it is not really an option for us to revert them; you do not have to defend it with "we are going partially forwards" ;-). -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git-cvsserver strips exec bit
Michael Cronenworth wrote: This fix is close. Now all files are checked out with a mask of 555. Let me clarify. Git mask 755 => CVS mask 555 Git mask 644 => CVS mask 444 Thanks, Michael -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL REQUEST] initial pack v4 support
Nicolas Pitre writes: > On Tue, 10 Sep 2013, Junio C Hamano wrote: > >> Nicolas Pitre writes: >> >> > Junio, would you please pull the following into pu: >> > >> >git://git.linaro.org/people/nico/git >> > >> > This is the pack v4 work to date which is somewhat getting usable. It >> > is time it gets more exposure, and possibly some more people's attention >> > who would like to work on the missing parts as I need to scale down my >> > own involvement. >> >> Thanks. Parked on 'pu'. > > Good. > >> > packv4-parse.c: allow tree entry copying from a canonical tree object >> >> This one needed a small fix-up to make it compile. >> >> I do not particularly like reusing that "size" variable, but it >> seemed to be dead at that point, so... > > Feel free to fold this in the original commit. > > I'm curious... what compiler are you using? My gcc version is just > happy to do arithmetic on void pointers. I have -Werror -Wpointer-arith -Woverflow -Wno-pointer-to-int-cast defined in my private build script (the todo branch is checked out as Meta/ subdirectory of git.git, and "Meta/Make --pedantic" is how I build things). -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Regression in e02ca72: git svn rebase is broken on Windows
Junio C Hamano pobox.com> writes: > > Tvangeste yandex.ru> writes: > > > Hi, > > > > After bisecting this problem I ended up with the mentioned commit that completely breaks git-svn for me on > Windows (mingw/msys version). > > > > == > > #> git svn rebase > > warning: unable to access '': Invalid argument > > warning: unable to access '': Invalid argument > > fatal: unable to access '../../../../w:/work/my/repo.git/.git/config': Invalid argument > > fatal: index file open failed: Invalid argument > > Cannot rebase: You have unstaged changes. > > Please commit or stash them. > > rebase refs/remotes/trunk: command returned error: 1 > > == > > > > Please note that I use the official git repository as-is, this one (no additional patches): > > git://git.kernel.org/pub/scm/git/git.git > > > > e02ca72f70ed8f0268a81f72cb3230c72e538e77 is the first bad commit > > commit e02ca72f70ed8f0268a81f72cb3230c72e538e77 > > Author: Jiang Xin > > Date: Tue Jun 25 23:53:43 2013 +0800 > > > > path.c: refactor relative_path(), not only strip prefix > > > > Thanks, > > --Tvangeste > > The suspect commit and symptom look consistent. You started from a > directory whose absolute path is "w:/work/..." and the updated code > mistakenly thoguht that something that begins with "w" (not '/') is > not an absolute, so added a series of ../ to make it relative, or > something silly like that. > > Jiang? > Indeed, this patch seems to change relative_path in a way that breaks git initialization, not just on Windows. Previously, relative_path was always called with two absolute paths, and it only returned a relative path if the first was a subdir of the second (so a better name would probably have been 'relative_path_if_subdir'). The purpose was to improve performance by making GIT_DIR shorter if it was a subdir of GIT_WORK_TREE. After this patch, relative_path always tries to return a relative path, even if both absolute paths are completely disjunct. This not only defeats the purpose (by making GIT_DIR longer, thus hurting performance), it is also not possible in general. POSIX explicitly allows for '//hostname' notation referring to network resources that are not explicitly mounted under '/'. I.e. given two absolute paths '//hostname1/a' and '//hostname2/b', there is no relative path from a to b or vice versa. Additionally, GIT_DIR now may or may not have a trailing slash, which gives me a slightly uneasy feeling... -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git-cvsserver strips exec bit
Junio C Hamano wrote: I stopped interacting with CVS quite a long time ago, so I do not have any way of verifying, but the fix may be just the matter of something like this. This fix is close. Now all files are checked out with a mask of 555. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/5] pull: rename pull.rename to pull.mode
Felipe Contreras writes: > Also 'branch..rebase' to 'branch..pullmode'. > > This way 'pull.mode' can be set to 'merge', and the default can be > something else. > > The old configurations still work, but get deprecated. Sounds good, but we should still mention these old names in the documentation (and mark them as deprecated). > +test "$mode" == 'rebase' && rebase="true" POSIX test does not take "==" as string equality; it is a bash-ism. test "$mode" = rebase -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL REQUEST] initial pack v4 support
On Tue, 10 Sep 2013, Junio C Hamano wrote: > Nicolas Pitre writes: > > > Junio, would you please pull the following into pu: > > > > git://git.linaro.org/people/nico/git > > > > This is the pack v4 work to date which is somewhat getting usable. It > > is time it gets more exposure, and possibly some more people's attention > > who would like to work on the missing parts as I need to scale down my > > own involvement. > > Thanks. Parked on 'pu'. Good. > > packv4-parse.c: allow tree entry copying from a canonical tree object > > This one needed a small fix-up to make it compile. > > I do not particularly like reusing that "size" variable, but it > seemed to be dead at that point, so... Feel free to fold this in the original commit. I'm curious... what compiler are you using? My gcc version is just happy to do arithmetic on void pointers. Nicolas -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Disabling status hints in COMMIT_EDITMSG
On Tue, Sep 10, 2013 at 11:04 PM, Matthieu Moy wrote: > Chris Packham writes: > >> On 10/09/13 21:19, Matthieu Moy wrote: >>> Hi, >>> >>> I just noticed that the template COMMIT_EDITMSG was containing status >>> hints, and that they were not particularty helpfull _during_ a commit. I >>> think it would be sensible to ignore advice.statusHints and disable >>> hints unconditionally when writting to COMMIT_EDITMSG. >>> >>> Any objection? >>> >> >> I did recently find them useful/reassuring when I was committing a >> merge. But I wouldn't consider that a strong objection. > > Just to make sure we're talking about the same thing: when commiting a > merge, the template currently looks like: > > Merge branch 'master' of /tmp/git > > Conflicts: > foo.txt > # > # It looks like you may be committing a merge. > # If this is not correct, please remove the file > # .git/MERGE_HEAD > # and try again. > > > # Please enter the commit message for your changes. Lines starting > # with '#' will be ignored, and an empty message aborts the commit. > # On branch master > # Your branch and 'origin/master' have diverged, > # and have 3 and 1 different commit each, respectively. > # (use "git pull" to merge the remote branch into yours) > # > # All conflicts fixed but you are still merging. > # (use "git commit" to conclude merge) > # > # Changes to be committed: > # > # modified: foo.txt > # > > What I'd like to remove are the parts between parenthesis : > > (use "git commit" to conclude merge) > (use "git pull" to merge the remote branch into yours) > > The first part (It looks like [...]) would remain, of course. > > Actually, even the "All conflicts fixed but you are still merging." part > is not really accurate when the commit is already started. OK. I wouldn't miss that parts in parenthesis. If I chose to abort the commit from the editor (e.g. :cq in vi) git status would still tell me what I need to know. > > -- > Matthieu Moy > http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL REQUEST] initial pack v4 support
Nicolas Pitre writes:
> Junio, would you please pull the following into pu:
>
> git://git.linaro.org/people/nico/git
>
> This is the pack v4 work to date which is somewhat getting usable. It
> is time it gets more exposure, and possibly some more people's attention
> who would like to work on the missing parts as I need to scale down my
> own involvement.
Thanks. Parked on 'pu'.
> packv4-parse.c: allow tree entry copying from a canonical tree object
This one needed a small fix-up to make it compile.
I do not particularly like reusing that "size" variable, but it
seemed to be dead at that point, so...
packv4-parse.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/packv4-parse.c b/packv4-parse.c
index f96acc1..3f95ed4 100644
--- a/packv4-parse.c
+++ b/packv4-parse.c
@@ -365,13 +365,14 @@ static int copy_canonical_tree_entries(struct packed_git
*p, off_t offset,
update_tree_entry(&desc);
end = desc.buffer;
- if (end - from > *sizep) {
+ size = (const char *)end - (const char *)from;
+ if (size > *sizep) {
free(data);
return -1;
}
- memcpy(*dstp, from, end - from);
- *dstp += end - from;
- *sizep -= end - from;
+ memcpy(*dstp, from, size);
+ *dstp += size;
+ *sizep -= size;
free(data);
return 0;
}
--
1.8.4-468-g1185e84
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: pack v4 trees with a canonical base
On Tue, 10 Sep 2013, Junio C Hamano wrote: > Nicolas Pitre writes: > > > On Tue, 10 Sep 2013, Junio C Hamano wrote: > > > >> There may be trees in the wild that record 100775 or 100777 in the > >> mode field for executable blobs, which also need to be special > >> cased. > > > > All the file mode bits are always preserved. So this is not really a > > special case as far as the pack v4 encoding is concerned. > > Ahh. OK. It can theoretically be argued that you could further > squeeze 13 bits out per tree entry because you would need only 5 > possible values (100644, 100755 12, 4, and 16, all > octal) for the modes, but we will never know what other modes we > would want to use in the future, so not being over-tight and using > 16-bit for this purpose is probably a good trade-off Absolutely. I tried not to lose any of the currently available extension possibilities in the canonical object format. > (squeezing 8 bits out per tree entry would make the shape of ident > table entry and tree path entry different and may hurt reusing the > code to parse these tables). One could argue that 16 bits is much more than sufficient to encode a time zone offset too. but again this didn't seem worth painting ourselves in a corner if ever some creative time zones are used. Those table are also compressed. So any repetition of the same mode bit pattern or sparseness in the tz bits is likely to be compressed well. Nicolas -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: pack v4 trees with a canonical base
Nicolas Pitre writes: very much appreciated to> On Tue, 10 Sep 2013, Junio C Hamano wrote: > >> Duy Nguyen writes: >> >> > On Tue, Sep 10, 2013 at 2:25 AM, Nicolas Pitre wrote: >> >> An eventual optimization to index-pack when completing a pack would be >> >> to attempt the encoding of appended tree objects into the packv4 format >> >> using the existing dictionary table in the pack, and fall back to the >> >> canonical format if that table doesn't have all the necessary elements. >> > >> > Yeah, it's on the improvement todo list. The way pack-objects creates >> > dictionaries right now, the tree dict should contain all elements the >> > base trees need so fall back is only necessary when trees are have >> > extra zeros in mode field. >> >> Careful. >> >> There may be trees in the wild that record 100775 or 100777 in the >> mode field for executable blobs, which also need to be special >> cased. > > All the file mode bits are always preserved. So this is not really a > special case as far as the pack v4 encoding is concerned. Ahh. OK. It can theoretically be argued that you could further squeeze 13 bits out per tree entry because you would need only 5 possible values (100644, 100755 12, 4, and 16, all octal) for the modes, but we will never know what other modes we would want to use in the future, so not being over-tight and using 16-bit for this purpose is probably a good trade-off (squeezing 8 bits out per tree entry would make the shape of ident table entry and tree path entry different and may hurt reusing the code to parse these tables). -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Regression in e02ca72: git svn rebase is broken on Windows
10.09.2013, 20:02, "Johannes Schindelin" : > Given the explanation what msysGit is, you might suspect that I'd like you > to try to fix this in the msysGit context: After installing > > https://code.google.com/p/msysgit/downloads/list?q=net+installer No problem. Here's what I have so far: 1. Installed the latest msysgit from the URL you've provided. Tried the git that comes out of the box that comes with the installer (1.8.3.msysgit): 1a. On CMD: everything is fine. 1b. On msys shell: everything is fine. 2. Checked out the branch you've suggested to try (pt/tentative-1.8.4) and installed it. Tried the new version: 2a. On CMD: got the problem that is being discussed in this thread. 2b. On msys shell: everything is fine. So, in summary. That commit e02ca72, somewhere between 1.8.3 and 1.8.4 introduced the regression in git/git-svn on Windows, when executed in CMD. Thanks, --Tvangeste -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] GIT-VERSION-GEN: Do not require tags to be annotated
On Tue, Sep 10, 2013 at 5:59 PM, Junio C Hamano wrote: > string to that file before building, so in that sense, we do not > *need* DEF_VER and version. But they have been there for a long > time, and I do not think it gives us a good trade-off between > risking regression and reducing the linecount to change it to remove > one. Fair enough! -- Sebastian Schuberth -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 0/8] Multiple simultaneously locked ref updates
Brad King writes: > On 09/10/2013 12:30 PM, Junio C Hamano wrote: >> Thanks. I am not sure if I should rewind and rebuild the series >> with these patches, though. This is a new feature and does not have >> to be merged to 'maint', so rebasing is perfectly fine, but it is >> not strictly necessary, either. > > I just thought I'd help out with the conflict resolution. Yeah, such an independent confirmation of the conflict resolution is very much appreciated. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: pack v4 trees with a canonical base
On Tue, 10 Sep 2013, Junio C Hamano wrote: > Duy Nguyen writes: > > > On Tue, Sep 10, 2013 at 2:25 AM, Nicolas Pitre wrote: > >> An eventual optimization to index-pack when completing a pack would be > >> to attempt the encoding of appended tree objects into the packv4 format > >> using the existing dictionary table in the pack, and fall back to the > >> canonical format if that table doesn't have all the necessary elements. > > > > Yeah, it's on the improvement todo list. The way pack-objects creates > > dictionaries right now, the tree dict should contain all elements the > > base trees need so fall back is only necessary when trees are have > > extra zeros in mode field. > > Careful. > > There may be trees in the wild that record 100775 or 100777 in the > mode field for executable blobs, which also need to be special > cased. All the file mode bits are always preserved. So this is not really a special case as far as the pack v4 encoding is concerned. Nicolas -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] reset: handle submodule with trailing slash
On Tue, Sep 10, 2013 at 09:37:45PM +0200, Jens Lehmann wrote:
> Am 10.09.2013 21:13, schrieb John Keeping:
> > When using tab-completion, a directory path will often end with a
> > trailing slash which currently confuses "git rm" when dealing with
>
> I think you meant to say "git reset" in the line above. Apart from
> that I'm all for it.
Yeah, you're right - I obviously got confused between the two patches :-(.
I'll wait for more feedback before submitting a re-roll.
> > submodules. Now that we have parse_pathspec we can easily handle this
> > by simply adding the PATHSPEC_STRIP_SUBMODULE_SLASH_CHEAP flag.
> >
> > Signed-off-by: John Keeping
> > ---
> > builtin/reset.c| 5 +
> > t/t7400-submodule-basic.sh | 6 --
> > 2 files changed, 9 insertions(+), 2 deletions(-)
> >
> > diff --git a/builtin/reset.c b/builtin/reset.c
> > index 5e4c551..9efac0f 100644
> > --- a/builtin/reset.c
> > +++ b/builtin/reset.c
> > @@ -220,8 +220,13 @@ static void parse_args(struct pathspec *pathspec,
> > }
> > }
> > *rev_ret = rev;
> > +
> > + if (read_cache() < 0)
> > + die(_("index file corrupt"));
> > +
> > parse_pathspec(pathspec, 0,
> >PATHSPEC_PREFER_FULL |
> > + PATHSPEC_STRIP_SUBMODULE_SLASH_CHEAP |
> >(patch_mode ? PATHSPEC_PREFIX_ORIGIN : 0),
> >prefix, argv);
> > }
> > diff --git a/t/t7400-submodule-basic.sh b/t/t7400-submodule-basic.sh
> > index 4192fe0..c268d3c 100755
> > --- a/t/t7400-submodule-basic.sh
> > +++ b/t/t7400-submodule-basic.sh
> > @@ -481,7 +481,7 @@ test_expect_success 'do not add files from a submodule'
> > '
> >
> > '
> >
> > -test_expect_success 'gracefully add submodule with a trailing slash' '
> > +test_expect_success 'gracefully add/reset submodule with a trailing slash'
> > '
> >
> > git reset --hard &&
> > git commit -m "commit subproject" init &&
> > @@ -495,7 +495,9 @@ test_expect_success 'gracefully add submodule with a
> > trailing slash' '
> > git add init/ &&
> > test_must_fail git diff --exit-code --cached init &&
> > test $commit = $(git ls-files --stage |
> > - sed -n "s/^16 \([^ ]*\).*/\1/p")
> > + sed -n "s/^16 \([^ ]*\).*/\1/p") &&
> > + git reset init/ &&
> > + git diff --exit-code --cached init
> >
> > '
> >
> >
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] reset: handle submodule with trailing slash
Am 10.09.2013 21:13, schrieb John Keeping:
> When using tab-completion, a directory path will often end with a
> trailing slash which currently confuses "git rm" when dealing with
I think you meant to say "git reset" in the line above. Apart from
that I'm all for it.
> submodules. Now that we have parse_pathspec we can easily handle this
> by simply adding the PATHSPEC_STRIP_SUBMODULE_SLASH_CHEAP flag.
>
> Signed-off-by: John Keeping
> ---
> builtin/reset.c| 5 +
> t/t7400-submodule-basic.sh | 6 --
> 2 files changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/builtin/reset.c b/builtin/reset.c
> index 5e4c551..9efac0f 100644
> --- a/builtin/reset.c
> +++ b/builtin/reset.c
> @@ -220,8 +220,13 @@ static void parse_args(struct pathspec *pathspec,
> }
> }
> *rev_ret = rev;
> +
> + if (read_cache() < 0)
> + die(_("index file corrupt"));
> +
> parse_pathspec(pathspec, 0,
> PATHSPEC_PREFER_FULL |
> +PATHSPEC_STRIP_SUBMODULE_SLASH_CHEAP |
> (patch_mode ? PATHSPEC_PREFIX_ORIGIN : 0),
> prefix, argv);
> }
> diff --git a/t/t7400-submodule-basic.sh b/t/t7400-submodule-basic.sh
> index 4192fe0..c268d3c 100755
> --- a/t/t7400-submodule-basic.sh
> +++ b/t/t7400-submodule-basic.sh
> @@ -481,7 +481,7 @@ test_expect_success 'do not add files from a submodule' '
>
> '
>
> -test_expect_success 'gracefully add submodule with a trailing slash' '
> +test_expect_success 'gracefully add/reset submodule with a trailing slash' '
>
> git reset --hard &&
> git commit -m "commit subproject" init &&
> @@ -495,7 +495,9 @@ test_expect_success 'gracefully add submodule with a
> trailing slash' '
> git add init/ &&
> test_must_fail git diff --exit-code --cached init &&
> test $commit = $(git ls-files --stage |
> - sed -n "s/^16 \([^ ]*\).*/\1/p")
> + sed -n "s/^16 \([^ ]*\).*/\1/p") &&
> + git reset init/ &&
> + git diff --exit-code --cached init
>
> '
>
>
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git-cvsserver strips exec bit
Junio C Hamano writes:
> Michael Cronenworth writes:
>
>> On git 1.8.1.x (Fedora 18) I was able to use the git-cvsserver to checkout
>> code
>> to package into a tarball. Script files that were in git with 755 masks were
>> checked-out with the same mask. After upgrading the git repository machine to
>> Fedora 19 (1.8.3.1) the behaviour has changed. When I checkout the same
>> script
>> files their mask is now 644. The mask has not changed in git.
>
> Matthew, I do not know if you are still using the git-cvsserver, but
> it seems that the only substantial change to that subsystem between
> the 1.8.1.x and 1.8.3.x is your update.
>
> Especially 2c3af7e7 (cvsserver: factor out git-log parsing logic,
> 2012-10-13) looks interesting. It has a hunk like this:
>
> -my $git_perms = "";
> -$git_perms .= "r" if ( $mode & 4 );
> -$git_perms .= "w" if ( $mode & 2 );
> -$git_perms .= "x" if ( $mode & 1 );
> -$git_perms = "rw" if ( $git_perms eq "" );
> +my $dbMode = convertToDbMode($mode);
>
> with the definition of convertToDbMode being:
>
> +sub convertToDbMode
> +{
> +my $mode = shift;
> +...
> +$mode=~/^\d\d(\d)\d{3}$/;
> +my $userBits=$1;
> +
> +my $dbMode = "";
> +$dbMode .= "r" if ( $userBits & 4 );
> +$dbMode .= "w" if ( $userBits & 2 );
> +$dbMode .= "x" if ( $userBits & 1 );
> +$dbMode = "rw" if ( $dbMode eq "" );
> +
> +return $dbMode;
>
> The $mode in the caller comes from diff-tree output (the post-change
> side of the mode string, like "100755").
>
> Picking the third digit from the left (i.e. "10'0'755"), instead of
> the tail digit (i.e. "10075'5'"), looks strange.
>
> Side note: now I look at it, the original does not make much sense
> for that matter. "100755" & 4 is different from oct("100755") & 4.
I stopped interacting with CVS quite a long time ago, so I do not
have any way of verifying, but the fix may be just the matter of
something like this.
I am not sure if we want to use the owner bit (i.e. 4th place)
instead of the other bit (i.e. the last place) like this patch does,
though. The old code in 1.8.1.x would have produced either "r" (for
100644) or "wx" (for 100755); I think that the result of applying
this patch would give us "r" (for 100644) or "rx" (for 100755).
-- >8 --
Subject: cvsserver: pick up the right mode bits
When determining the file mode from either ls-tree or diff-tree
output, we used to grab these octal mode string (typically 100644 or
100755) and then did
$git_perms .= "r" if ( $mode & 4 );
$git_perms .= "w" if ( $mode & 2 );
$git_perms .= "x" if ( $mode & 1 );
which was already wrong, as (100644 & 4) is very different from
oct("100644") & 4. An earlier refactoring 2c3af7e7 (cvsserver:
factor out git-log parsing logic, 2012-10-13) further changed it to
pick the third octal digit (10*0*644 or 10*0*755) from the left and
then do the above conversion, which does not make sense, either.
Let's use the last digit of the octal mode string to make sure we
get the executable and read bits right.
Signed-off-by: Junio C Hamano
---
git-cvsserver.perl | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/git-cvsserver.perl b/git-cvsserver.perl
index a0d796e..b1d7a4c 100755
--- a/git-cvsserver.perl
+++ b/git-cvsserver.perl
@@ -4167,7 +4167,7 @@ sub convertToDbMode
# this half-converted form, but it isn't currently worth the
# backwards compatibility headaches.
-$mode=~/^\d\d(\d)\d{3}$/;
+$mode=~/^\d{5}(\d)$/;
my $userBits=$1;
my $dbMode = "";
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: pack v4 trees with a canonical base
Duy Nguyen writes: > On Tue, Sep 10, 2013 at 2:25 AM, Nicolas Pitre wrote: >> An eventual optimization to index-pack when completing a pack would be >> to attempt the encoding of appended tree objects into the packv4 format >> using the existing dictionary table in the pack, and fall back to the >> canonical format if that table doesn't have all the necessary elements. > > Yeah, it's on the improvement todo list. The way pack-objects creates > dictionaries right now, the tree dict should contain all elements the > base trees need so fall back is only necessary when trees are have > extra zeros in mode field. Careful. There may be trees in the wild that record 100775 or 100777 in the mode field for executable blobs, which also need to be special cased. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's cooking in git.git (Sep 2013, #02; Mon, 9)
Jens Lehmann writes: > Am 10.09.2013 00:53, schrieb Junio C Hamano: >> * bc/submodule-status-ignored (2013-09-04) 2 commits >> - submodule: don't print status output with ignore=all >> - submodule: fix confusing variable name >> >> Originally merged to 'next' on 2013-08-22 >> >> Will merge to 'next'. > > I propose to cook this some time in next to give submodule > users who have configured ignore=all the opportunity to test > and comment on that. And as Matthieu noticed the documentation > is not terribly clear here, I'll prepare one or two patches to > fix that which should go in together with these changes. OK. Thanks. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] rm: re-use parse_pathspec's trailing-slash removal
Instead of re-implementing the "remove trailing slashes" loop in
builtin/rm.c just pass PATHSPEC_STRIP_SUBMODULE_SLASH_CHEAP to
parse_pathspec.
Signed-off-by: John Keeping
---
builtin/rm.c | 20
1 file changed, 4 insertions(+), 16 deletions(-)
diff --git a/builtin/rm.c b/builtin/rm.c
index 9b59ab3..3a0e0ea 100644
--- a/builtin/rm.c
+++ b/builtin/rm.c
@@ -298,22 +298,10 @@ int cmd_rm(int argc, const char **argv, const char
*prefix)
if (read_cache() < 0)
die(_("index file corrupt"));
- /*
-* Drop trailing directory separators from directories so we'll find
-* submodules in the index.
-*/
- for (i = 0; i < argc; i++) {
- size_t pathlen = strlen(argv[i]);
- if (pathlen && is_dir_sep(argv[i][pathlen - 1]) &&
- is_directory(argv[i])) {
- do {
- pathlen--;
- } while (pathlen && is_dir_sep(argv[i][pathlen - 1]));
- argv[i] = xmemdupz(argv[i], pathlen);
- }
- }
-
- parse_pathspec(&pathspec, 0, PATHSPEC_PREFER_CWD, prefix, argv);
+ parse_pathspec(&pathspec, 0,
+ PATHSPEC_PREFER_CWD |
+ PATHSPEC_STRIP_SUBMODULE_SLASH_CHEAP,
+ prefix, argv);
refresh_index(&the_index, REFRESH_QUIET, &pathspec, NULL, NULL);
seen = xcalloc(pathspec.nr, 1);
--
1.8.2
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] reset: handle submodule with trailing slash
The first patch is the important one here, the second one I noticed while checking if any other commands fail to handle submodule paths with a trailing slash and is just a simplification. John Keeping (2): reset: handle submodule with trailing slash rm: re-use parse_pathspec's trailing-slash removal builtin/reset.c| 5 + builtin/rm.c | 20 t/t7400-submodule-basic.sh | 6 -- 3 files changed, 13 insertions(+), 18 deletions(-) -- 1.8.2 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] reset: handle submodule with trailing slash
When using tab-completion, a directory path will often end with a
trailing slash which currently confuses "git rm" when dealing with
submodules. Now that we have parse_pathspec we can easily handle this
by simply adding the PATHSPEC_STRIP_SUBMODULE_SLASH_CHEAP flag.
Signed-off-by: John Keeping
---
builtin/reset.c| 5 +
t/t7400-submodule-basic.sh | 6 --
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/builtin/reset.c b/builtin/reset.c
index 5e4c551..9efac0f 100644
--- a/builtin/reset.c
+++ b/builtin/reset.c
@@ -220,8 +220,13 @@ static void parse_args(struct pathspec *pathspec,
}
}
*rev_ret = rev;
+
+ if (read_cache() < 0)
+ die(_("index file corrupt"));
+
parse_pathspec(pathspec, 0,
PATHSPEC_PREFER_FULL |
+ PATHSPEC_STRIP_SUBMODULE_SLASH_CHEAP |
(patch_mode ? PATHSPEC_PREFIX_ORIGIN : 0),
prefix, argv);
}
diff --git a/t/t7400-submodule-basic.sh b/t/t7400-submodule-basic.sh
index 4192fe0..c268d3c 100755
--- a/t/t7400-submodule-basic.sh
+++ b/t/t7400-submodule-basic.sh
@@ -481,7 +481,7 @@ test_expect_success 'do not add files from a submodule' '
'
-test_expect_success 'gracefully add submodule with a trailing slash' '
+test_expect_success 'gracefully add/reset submodule with a trailing slash' '
git reset --hard &&
git commit -m "commit subproject" init &&
@@ -495,7 +495,9 @@ test_expect_success 'gracefully add submodule with a
trailing slash' '
git add init/ &&
test_must_fail git diff --exit-code --cached init &&
test $commit = $(git ls-files --stage |
- sed -n "s/^16 \([^ ]*\).*/\1/p")
+ sed -n "s/^16 \([^ ]*\).*/\1/p") &&
+ git reset init/ &&
+ git diff --exit-code --cached init
'
--
1.8.2
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's cooking in git.git (Sep 2013, #02; Mon, 9)
Matthieu Moy writes: > Junio C Hamano writes: > >> * mm/rebase-continue-freebsd-WB (2013-09-09) 1 commit >> - rebase: fix run_specific_rebase's use of "return" on FreeBSD >> >> Work around a bug in FreeBSD shell that caused a regression to "git >> rebase" in v1.8.4. It would be lovely to hear from FreeBSD folks a >> success report to make sure we didn't miss any other use of a bare >> "return" from dot-sourced script. >> >> Will merge to 'next'. > > BTW, this is a candidate for maint too I guess. Yes, thanks for reminding me. I was planning to change that label to "Will merge to 'master' and later to 'maint'" when it hits 'next'. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Disabling status hints in COMMIT_EDITMSG
Matthieu Moy wrote: > I just noticed that the template COMMIT_EDITMSG was containing status > hints, and that they were not particularty helpfull _during_ a commit. I > think it would be sensible to ignore advice.statusHints and disable > hints unconditionally when writting to COMMIT_EDITMSG. > > Any objection? No objection from me. It sounds like a good change. Thanks, Jonathan -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Regression in e02ca72: git svn rebase is broken on Windows
Hi Tvangeste, On Tue, 10 Sep 2013, Tvangeste wrote: > 10.09.2013, 18:13, "Johannes Schindelin" : > > Have you tried with Git for Windows yet? > > What's Git for Windows? If you mean msysgit, Actually, they are two different things: Git for Windows is what the name says, and it comes with an installer. msysGit is the development environment to *build* Git for Windows. > then I say no, because the latest msysgit version is from June 02, and > the change under discussion was made later on, on June 25th. So, this > regression is not in msysgit release (yet). Given the explanation what msysGit is, you might suspect that I'd like you to try to fix this in the msysGit context: After installing https://code.google.com/p/msysgit/downloads/list?q=net+installer you will have a full build environment, including the build of our latest master. You can then "cd /git/" and "git checkout pt/tentative-1.8.4 && make install" to make sure that the version we are very close to releasing as the new Git for Windows version does not break your workflow. Ciao, Johannes -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Regression in e02ca72: git svn rebase is broken on Windows
10.09.2013, 18:13, "Johannes Schindelin" : > Have you tried with Git for Windows yet? What's Git for Windows? If you mean msysgit, then I say no, because the latest msysgit version is from June 02, and the change under discussion was made later on, on June 25th. So, this regression is not in msysgit release (yet). Thanks, --Tvangeste -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Re-Transmission of blobs?
Josef Wolf writes: > as we all know, files are identified by their SHA. Thus I had the impression > that when transfering files, git would know by the SHA whether a given file is > already available in the destination repository and the transfer would be of > no use. That is unfortunately not how things work. It is not like the receiving end sends the names of all objects it has, and the sending end excludes these objects from what it is going to send. Consider this simple history with only a handful of commits (as usual, time flows from left to right): E / A---B---C---D where D is at the tip of the sending side, E is at the tip of the receiving side. The exchange goes roughly like this: (receiving side): what do you have? (sending side): my tip is at D. (receiving side): D? I've never heard of it --- please give it to me. I have E. (sending side): E? I don't know about it; must be something you created since you forked from me. Tell me about its ancestors. (receiving side): OK, I have C. (sending side): Oh, C I know about. You do not have to tell me anything more. A packfile to bring you up to date will follow. At this point, the sender knows that the receiver needs the commit D, and trees and blobs in D. It does also know it has the commit C and trees and blobs in C. It does the best thing it can do using these (and only these) information, namely, to send the commit D, and send trees and blobs in D that are not in the commit C. You may happen to have something in E that match what is in D but not in C. Because the sender does not know anything about E at all in the first place, that information cannot be used to reduce the transfer. The sender theoretically _could_ also exploit the fact that any receiver that has C must have B and A and all trees and blobs associated with these ancestor commits [*1*], but that information is not currently discovered nor used during the object transfer. There may happen to be a tree or a blob in A that matches a tree or a blob in D. But because the common ancestor discovery exchange above stops at C, the sender does not bother enumerating all the objects that are in the ancestor commits of C when figuring out what objects to send to ensure that the receiving end has all the objects necessary to complete D. If you modified a blob at B (or C) and then resurrected the old version of the blob at D, it is likely that the blob is going to be sent again when the receiving end asks for D. There are some work being done to optimize this further using various techniques, but they are not ready yet. [Footnote] *1* only down to the shallow boundary, if the receiving end is a shallow clone. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Regression in e02ca72: git svn rebase is broken on Windows
10.09.2013, 18:53, "Johannes Sixt" : > Can you please run the command with GIT_TRACE=2? Sure: #> git --version trace: built-in: git 'version' git version 1.8.4.242.gbb80ee0 #> git svn rebase -l trace: exec: 'git-svn' 'rebase' '-l' trace: run_command: 'git-svn' 'rebase' '-l' trace: built-in: git 'rev-parse' '--git-dir' trace: built-in: git 'rev-parse' '--show-cdup' trace: built-in: git 'config' '--bool' '--get' 'svn.fetchall' trace: built-in: git 'config' '--bool' '--get' 'svn.noauthcache' trace: built-in: git 'config' '--bool' '--get' 'svn.nocheckout' trace: built-in: git 'config' '--get' 'svn.authorsprog' trace: built-in: git 'config' '--bool' '--get' 'svn.dryrun' trace: built-in: git 'config' '--bool' '--get' 'svn.preservemerges' trace: built-in: git 'config' '--bool' '--get' 'svn.followparent' trace: built-in: git 'config' '--bool' '--get' 'svn.useSvmProps' trace: built-in: git 'config' '--get' 'svn.authorsfile' trace: built-in: git 'config' '--get' 'svn.username' trace: built-in: git 'config' '--get' 'svn.repackflags' trace: built-in: git 'config' '--bool' '--get' 'svn.localtime' trace: built-in: git 'config' '--int' '--get' 'svn.repack' trace: built-in: git 'config' '--get' 'svn.ignorepaths' trace: built-in: git 'config' '--bool' '--get' 'svn.verbose' trace: built-in: git 'config' '--bool' '--get' 'svn.quiet' trace: built-in: git 'config' '--int' '--get' 'svn.logwindowsize' trace: built-in: git 'config' '--get' 'svn.ignorerefs' trace: built-in: git 'config' '--get' 'svn.configdir' trace: built-in: git 'config' '--bool' '--get' 'svn.merge' trace: built-in: git 'config' '--bool' '--get' 'svn.addauthorfrom' trace: built-in: git 'config' '--bool' '--get' 'svn.useSvnsyncProps' trace: built-in: git 'config' '--bool' '--get' 'svn.noMetadata' trace: built-in: git 'config' '--bool' '--get' 'svn.local' trace: built-in: git 'config' '--get' 'svn.strategy' trace: built-in: git 'config' '--get' 'svn.includepaths' trace: built-in: git 'config' '--bool' '--get' 'svn.uselogauthor' trace: built-in: git 'rev-parse' '--symbolic' '--all' trace: built-in: git 'config' '-l' trace: built-in: git 'config' '-l' trace: built-in: git 'update-index' '--refresh' trace: built-in: git 'rev-list' '--first-parent' '--pretty=medium' 'HEAD' '--' trace: built-in: git 'config' '--bool' 'svn.useSvmProps' trace: built-in: git 'config' '-l' trace: built-in: git 'for-each-ref' '--format=%(refname)' 'refs/' trace: built-in: git 'for-each-ref' '--format=%(refname)' 'refs/' trace: built-in: git 'for-each-ref' '--format=%(refname)' 'refs/' trace: built-in: git 'for-each-ref' '--format=%(refname)' 'refs/' trace: built-in: git 'for-each-ref' '--format=%(refname)' 'refs/' trace: built-in: git 'config' '--get' 'svn-remote.svn.rewriteRoot' trace: built-in: git 'config' '--get' 'svn-remote.svn.url' trace: built-in: git 'config' '--get' 'svn-remote.svn.pushurl' trace: built-in: git 'config' '--get' 'svn-remote.svn.uuid' trace: built-in: git 'rev-list' '--pretty=raw' '--reverse' 'cdc459d7cedcec6bb26812e24661c7318f031be4..refs/remotes/trunk' '--' trace: built-in: git 'config' '--get' 'svn-remote.svn.rewriteRoot' trace: built-in: git 'config' '--get' 'svn-remote.svn.rewriteUUID' trace: built-in: git 'diff-index' 'HEAD' '--' trace: exec: 'git-rebase' 'refs/remotes/trunk' trace: run_command: 'git-rebase' 'refs/remotes/trunk' trace: built-in: git 'rev-parse' '--parseopt' '--' 'refs/remotes/trunk' trace: built-in: git 'rev-parse' '--git-dir' trace: built-in: git 'rev-parse' '--is-bare-repository' trace: built-in: git 'rev-parse' '--show-toplevel' trace: built-in: git 'config' '--bool' 'rebase.stat' trace: built-in: git 'config' '--bool' 'rebase.autostash' trace: built-in: git 'config' '--bool' 'rebase.autosquash' trace: built-in: git 'rev-parse' '--verify' 'refs/remotes/trunk^0' trace: built-in: git 'rev-parse' '--verify' 'refs/remotes/trunk^0' trace: built-in: git 'symbolic-ref' '-q' 'HEAD' trace: built-in: git 'rev-parse' '--verify' 'HEAD' trace: built-in: git 'rev-parse' '--verify' 'HEAD' trace: built-in: git 'update-index' '-q' '--ignore-submodules' '--refresh' fatal: unable to access '../../../../w:/work/xxx/xxx-xxx-OSS.git.new/.git/config': Invalid argument trace: built-in: git 'diff-files' '--quiet' '--ignore-submodules' fatal: index file open failed: Invalid argument Cannot rebase: You have unstaged changes. trace: built-in: git 'diff-index' '--cached' '--quiet' '--ignore-submodules' 'HEAD' '--' Please commit or stash them. rebase refs/remotes/trunk: command returned error: 1 Thanks, --Tvangeste -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 01/14] Document the HTTP transport protocol
From: "Shawn O. Pearce"
Signed-off-by: Shawn O. Pearce
Signed-off-by: Tay Ray Chuan
--
This is the original
<1255065768-10428-2-git-send-email-spea...@spearce.org>
with some minor changes, as follows:
- fix mis-spelling 'paramterized'
- fix mis-spelling 'mangement' (spotted by Junio)
- fix missing ABNF reference for smart replies (spotted by Sverre, Junio)
---
Documentation/technical/http-protocol.txt | 542 ++
1 file changed, 542 insertions(+)
create mode 100644 Documentation/technical/http-protocol.txt
diff --git a/Documentation/technical/http-protocol.txt
b/Documentation/technical/http-protocol.txt
new file mode 100644
index 000..0a2a53d
--- /dev/null
+++ b/Documentation/technical/http-protocol.txt
@@ -0,0 +1,542 @@
+HTTP transfer protocols
+===
+
+Git supports two HTTP based transfer protocols. A "dumb" protocol
+which requires only a standard HTTP server on the server end of the
+connection, and a "smart" protocol which requires a Git aware CGI
+(or server module). This document describes both protocols.
+
+As a design feature smart clients can automatically upgrade "dumb"
+protocol URLs to smart URLs. This permits all users to have the
+same published URL, and the peers automatically select the most
+efficient transport available to them.
+
+
+URL Format
+--
+
+URLs for Git repositories accessed by HTTP use the standard HTTP
+URL syntax documented by RFC 1738, so they are of the form:
+
+ http://:/
+
+Within this documentation the placeholder $GIT_URL will stand for
+the http:// repository URL entered by the end-user.
+
+Both the "smart" and "dumb" HTTP protocols used by Git operate
+by appending additional path components onto the end of the user
+supplied $GIT_URL string.
+
+Clients MUST strip a trailing '/', if present, from the user supplied
+$GIT_URL string to prevent empty path tokens ('//') from appearing
+in any URL sent to a server. Compatible clients must expand
+'$GIT_URL/info/refs' as 'foo/info/refs' and not 'foo//info/refs'.
+
+
+Authentication
+--
+
+Standard HTTP authentication is used if authentication is required
+to access a repository, and MAY be configured and enforced by the
+HTTP server software.
+
+Because Git repositories are accessed by standard path components
+server administrators MAY use directory based permissions within
+their HTTP server to control repository access.
+
+Clients SHOULD support Basic authentication as described by RFC 2616.
+Servers SHOULD support Basic authentication by relying upon the
+HTTP server placed in front of the Git server software.
+
+Servers MUST NOT require HTTP cookies for the purposes of
+authentication or access control.
+
+Clients and servers MAY support other common forms of HTTP based
+authentication, such as Digest authentication.
+
+
+SSL
+---
+
+Clients and servers SHOULD support SSL, particularly to protect
+passwords when relying on Basic HTTP authentication.
+
+
+Session State
+-
+
+The Git over HTTP protocol (much like HTTP itself) is stateless
+from the perspective of the HTTP server side. All state must be
+retained and managed by the client process. This permits simple
+round-robin load-balancing on the server side, without needing to
+worry about state management.
+
+Clients MUST NOT require state management on the server side in
+order to function correctly.
+
+Servers MUST NOT require HTTP cookies in order to function correctly.
+Clients MAY store and forward HTTP cookies during request processing
+as described by RFC 2616 (HTTP/1.1). Servers SHOULD ignore any
+cookies sent by a client.
+
+
+pkt-line Format
+---
+
+Much (but not all) of the payload is described around pkt-lines.
+
+A pkt-line is a variable length binary string. The first four bytes
+of the line indicates the total length of the line, in hexadecimal.
+The total length includes the 4 bytes used to denote the length.
+A line SHOULD BE terminated by an LF, which if present MUST be
+included in the total length.
+
+A pkt-line MAY contain binary data, so implementors MUST ensure all
+pkt-line parsing/formatting routines are 8-bit clean. The maximum
+length of a pkt-line's data is 65532 bytes (65536 - 4).
+
+Examples (as C-style strings):
+
+ pkt-line actual value
+ -
+ "0006a\n" "a\n"
+ "0005a" "a"
+ "000bfoobar\n""foobar\n"
+ "0004"""
+
+A pkt-line with a length of 0 ("") is a special case and MUST
+be treated as a message break or terminator in the payload.
+
+
+General Request Processing
+--
+
+Except where noted, all standard HTTP behavior SHOULD be assumed
+by both client and server. This includes (but is not necessarily
+limited to):
+
+If there is no repository at $GIT_URL, the server MUST respond with
+the '404 Not Found' HTTP status code.
+
+If there is a repository at $GIT_URL, but access is not currently
+permitted, the se
[PATCH 04/14] normalize rules with RFC 5234
Drop LF, SP which are defined in RFC 5234.
Replace HT with HTAB (also defined in the RFC).
Use '/' instead of '|', as the RFC does.
Signed-off-by: Tay Ray Chuan
---
Documentation/technical/http-protocol.txt | 26 +-
1 file changed, 9 insertions(+), 17 deletions(-)
diff --git a/Documentation/technical/http-protocol.txt
b/Documentation/technical/http-protocol.txt
index 55753bb..ff91bb0 100644
--- a/Documentation/technical/http-protocol.txt
+++ b/Documentation/technical/http-protocol.txt
@@ -192,16 +192,13 @@ according to the C locale ordering. The file SHOULD NOT
include
the default ref named 'HEAD'.
info_refs= *( ref_record )
- ref_record = any_ref | peeled_ref
+ ref_record = any_ref / peeled_ref
- any_ref = id HT name LF
- peeled_ref = id HT name LF
- id HT name "^{}" LF
+ any_ref = id HTAB name LF
+ peeled_ref = id HTAB name LF
+ id HTAB name "^{}" LF
id = 40*HEX
- HEX = "0".."9" | "a".."f"
- LF =
- HT =
Smart Clients
~
@@ -288,7 +285,7 @@ declarations behind a NUL on the first ref.
smart_reply = PKT-LINE("# service=$servicename" LF)
ref_list
""
- ref_list = empty_list | non_empty_list
+ ref_list = empty_list / non_empty_list
empty_list = PKT-LINE(id SP "capabilities^{}" NUL cap_list LF)
@@ -296,18 +293,13 @@ declarations behind a NUL on the first ref.
*ref_record
cap_list = *(SP capability) SP
- ref_record = any_ref | peeled_ref
+ ref_record = any_ref / peeled_ref
any_ref = PKT-LINE(id SP name LF)
peeled_ref = PKT-LINE(id SP name LF)
PKT-LINE(id SP name "^{}" LF
id = 40*HEX
- HEX = "0".."9" | "a".."f"
- NL =
- LF =
- SP =
-
Smart Service git-upload-pack
--
@@ -343,7 +335,7 @@ appear in the response obtained through ref discovery.
compute_request = want_list
have_list
request_end
- request_end = "" | "done"
+ request_end = "" / "done"
want_list= PKT-LINE(want NUL cap_list LF)
*(want_pkt)
@@ -353,7 +345,7 @@ appear in the response obtained through ref discovery.
have_list= *PKT-LINE("have" SP id LF)
- command = create | delete | update
+ command = create / delete / update
create = 40*"0" SP new_id SP name
delete = old_id SP 40*"0" SP name
update = old_id SP new_id SP name
@@ -530,7 +522,7 @@ the id obtained through ref discovery as old_id.
command_pkt = PKT-LINE(command LF)
cap_list = *(SP capability) SP
- command = create | delete | update
+ command = create / delete / update
create = 40*"0" SP new_id SP name
delete = old_id SP 40*"0" SP name
update = old_id SP new_id SP name
--
1.8.4.rc4.527.g303b16c
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 0/8] Multiple simultaneously locked ref updates
On 09/10/2013 12:30 PM, Junio C Hamano wrote: > Thanks. I am not sure if I should rewind and rebuild the series > with these patches, though. This is a new feature and does not have > to be merged to 'maint', so rebasing is perfectly fine, but it is > not strictly necessary, either. I just thought I'd help out with the conflict resolution. If you're happy with resolving the conflicts in v5 then there is no reason to use v6. Thanks, -Brad -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Regression in e02ca72: git svn rebase is broken on Windows
Tvangeste writes: > Hi, > > After bisecting this problem I ended up with the mentioned commit that > completely breaks git-svn for me on Windows (mingw/msys version). > > == > #> git svn rebase > warning: unable to access '': Invalid argument > warning: unable to access '': Invalid argument > fatal: unable to access '../../../../w:/work/my/repo.git/.git/config': > Invalid argument > fatal: index file open failed: Invalid argument > Cannot rebase: You have unstaged changes. > Please commit or stash them. > rebase refs/remotes/trunk: command returned error: 1 > == > > Please note that I use the official git repository as-is, this one (no > additional patches): > git://git.kernel.org/pub/scm/git/git.git > > e02ca72f70ed8f0268a81f72cb3230c72e538e77 is the first bad commit > commit e02ca72f70ed8f0268a81f72cb3230c72e538e77 > Author: Jiang Xin > Date: Tue Jun 25 23:53:43 2013 +0800 > > path.c: refactor relative_path(), not only strip prefix > > Thanks, > --Tvangeste The suspect commit and symptom look consistent. You started from a directory whose absolute path is "w:/work/..." and the updated code mistakenly thoguht that something that begins with "w" (not '/') is not an absolute, so added a series of ../ to make it relative, or something silly like that. Jiang? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 06/14] reword behaviour on missing repository or objects
From: "Shawn O. Pearce" Signed-off-by: Tay Ray Chuan -- To Shawn: sign-off-by needed. Based on: From: "Shawn O. Pearce" Message-ID: <20091016142135.gr10...@spearce.org> Mike Hommey wrote: > On Thu, Oct 15, 2009 at 10:59:25PM -0700, H. Peter Anvin wrote: > > On 10/10/2009 03:12 AM, Antti-Juhani Kaijanaho wrote: > > > On 2009-10-09, Junio C Hamano wrote: > > >>> +If there is no repository at $GIT_URL, the server MUST respond with > > >>> +the '404 Not Found' HTTP status code. > > >> > > >> We may also want to add > > >> > > >> If there is no object at $GIT_URL/some/path, the server MUST respond > > >> with the '404 Not Found' HTTP status code. > > >> > > >> to help dumb clients. > > > > > > In both cases - is it really necessary to forbid the use of 410 (Gone)? My original text got taken a bit out of context here. I guess MUST was too strong of a word. I more ment something like: If there is no repository at $GIT_URL, the server MUST NOT respond with '200 OK' and a valid info/refs response. A server SHOULD respond with '404 Not Found', '410 Gone', or any other suitable HTTP status code which does not imply the resource exists as requested. In addition, address behaviour on missing objects, as suggested by Junio. His text (see quote in above excerpt) was not used, in favour of a more general treatment (locations matching $GIT_URL, not just objects). --- Documentation/technical/http-protocol.txt | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/Documentation/technical/http-protocol.txt b/Documentation/technical/http-protocol.txt index a8d28ba..412b898 100644 --- a/Documentation/technical/http-protocol.txt +++ b/Documentation/technical/http-protocol.txt @@ -91,8 +91,12 @@ Except where noted, all standard HTTP behavior SHOULD be assumed by both client and server. This includes (but is not necessarily limited to): -If there is no repository at $GIT_URL, the server MUST respond with -the '404 Not Found' HTTP status code. +If there is no repository at $GIT_URL, the server MUST NOT respond with +'200 OK' and a valid info/refs response. Also, if the resource pointed +to by a location matching $GIT_URL does not exist, the server MUST NOT +respond with '200 OK'. A server SHOULD respond with +'404 Not Found', '410 Gone', or any other suitable HTTP status code +which does not imply the resource exists as requested. If there is a repository at $GIT_URL, but access is not currently permitted, the server MUST respond with the '403 Forbidden' HTTP -- 1.8.4.rc4.527.g303b16c -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 00/14] document edits to original http protocol documentation
This patch series are the changes based on the discussion on Shawn's
original text [1]. Some of them are minor, while some may potentially
change behaviour; see below for a classification of the changes.
Hopefully they can be examined by the git contributors here.
An earlier iteration of this patch series [2], including additional
changes by Nguyen [3], had been merged in 36d8020 (Merge branch
'sp/doc-smart-http', Aug 30). Since that iteration, the changes have
been corrected and consolidated. Effort has also been made to provide
the context for the changes; hopefully it helps with the review.
[1] http://mid.gmane.org/<1255065768-10428-2-git-send-email-spea...@spearce.org>
[2]
https://github.com/rctay/git/blob/rc/http-doc/v1/p/Documentation/technical/http-protocol.txt
[3] http://mid.gmane.org/<1377092713-25434-1-git-send-email-pclo...@gmail.com>
(For convenience, a diff against 36d8020 is included at the end of this
message; it is in word-diff form, hopefully for better clarity of the
changes.)
Given that an earlier iteration had already been merged, perhaps that
could be replaced with merge -Xtheirs (just throwing ideas, my git-fu is
not that strong). This would make the changes on the original RFC
available eg. via git-blame, which may be helpful for implementations
made based on the original RFC, especially since these "early"
implementations may now be in violation of the recently-included copy of
the spec.
The patches have been grouped based on their "safeness" (with regard to
potentially changing the protocol spec), with a bias towards caution, as
follows:
Trivial changes (eg formatting, style):
[PATCH 01/14] Document the HTTP transport protocol
[PATCH 02/14] normalize indentation with protcol-common.txt
[PATCH 03/14] capitalize key words according to RFC 2119
[PATCH 04/14] normalize rules with RFC 5234
[PATCH 05/14] drop rules, etc. common to the pack protocol
[PATCH 10/14] fix example request/responses
[PATCH 13/14] shift dumb server response details
Rewords based on discussions that have been settled, or seem safe:
[PATCH 07/14] weaken specification over cookies for authentication
[PATCH 09/14] reduce ambiguity over '?' in $GIT_URL for dumb clients
[PATCH 11/14] be clearer in place of 'remote repository' phrase
Potentially behaviour-changes, may need of discussion:
[PATCH 06/14] reword behaviour on missing repository or objects
[PATCH 08/14] mention different variations around $GIT_URL
[PATCH 12/14] reduce confusion over smart server response behaviour
[PATCH 14/14] mention effect of "allow-tip-sha1-in-want" capability
Full, ordered listing:
[PATCH 01/14] Document the HTTP transport protocol
[PATCH 02/14] normalize indentation with protcol-common.txt
[PATCH 03/14] capitalize key words according to RFC 2119
[PATCH 04/14] normalize rules with RFC 5234
[PATCH 05/14] drop rules, etc. common to the pack protocol
[PATCH 06/14] reword behaviour on missing repository or objects
[PATCH 07/14] weaken specification over cookies for authentication
[PATCH 08/14] mention different variations around $GIT_URL
[PATCH 09/14] reduce ambiguity over '?' in $GIT_URL for dumb clients
[PATCH 10/14] fix example request/responses
[PATCH 11/14] be clearer in place of 'remote repository' phrase
[PATCH 12/14] reduce confusion over smart server response behaviour
[PATCH 13/14] shift dumb server response details
[PATCH 14/14] mention effect of "allow-tip-sha1-in-want" capability
This patch series is queued at:
https://github.com/rctay/git/commits/rc/http-doc/v2/q
--
1.8.4.rc4.527.g303b16c
output of
$ git diff -b --word-diff 36d8020 -- Documentation/technical/http-protocol.txt
diff --git a/Documentation/technical/http-protocol.txt
b/Documentation/technical/http-protocol.txt
index a1173ee..acc68ac 100644
--- a/Documentation/technical/http-protocol.txt
+++ b/Documentation/technical/http-protocol.txt
@@ -11,6 +11,10 @@ protocol URLs to smart URLs. This permits all users to have
the
same published URL, and the peers automatically select the most
efficient transport available to them.
{+The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL+}
{+NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and+}
{+"OPTIONAL" in this document are to be interpreted as described in+}
{+RFC 2119.+}
URL Format
--
@@ -33,16 +37,13 @@ An example of a dumb client requesting for a loose object:
$GIT_URL: http://example.com:8080/git/repo.git
URL request:
http://example.com:8080/git/repo.git/objects/d0/49f6c27a2244e12041955e262a404c7faba355
An example of a smart request to a catch-all [-gateway:-]{+gateway (notice how
the+}
{+'service' parameter is passed with '&', since a '?' was detected in+}
{+$GIT_URL):+}
$GIT_URL: http://example.com/daemon.cgi?svc=git&q=
URL request:
http://example.com/daemon.cgi?svc=git&q=/info/refs&service=git-receive-pack
[-An example of a request to a submodule:-]
[- $GIT_URL: http://example.com/git/
Re: git-cvsserver strips exec bit
Michael Cronenworth writes:
> On git 1.8.1.x (Fedora 18) I was able to use the git-cvsserver to checkout
> code
> to package into a tarball. Script files that were in git with 755 masks were
> checked-out with the same mask. After upgrading the git repository machine to
> Fedora 19 (1.8.3.1) the behaviour has changed. When I checkout the same script
> files their mask is now 644. The mask has not changed in git.
Matthew, I do not know if you are still using the git-cvsserver, but
it seems that the only substantial change to that subsystem between
the 1.8.1.x and 1.8.3.x is your update.
Especially 2c3af7e7 (cvsserver: factor out git-log parsing logic,
2012-10-13) looks interesting. It has a hunk like this:
-my $git_perms = "";
-$git_perms .= "r" if ( $mode & 4 );
-$git_perms .= "w" if ( $mode & 2 );
-$git_perms .= "x" if ( $mode & 1 );
-$git_perms = "rw" if ( $git_perms eq "" );
+my $dbMode = convertToDbMode($mode);
with the definition of convertToDbMode being:
+sub convertToDbMode
+{
+my $mode = shift;
+...
+$mode=~/^\d\d(\d)\d{3}$/;
+my $userBits=$1;
+
+my $dbMode = "";
+$dbMode .= "r" if ( $userBits & 4 );
+$dbMode .= "w" if ( $userBits & 2 );
+$dbMode .= "x" if ( $userBits & 1 );
+$dbMode = "rw" if ( $dbMode eq "" );
+
+return $dbMode;
The $mode in the caller comes from diff-tree output (the post-change
side of the mode string, like "100755").
Picking the third digit from the left (i.e. "10'0'755"), instead of
the tail digit (i.e. "10075'5'"), looks strange.
Side note: now I look at it, the original does not make much sense
for that matter. "100755" & 4 is different from oct("100755") & 4.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Regression in e02ca72: git svn rebase is broken on Windows
Am 10.09.2013 15:14, schrieb Tvangeste: > After bisecting this problem I ended up with the mentioned commit > that completely breaks git-svn for me on Windows (mingw/msys version). > > == > #> git svn rebase > warning: unable to access '': Invalid argument > warning: unable to access '': Invalid argument > fatal: unable to access '../../../../w:/work/my/repo.git/.git/config': > Invalid argument > fatal: index file open failed: Invalid argument > Cannot rebase: You have unstaged changes. > Please commit or stash them. > rebase refs/remotes/trunk: command returned error: 1 > == Can you please run the command with GIT_TRACE=2? -- Hannes -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 03/14] capitalize key words according to RFC 2119
Signed-off-by: Tay Ray Chuan
---
Documentation/technical/http-protocol.txt | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/Documentation/technical/http-protocol.txt
b/Documentation/technical/http-protocol.txt
index 70a1648..55753bb 100644
--- a/Documentation/technical/http-protocol.txt
+++ b/Documentation/technical/http-protocol.txt
@@ -11,6 +11,10 @@ protocol URLs to smart URLs. This permits all users to have
the
same published URL, and the peers automatically select the most
efficient transport available to them.
+The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
+NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
+"OPTIONAL" in this document are to be interpreted as described in
+RFC 2119.
URL Format
--
@@ -29,7 +33,7 @@ supplied $GIT_URL string.
Clients MUST strip a trailing '/', if present, from the user supplied
$GIT_URL string to prevent empty path tokens ('//') from appearing
-in any URL sent to a server. Compatible clients must expand
+in any URL sent to a server. Compatible clients MUST expand
'$GIT_URL/info/refs' as 'foo/info/refs' and not 'foo//info/refs'.
@@ -66,7 +70,7 @@ Session State
-
The Git over HTTP protocol (much like HTTP itself) is stateless
-from the perspective of the HTTP server side. All state must be
+from the perspective of the HTTP server side. All state MUST be
retained and managed by the client process. This permits simple
round-robin load-balancing on the server side, without needing to
worry about state management.
@@ -158,7 +162,7 @@ references by making a request for the special info/refs
file of
the repository.
Dumb HTTP clients MUST NOT include search/query parameters when
-fetching the info/refs file. (That is, '?' must not appear in the
+fetching the info/refs file. (That is, '?' MUST NOT appear in the
requested URL.)
C: GET $GIT_URL/info/refs HTTP/1.0
@@ -390,7 +394,7 @@ The computation to select the minimal pack proceeds as
follows
(c) Start a queue, C_PENDING, ordered by commit time (popping newest
first). Add all client refs. When a commit is popped from
- the queue its parents should be automatically inserted back.
+ the queue its parents SHOULD be automatically inserted back.
Commits MUST only enter the queue once.
one compute step:
@@ -431,7 +435,7 @@ The computation to select the minimal pack proceeds as
follows
If the client has sent 256 HAVE commits and has not yet
received one of those back from S_COMMON, or the client has
- emptied C_PENDING it should include a "done" command to let
+ emptied C_PENDING it SHOULD include a "done" command to let
the server know it won't proceed:
C: 0009done
@@ -470,7 +474,7 @@ TODO: Document the pack based response
The returned stream is the side-band-64k protocol supported
by the git-upload-pack service, and the pack is embedded into
- stream 1. Progress messages from the server side may appear
+ stream 1. Progress messages from the server side MAY appear
in stream 2.
Here a "closed set of objects" is defined to have at least
@@ -538,5 +542,6 @@ References
--
link:http://www.ietf.org/rfc/rfc1738.txt[RFC 1738: Uniform Resource Locators
(URL)]
+link:http://www.ietf.org/rfc/rfc2119.txt[RFC 2119: Key words for use in RFCs
to Indicate Requirement Levels]
link:http://www.ietf.org/rfc/rfc2616.txt[RFC 2616: Hypertext Transfer Protocol
-- HTTP/1.1]
--
1.8.4.rc4.527.g303b16c
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 09/14] reduce ambiguity over '?' in $GIT_URL for dumb clients
From: Junio C Hamano It is unclear if '?' can be part of $GIT_URL. E.g. $ wget http://example.xz/serve.cgi?path=git.git/info/refs $ git clone http://example.xz/serve.cgi?path=git.git Signed-off-by: Tay Ray Chuan -- Notes: - said "request to" instead of Junio's "request against", for consistency with the rest of the document. - said "E.g." instead of "I.e." since it's an example request and response Based on: From: Junio C Hamano Message-ID: <7vskdss3ei@alter.siamese.dyndns.org> > +Dumb Clients > + > + > +HTTP clients that only support the "dumb" protocol MUST discover > +references by making a request for the special info/refs file of > +the repository. > + > +Dumb HTTP clients MUST NOT include search/query parameters when > +fetching the info/refs file. (That is, '?' must not appear in the > +requested URL.) It is unclear if '?' can be part of $GIT_URL. E.g. $ wget http://example.xz/serve.cgi?path=git.git/info/refs $ git clone http://example.xz/serve.cgi?path=git.git It might be clearer to just say Dumb HTTP clients MUST make a GET request against $GIT_URL/info/refs, without any search/query parameters. I.e. C: GET $GIT_URL/info/refs HTTP/1.0 to also exclude methods other than GET. --- Documentation/technical/http-protocol.txt | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/Documentation/technical/http-protocol.txt b/Documentation/technical/http-protocol.txt index d0955c2..5141c6a 100644 --- a/Documentation/technical/http-protocol.txt +++ b/Documentation/technical/http-protocol.txt @@ -150,9 +150,8 @@ HTTP clients that only support the "dumb" protocol MUST discover references by making a request for the special info/refs file of the repository. -Dumb HTTP clients MUST NOT include search/query parameters when -fetching the info/refs file. (That is, '?' MUST NOT appear in the -requested URL.) +Dumb HTTP clients MUST make a GET request to $GIT_URL/info/refs, +without any search/query parameters. E.g. C: GET $GIT_URL/info/refs HTTP/1.0 -- 1.8.4.rc4.527.g303b16c -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 14/14] mention effect of "allow-tip-sha1-in-want" capability on git-upload-pack
From: Nguyễn Thái Ngọc Duy Signed-off-by: Tay Ray Chuan Signed-off-by: Nguyễn Thái Ngọc Duy -- Subject crafted by Ray Chuan, Nguyễn's s-o-b lifted from <1377092713-25434-1-git-send-email-pclo...@gmail.com>. --- Documentation/technical/http-protocol.txt | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/Documentation/technical/http-protocol.txt b/Documentation/technical/http-protocol.txt index 3098aa4..acc68ac 100644 --- a/Documentation/technical/http-protocol.txt +++ b/Documentation/technical/http-protocol.txt @@ -304,7 +304,8 @@ Servers SHOULD support all capabilities defined here. Clients MUST send at least one 'want' command in the request body. Clients MUST NOT reference an id in a 'want' command which did not -appear in the response obtained through ref discovery. +appear in the response obtained through ref discovery unless the +server advertises capability "allow-tip-sha1-in-want". compute_request = want_list have_list -- 1.8.4.rc4.527.g303b16c -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 07/14] weaken specification over cookies for authentication
From: "Shawn O. Pearce" Signed-off-by: Tay Ray Chuan -- To Shawn: sign-off-by needed. Based on the discussion in <20091009195035.ga15...@coredump.intra.peff.net>, <20091015165228.go10...@spearce.org> (patch), <20091015173902.ga22...@sigill.intra.peff.net> (agreement) From: "Shawn O. Pearce" Message-ID: <20091015165228.go10...@spearce.org> I weakend the sections on cookies: + Authentication + -- + Servers SHOULD NOT require HTTP cookies for the purposes of + authentication or access control. and that's all we say on the matter. I took out the Servers MUST NOT line under session state. --- Documentation/technical/http-protocol.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/technical/http-protocol.txt b/Documentation/technical/http-protocol.txt index 412b898..2382384 100644 --- a/Documentation/technical/http-protocol.txt +++ b/Documentation/technical/http-protocol.txt @@ -52,7 +52,7 @@ Clients SHOULD support Basic authentication as described by RFC 2616. Servers SHOULD support Basic authentication by relying upon the HTTP server placed in front of the Git server software. -Servers MUST NOT require HTTP cookies for the purposes of +Servers SHOULD NOT require HTTP cookies for the purposes of authentication or access control. Clients and servers MAY support other common forms of HTTP based -- 1.8.4.rc4.527.g303b16c -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 11/14] be clearer in place of 'remote repository' phrase
Based on: From: Junio C Hamano Message-ID: <7vskdss3ei@alter.siamese.dyndns.org> > +Smart Service git-upload-pack > +-- > +This service reads from the remote repository. The wording "remote repository" felt confusing. I know it is "from the repository served by the server", but if it were named without "upload-pack", I might have mistaken that you are allowing to proxy a request to access a third-party repository by this server. The same comment applies to the git-receive-pack service. Signed-off-by: Tay Ray Chuan --- Documentation/technical/http-protocol.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/technical/http-protocol.txt b/Documentation/technical/http-protocol.txt index dbfff36..4bb1614 100644 --- a/Documentation/technical/http-protocol.txt +++ b/Documentation/technical/http-protocol.txt @@ -279,7 +279,7 @@ declarations behind a NUL on the first ref. Smart Service git-upload-pack -- -This service reads from the remote repository. +This service reads from the repository pointed to by $GIT_URL. Clients MUST first perform ref discovery with '$GIT_URL/info/refs?service=git-upload-pack'. @@ -440,7 +440,7 @@ TODO: Document parsing response Smart Service git-receive-pack -- -This service modifies the remote repository. +This service modifies the repository pointed to by $GIT_URL. Clients MUST first perform ref discovery with '$GIT_URL/info/refs?service=git-receive-pack'. -- 1.8.4.rc4.527.g303b16c -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
breakage in revision traversal with pathspec
I am grumpy X-<. It appears that we introduced a large breakage during 1.8.4 cycle to the revision traversal machinery and made pathspec-limited "git log" pretty much useless. This command $ git log v1.8.3.1..v1.8.4 -- git-cvsserver.perl reports that a merge 766f0f8ef7 (which did not touch the specified path at all) touches it. Bisecting points at d0af663e (revision.c: Make --full-history consider more merges, 2013-05-16). -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 13/14] shift dumb server response details
Shift details like ABNF from the client section to server section. This
is in line with the smart analogue.
Signed-off-by: Tay Ray Chuan
---
Documentation/technical/http-protocol.txt | 49 +++
1 file changed, 23 insertions(+), 26 deletions(-)
diff --git a/Documentation/technical/http-protocol.txt
b/Documentation/technical/http-protocol.txt
index 63a089a..3098aa4 100644
--- a/Documentation/technical/http-protocol.txt
+++ b/Documentation/technical/http-protocol.txt
@@ -162,30 +162,6 @@ without any search/query parameters. E.g.
S: 2cb58b79488a98d2721cea644875a8dd0026b115 refs/tags/v1.0\n
S: a3c2e2402b99163d1d59756e5f207ae21cccba4c refs/tags/v1.0^{}\n
-The Content-Type of the returned info/refs entity SHOULD be
-"text/plain; charset=utf-8", but MAY be any content type.
-Clients MUST NOT attempt to validate the returned Content-Type.
-Dumb servers MUST NOT return a return type starting with
-"application/x-git-".
-
-Cache-Control headers MAY be returned to disable caching of the
-returned entity.
-
-When examining the response clients SHOULD only examine the HTTP
-status code. Valid responses are '200 OK', or '304 Not Modified'.
-
-The returned content is a UNIX formatted text file describing
-each ref and its known value. The file SHOULD be sorted by name
-according to the C locale ordering. The file SHOULD NOT include
-the default ref named 'HEAD'.
-
- info_refs= *( ref_record )
- ref_record = any_ref / peeled_ref
-
- any_ref = obj-id HTAB refname LF
- peeled_ref = obj-id HTAB refname LF
- obj-id HTAB refname "^{}" LF
-
Smart Clients
~
@@ -229,8 +205,29 @@ Dumb Server Response
Dumb servers MUST respond with the dumb server reply format.
-See the prior section under dumb clients for a more detailed
-description of the dumb server response.
+The Content-Type of the returned info/refs entity SHOULD be
+"text/plain; charset=utf-8", but MAY be any content type.
+Clients MUST NOT attempt to validate the returned Content-Type.
+Dumb servers MUST NOT return a return type starting with
+"application/x-git-".
+
+Cache-Control headers MAY be returned to disable caching of the
+returned entity.
+
+When examining the response clients SHOULD only examine the HTTP
+status code. Valid responses are '200 OK', or '304 Not Modified'.
+
+The returned content is a UNIX formatted text file describing
+each ref and its known value. The file SHOULD be sorted by name
+according to the C locale ordering. The file SHOULD NOT include
+the default ref named 'HEAD'.
+
+ info_refs= *( ref_record )
+ ref_record = any_ref / peeled_ref
+
+ any_ref = obj-id HTAB refname LF
+ peeled_ref = obj-id HTAB refname LF
+ obj-id HTAB refname "^{}" LF
Smart Server Response
^
--
1.8.4.rc4.527.g303b16c
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 10/14] fix example request/responses
Add LF for responses.
For smart interactions, add pkt-line lengths and the flush-pkt () line.
Drop the SP that followed NUL before capability list.
Signed-off-by: Tay Ray Chuan
---
Documentation/technical/http-protocol.txt | 35 ---
1 file changed, 18 insertions(+), 17 deletions(-)
diff --git a/Documentation/technical/http-protocol.txt
b/Documentation/technical/http-protocol.txt
index 5141c6a..dbfff36 100644
--- a/Documentation/technical/http-protocol.txt
+++ b/Documentation/technical/http-protocol.txt
@@ -157,10 +157,10 @@ without any search/query parameters. E.g.
S: 200 OK
S:
- S: 95dcfa3633004da0049d3d0fa03f80589cbcaf31 refs/heads/maint
- S: d049f6c27a2244e12041955e262a404c7faba355 refs/heads/master
- S: 2cb58b79488a98d2721cea644875a8dd0026b115 refs/tags/v1.0
- S: a3c2e2402b99163d1d59756e5f207ae21cccba4c refs/tags/v1.0^{}
+ S: 95dcfa3633004da0049d3d0fa03f80589cbcaf31 refs/heads/maint\n
+ S: d049f6c27a2244e12041955e262a404c7faba355 refs/heads/master\n
+ S: 2cb58b79488a98d2721cea644875a8dd0026b115 refs/tags/v1.0\n
+ S: a3c2e2402b99163d1d59756e5f207ae21cccba4c refs/tags/v1.0^{}\n
The Content-Type of the returned info/refs entity SHOULD be
"text/plain; charset=utf-8", but MAY be any content type.
@@ -208,21 +208,22 @@ $GIT_URLs, and thus may pass more than parameter to the
server.
dumb server reply:
S: 200 OK
S:
- S: 95dcfa3633004da0049d3d0fa03f80589cbcaf31 refs/heads/maint
- S: d049f6c27a2244e12041955e262a404c7faba355 refs/heads/master
- S: 2cb58b79488a98d2721cea644875a8dd0026b115 refs/tags/v1.0
- S: a3c2e2402b99163d1d59756e5f207ae21cccba4c refs/tags/v1.0^{}
+ S: 95dcfa3633004da0049d3d0fa03f80589cbcaf31 refs/heads/maint\n
+ S: d049f6c27a2244e12041955e262a404c7faba355 refs/heads/master\n
+ S: 2cb58b79488a98d2721cea644875a8dd0026b115 refs/tags/v1.0\n
+ S: a3c2e2402b99163d1d59756e5f207ae21cccba4c refs/tags/v1.0^{}\n
smart server reply:
S: 200 OK
S: Content-Type: application/x-git-upload-pack-advertisement
S: Cache-Control: no-cache
S:
- S: # service=git-upload-pack
- S: 95dcfa3633004da0049d3d0fa03f80589cbcaf31 refs/heads/maint\0 multi_ack
- S: d049f6c27a2244e12041955e262a404c7faba355 refs/heads/master
- S: 2cb58b79488a98d2721cea644875a8dd0026b115 refs/tags/v1.0
- S: a3c2e2402b99163d1d59756e5f207ae21cccba4c refs/tags/v1.0^{}
+ S: 001e# service=git-upload-pack\n
+ S: 004895dcfa3633004da0049d3d0fa03f80589cbcaf31
refs/heads/maint\0multi_ack\n
+ S: 0042d049f6c27a2244e12041955e262a404c7faba355 refs/heads/master\n
+ S: 003c2cb58b79488a98d2721cea644875a8dd0026b115 refs/tags/v1.0\n
+ S: 003fa3c2e2402b99163d1d59756e5f207ae21cccba4c refs/tags/v1.0^{}\n
+ S:
Dumb Server Response
@@ -286,8 +287,8 @@ Clients MUST first perform ref discovery with
C: POST $GIT_URL/git-upload-pack HTTP/1.0
C: Content-Type: application/x-git-upload-pack-request
C:
- C: want 0a53e9ddeaddad63ad106860237bbf53411d11a7
- C: have 441b40d833fdfa93eb2908e52742248faf0ee993
+ C: 0032want 0a53e9ddeaddad63ad106860237bbf53411d11a7\n
+ C: 0032have 441b40d833fdfa93eb2908e52742248faf0ee993\n
C:
S: 200 OK
@@ -383,7 +384,7 @@ The computation to select the minimal pack proceeds as
follows
emptied C_PENDING it SHOULD include a "done" command to let
the server know it won't proceed:
- C: 0009done
+ C: 0009done\n
(s) Parse the git-upload-pack request:
@@ -447,7 +448,7 @@ Clients MUST first perform ref discovery with
C: POST $GIT_URL/git-receive-pack HTTP/1.0
C: Content-Type: application/x-git-receive-pack-request
C:
- C: 0a53e9ddeaddad63ad106860237bbf53411d11a7
441b40d833fdfa93eb2908e52742248faf0ee993 refs/heads/maint\0 report-status
+ C: 0a53e9ddeaddad63ad106860237bbf53411d11a7
441b40d833fdfa93eb2908e52742248faf0ee993 refs/heads/maint\0report-status
C:
C: PACK
--
1.8.4.rc4.527.g303b16c
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 08/14] mention different variations around $GIT_URL
Based on
From: Alex Blewitt
Message-ID:
Shawn O. Pearce spearce.org> writes:
> +URL Format
> +--
> +
> +URLs for Git repositories accessed by HTTP use the standard HTTP
> +URL syntax documented by RFC 1738, so they are of the form:
> +
> + http://:/
> +
> +Within this documentation the placeholder $GIT_URL will stand for
> +the http:// repository URL entered by the end-user.
It's worth making clear here that $GIT_URL will be the path to the repository,
rather than necessarily just the host upon which the server sits. Perhaps
including an example, like http://example:8080/repos/example.git
would make it clearer that there can be a path (and so leading to
a request like http://example:8080/repos/example.git/info/refs?service=...
It's also worth clarifying, therefore, that multiple repositories can be
served
by the same process (as with the git server today) by using different path(s).
And for those that are interested in submodules, it's worth confirming that
http://example/repos/master.git/child.git/info/refs?service= will ensure
that the repository is the 'child' git rather than anything else.
The submodule example (/master.git/child.git) seems potentially
confusing - it suggests a setup where the server has a route to a git
repo (child.git) with a parent path containing another git repo
(master.git). It is excluded lest we be seen as encouraging such
mind-boggling setups.
While providing an example $GIT_URL containing a '?' (the catch-all
gateway one), also mention a possible contradiction between the
exactly-one-param requirement and the http client implementation in Git.
Signed-off-by: Tay Ray Chuan
---
Documentation/technical/http-protocol.txt | 22 --
1 file changed, 20 insertions(+), 2 deletions(-)
diff --git a/Documentation/technical/http-protocol.txt
b/Documentation/technical/http-protocol.txt
index 2382384..d0955c2 100644
--- a/Documentation/technical/http-protocol.txt
+++ b/Documentation/technical/http-protocol.txt
@@ -22,15 +22,28 @@ URL Format
URLs for Git repositories accessed by HTTP use the standard HTTP
URL syntax documented by RFC 1738, so they are of the form:
- http://:/
+ http://:/?
Within this documentation the placeholder $GIT_URL will stand for
the http:// repository URL entered by the end-user.
-Both the "smart" and "dumb" HTTP protocols used by Git operate
+Servers SHOULD handle all requests to locations matching $GIT_URL, as
+both the "smart" and "dumb" HTTP protocols used by Git operate
by appending additional path components onto the end of the user
supplied $GIT_URL string.
+An example of a dumb client requesting for a loose object:
+
+ $GIT_URL: http://example.com:8080/git/repo.git
+ URL request:
http://example.com:8080/git/repo.git/objects/d0/49f6c27a2244e12041955e262a404c7faba355
+
+An example of a smart request to a catch-all gateway (notice how the
+'service' parameter is passed with '&', since a '?' was detected in
+$GIT_URL):
+
+ $GIT_URL: http://example.com/daemon.cgi?svc=git&q=
+ URL request:
http://example.com/daemon.cgi?svc=git&q=/info/refs&service=git-receive-pack
+
Clients MUST strip a trailing '/', if present, from the user supplied
$GIT_URL string to prevent empty path tokens ('//') from appearing
in any URL sent to a server. Compatible clients MUST expand
@@ -186,6 +199,11 @@ The request MUST contain exactly one query parameter,
name the client wishes to contact to complete the operation.
The request MUST NOT contain additional query parameters.
+TODO: "exactly" one query parameter may be too strict; see the catch-all
+gateway $GIT_URL for an example where more than one parameter is passed.
+In fact, the http client implementation in Git can handle similar
+$GIT_URLs, and thus may pass more than parameter to the server.
+
C: GET $GIT_URL/info/refs?service=git-upload-pack HTTP/1.0
dumb server reply:
--
1.8.4.rc4.527.g303b16c
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
