Thread (9 messages) flat view 9 messages, 3 authors, 2016-06-15

Re: [PATCH] Add '--create-index' to git-unpack-objects

From: Johannes Schindelin <hidden>
Date: 2016-06-15 22:42:08

Hi,

On Wed, 12 Oct 2005, Sergey Vlasov wrote:
On Wed, 12 Oct 2005 13:02:36 +0200 (CEST) Johannes Schindelin wrote:
quoted
 static void write_object(void *buf, unsigned long size, const char *type)
 {
 	unsigned char sha1[20];
-	if (write_sha1_file(buf, size, type, sha1) < 0)
+	if (create_index) {
+		char header[100];
+		SHA_CTX c;
+
+		SHA1_Init(&c);
+		SHA1_Update(&c, header, 1+sprintf(header, "%s %lu", type, size));
+		SHA1_Update(&c, buf, size);
+		SHA1_Final(current_sha1, &c);
+	} else if (write_sha1_file(buf, size, type, sha1) < 0)
 		die("failed to write object");
Sorry, but this cannot work.  git-unpack-objects does a streaming
unpack, and it needs to be able to read back the objects it has written
out previously (in case a delta later in the stream references some
older object).
Even worse, my code did not anticipate that the base objects could have 
been handled earlier (and thus the deltas would never be resolved).
Saving unpacked objects in memory would obviously be unacceptable.
Actually, this is what git-unpack-objects does. All unresolved deltas are 
stored in a linked list, and handled later.

Of course, it would be nicer to use a seekable file if you have one. But 
then, I am not at all sure that base objects should be allowed to come 
later in the file: since the delta chains must not be cyclic, the objects
can be sorted. Thus, it could be guaranteed that the base objects are 
already unpacked when unpacking the derived object.

Ciao,
Dscho
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help