threads / patch / 7586

patch, 10 partsallow forcing index v2 and 64-bit offset treshold

Subject: [PATCH 11/10] allow forcing index v2 and 64-bit offset treshold

## tl;dr

8 messages between Apr 9, 2007 and Apr 10, 2007. Diffs are folded; open one to read it.

replies: 7people: 3as markdown or json

Nicolas Pitre· Apr 9, 2007, 21:32 UTC · lore

This is necessary for testing the new capabilities in some automated way without having an actual 4GB+ pack.

Signed-off-by: Nicolas Pitre <nico@cam.org>
---
I should write some tests... when I have more time.
Show changes to 2 files +32 −6

builtin-pack-objects.c, index-pack.c

diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
index 8cf2871..099dea0 100644
--- a/builtin-pack-objects.c
+++ b/builtin-pack-objects.c
@@ -597,6 +597,9 @@ static off_t write_pack_file(void)
 	return last_obj_offset;
 }
 
+static uint32_t index_default_version = 1;
+static uint32_t index_off32_limit = 0x7fffffff;
+
 static void write_index_file(off_t last_obj_offset)
 {
 	uint32_t i;
@@ -608,7 +611,7 @@ static void write_index_file(off_t last_obj_offset)
 	uint32_t index_version;
 
 	/* if last object's offset is >= 2^31 we should use index V2 */
-	index_version = (last_obj_offset >> 31) ? 2 : 1;
+	index_version = (last_obj_offset >> 31) ? 2 : index_default_version;
 
 	/* index versions 2 and above need a header */
 	if (index_version >= 2) {
@@ -664,7 +667,7 @@ static void write_index_file(off_t last_obj_offset)
 		list = sorted_by_sha;
 		for (i = 0; i < nr_objects; i++) {
 			struct object_entry *entry = *list++;
-			uint32_t offset = (entry->offset <= 0x7fffffff) ?
+			uint32_t offset = (entry->offset <= index_off32_limit) ?
 				entry->offset : (0x80000000 | nr_large_offset++);
 			offset = htonl(offset);
 			sha1write(f, &offset, 4);
@@ -675,7 +678,7 @@ static void write_index_file(off_t last_obj_offset)
 		while (nr_large_offset) {
 			struct object_entry *entry = *list++;
 			uint64_t offset = entry->offset;
-			if (offset > 0x7fffffff) {
+			if (offset > index_off32_limit) {
 				uint32_t split[2];
 				split[0]        = htonl(offset >> 32);
 				split[1] = htonl(offset & 0xffffffff);
@@ -1714,6 +1717,17 @@ int cmd_pack_objects(int argc, const char **argv, const char *prefix)
 			rp_av[1] = "--objects-edge";
 			continue;
 		}
+		if (!prefixcmp(arg, "--index-version=")) {
+			char *c;
+			index_default_version = strtoul(arg + 16, &c, 10);
+			if (index_default_version > 2)
+				die("bad %s", arg);
+			if (*c == ',')
+				index_off32_limit = strtoul(c+1, &c, 0);
+			if (*c || index_off32_limit & 0x80000000)
+				die("bad %s", arg);
+			continue;
+		}
 		usage(pack_usage);
 	}
 
diff --git a/index-pack.c b/index-pack.c
index a833f64..7aad261 100644
--- a/index-pack.c
+++ b/index-pack.c
@@ -671,6 +671,9 @@ static void readjust_pack_header_and_sha1(unsigned char *sha1)
 	write_or_die(output_fd, sha1, 20);
 }
 
+static uint32_t index_default_version = 1;
+static uint32_t index_off32_limit = 0x7fffffff;
+
 static int sha1_compare(const void *_a, const void *_b)
 {
 	struct object_entry *a = *(struct object_entry **)_a;
@@ -719,7 +722,7 @@ static const char *write_index_file(const char *index_name, unsigned char *sha1)
 	f = sha1fd(fd, index_name);
 
 	/* if last object's offset is >= 2^31 we should use index V2 */
-	index_version = (objects[nr_objects-1].offset >> 31) ? 2 : 1;
+	index_version = (objects[nr_objects-1].offset >> 31) ? 2 : index_default_version;
 
 	/* index versions 2 and above need a header */
 	if (index_version >= 2) {
@@ -779,7 +782,7 @@ static const char *write_index_file(const char *index_name, unsigned char *sha1)
 		list = sorted_by_sha;
 		for (i = 0; i < nr_objects; i++) {
 			struct object_entry *obj = *list++;
-			uint32_t offset = (obj->offset <= 0x7fffffff) ?
+			uint32_t offset = (obj->offset <= index_off32_limit) ?
 				obj->offset : (0x80000000 | nr_large_offset++);
 			offset = htonl(offset);
 			sha1write(f, &offset, 4);
@@ -790,7 +793,7 @@ static const char *write_index_file(const char *index_name, unsigned char *sha1)
 		while (nr_large_offset) {
 			struct object_entry *obj = *list++;
 			uint64_t offset = obj->offset;
-			if (offset > 0x7fffffff) {
+			if (offset > index_off32_limit) {
 				uint32_t split[2];
 				split[0]	= htonl(offset >> 32);
 				split[1] = htonl(offset & 0xffffffff);
@@ -929,6 +932,15 @@ int main(int argc, char **argv)
 				if (index_name || (i+1) >= argc)
 					usage(index_pack_usage);
 				index_name = argv[++i];
+			} else if (!prefixcmp(arg, "--index-version=")) {
+				char *c;
+				index_default_version = strtoul(arg + 16, &c, 10);
+				if (index_default_version > 2)
+					die("bad %s", arg);
+				if (*c == ',')
+					index_off32_limit = strtoul(c+1, &c, 0);
+				if (*c || index_off32_limit & 0x80000000)
+					die("bad %s", arg);
 			} else
 				usage(index_pack_usage);
 			continue;
ddiff --git a/t/Makefile b/t/Makefile
Junio C Hamano· Apr 9, 2007, 22:28 UTC · re: Nicolas Pitre · lore

Re: [PATCH 11/10] allow forcing index v2 and 64-bit offset treshold

Nicolas Pitre <nico@cam.org> writes:
Show 7 quoted lines
> This is necessary for testing the new capabilities in some automated 
> way without having an actual 4GB+ pack.
>
> Signed-off-by: Nicolas Pitre <nico@cam.org>
> ---
>
> I should write some tests... when I have more time.

It appears everybody is short of time. I am having two troubles. Nobody seems to have positive nor negative reports or comments on what are cooking in 'next' so nothing can graduate, and I am behind list discussions on certain areas myself.

> ddiff --git a/t/Makefile b/t/Makefile
???
Bill Lear· Apr 9, 2007, 22:33 UTC · re: Junio C Hamano · lore

Re: [PATCH 11/10] allow forcing index v2 and 64-bit offset treshold

On Monday, April 9, 2007 at 15:28:56 (-0700) Junio C Hamano writes:
Show 8 quoted lines
>Nicolas Pitre <nico@cam.org> writes:
>>...
>> I should write some tests... when I have more time.
>
>It appears everybody is short of time.  I am having two
>troubles.  Nobody seems to have positive nor negative reports or
>comments on what are cooking in 'next' so nothing can graduate,
>and I am behind list discussions on certain areas myself.

Have you considered a git holiday? Just black out the calendar for a week every once in a while to allow people to catch up on their "real" jobs, and allow things to settle?

Bill
Nicolas Pitre· Apr 9, 2007, 23:04 UTC · re: Junio C Hamano · lore

Re: [PATCH 11/10] allow forcing index v2 and 64-bit offset treshold

On Mon, 9 Apr 2007, Junio C Hamano wrote:
Show 14 quoted lines
> Nicolas Pitre <nico@cam.org> writes:
> 
> > This is necessary for testing the new capabilities in some automated 
> > way without having an actual 4GB+ pack.
> >
> > Signed-off-by: Nicolas Pitre <nico@cam.org>
> > ---
> >
> > I should write some tests... when I have more time.
> 
> It appears everybody is short of time.  I am having two
> troubles.  Nobody seems to have positive nor negative reports or
> comments on what are cooking in 'next' so nothing can graduate,
> and I am behind list discussions on certain areas myself.
At least my latest patch series received two positive reviews.  ;-)
> > ddiff --git a/t/Makefile b/t/Makefile
> 
> ???

Remnant of a change to that file which was later reverted but mtime doesn't match the index.

Nicolas
Junio C Hamano· Apr 10, 2007, 00:23 UTC · re: Nicolas Pitre · lore

Re: [PATCH 11/10] allow forcing index v2 and 64-bit offset treshold

Nicolas Pitre <nico@cam.org> writes:
Show 18 quoted lines
> On Mon, 9 Apr 2007, Junio C Hamano wrote:
>
>> Nicolas Pitre <nico@cam.org> writes:
>> 
>> > This is necessary for testing the new capabilities in some automated 
>> > way without having an actual 4GB+ pack.
>> >
>> > Signed-off-by: Nicolas Pitre <nico@cam.org>
>> > ---
>> >
>> > I should write some tests... when I have more time.
>> 
>> It appears everybody is short of time.  I am having two
>> troubles.  Nobody seems to have positive nor negative reports or
>> comments on what are cooking in 'next' so nothing can graduate,
>> and I am behind list discussions on certain areas myself.
>
> At least my latest patch series received two positive reviews.  ;-)

They are _not_ even in 'pu'. I am talking about things that have been cooking.

Show 6 quoted lines
>> > ddiff --git a/t/Makefile b/t/Makefile
>> 
>> ???
>
> Remnant of a change to that file which was later reverted but mtime 
> doesn't match the index.
Double 'd'?
Nicolas Pitre· Apr 10, 2007, 01:03 UTC · re: Junio C Hamano · lore

Re: [PATCH 11/10] allow forcing index v2 and 64-bit offset treshold

On Mon, 9 Apr 2007, Junio C Hamano wrote:
Show 13 quoted lines
> Nicolas Pitre <nico@cam.org> writes:
> 
> > On Mon, 9 Apr 2007, Junio C Hamano wrote:
> >
> >> It appears everybody is short of time.  I am having two
> >> troubles.  Nobody seems to have positive nor negative reports or
> >> comments on what are cooking in 'next' so nothing can graduate,
> >> and I am behind list discussions on certain areas myself.
> >
> > At least my latest patch series received two positive reviews.  ;-)
> 
> They are _not_ even in 'pu'.  I am talking about things that
> have been cooking.

Remember that positive comments are by default much less verbose than negative ones. In other words, no news is probably good news.

> >> > ddiff --git a/t/Makefile b/t/Makefile
> >> 
> >> ???

$ touch t/Makefile $ git diff

Nicolas
Junio C Hamano· Apr 10, 2007, 07:31 UTC · re: Nicolas Pitre · lore

Re: [PATCH 11/10] allow forcing index v2 and 64-bit offset treshold

Nicolas Pitre <nico@cam.org> writes:
Show 5 quoted lines
>> They are _not_ even in 'pu'.  I am talking about things that
>> have been cooking.
>
> Remember that positive comments are by default much less verbose than 
> negative ones. In other words, no news is probably good news.
No news means one or more of the following:
 - Immediately before 1.5.1, people were asked to test 'master'
   rigorously, and they did, and they are still on 'master'.
   Nobody noticed breakages in 'next'.
 - Some people use 'next' but the new features, fixes or
   enhancements the topics introduce are totally irrelevant to
   how they use git, so problems are not noticed.  This would
   indicate that some of the topics may not even deserve to
   be in 'next'.
 - Most people are generally 'wait and see' and even when warned
   that some new features cooking in 'next' may change the user
   experience (even in good ways), they do not try to see if the
   change may adversely affect them to voice their objection
   early, to catch the changes they do not like before they
   graduate to 'master', and then complain.  This would indicate
   that it is futile to have 'next' as a holding area.  It would
   be more effective to push out unproven stuff on 'master' to
   make sure people complain.
None of the above does not sound a good news at all to me.
Show 6 quoted lines
>> >> > ddiff --git a/t/Makefile b/t/Makefile
>> >> 
>> >> ???
>
> $ touch t/Makefile
> $ git diff
This still does not give me doubled d in diff.
Nicolas Pitre· Apr 10, 2007, 13:23 UTC · re: Junio C Hamano · lore

Re: [PATCH 11/10] allow forcing index v2 and 64-bit offset treshold

On Tue, 10 Apr 2007, Junio C Hamano wrote:
Show 10 quoted lines
> Nicolas Pitre <nico@cam.org> writes:
> 
> >> >> > ddiff --git a/t/Makefile b/t/Makefile
> >> >> 
> >> >> ???
> >
> > $ touch t/Makefile
> > $ git diff
> 
> This still does not give me doubled d in diff.
Ah!  Maybe I tried to delete it ('dd' in vi) and screwed it somehow.
Nicolas

← back to recent threads