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.
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...
[ message continues ]

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,
???
-

Remnant of a change to that file which was later reverted but mtime

doesn't match the index.
Nicolas

-

They are _not_ even in 'pu'.  I am talking about things that
Double 'd'?
-

Remember that positive comments are by default much less verbose than 
$ touch t/Makefile

$ git diff
Nicolas

-

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.
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

-

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

-