From: Junio C Hamano <gitster@pobox.com>
To: git@vger.kernel.org
Subject: [PATCH] sha1_file.c: "legacy" is really the current format
Date: Wed, 08 Jun 2011 11:29:01 -0700 [thread overview]
Message-ID: <7vaads2n4i.fsf@alter.siamese.dyndns.org> (raw)
Every time I look at the read-loose-object codepath, legacy_loose_object()
function makes my brain go through mental contortion. When we were playing
with the experimental loose object format, it may have made sense to call
the traditional format "legacy", in the hope that the experimental one
will some day replace it to become official, but it never happened.
This renames the function (and negates its return value) to detect if we
are looking at the experimental format, and move the code around in its
caller which used to do "if we are looing at legacy, do this special case,
otherwise the normal case is this". The codepath to read from the loose
objects in experimental format is the "unlikely" case.
Someday after Git 2.0, we should drop the support of this format.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
sha1_file.c | 62 +++++++++++++++++++++++++++++++---------------------------
1 files changed, 33 insertions(+), 29 deletions(-)
diff --git a/sha1_file.c b/sha1_file.c
index 064a330..697f4a4 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -1205,20 +1205,29 @@ static void *map_sha1_file(const unsigned char *sha1, unsigned long *size)
return map;
}
-static int legacy_loose_object(unsigned char *map)
+/*
+ * There used to be a second loose object header format which
+ * was meant to mimic the in-pack format, allowing for direct
+ * copy of the object data. This format turned up not to be
+ * really worth it and we no longer write loose objects in that
+ * format.
+ */
+static int experimental_loose_object(unsigned char *map)
{
unsigned int word;
/*
* Is it a zlib-compressed buffer? If so, the first byte
* must be 0x78 (15-bit window size, deflated), and the
- * first 16-bit word is evenly divisible by 31
+ * first 16-bit word is evenly divisible by 31. If so,
+ * we are looking at the official format, not the experimental
+ * one.
*/
word = (map[0] << 8) + map[1];
if (map[0] == 0x78 && !(word % 31))
- return 1;
- else
return 0;
+ else
+ return 1;
}
unsigned long unpack_object_header_buffer(const unsigned char *buf,
@@ -1262,34 +1271,29 @@ static int unpack_sha1_header(z_stream *stream, unsigned char *map, unsigned lon
stream->next_out = buffer;
stream->avail_out = bufsiz;
- if (legacy_loose_object(map)) {
- git_inflate_init(stream);
- return git_inflate(stream, 0);
- }
-
+ if (experimental_loose_object(map)) {
+ /*
+ * The old experimental format we no longer produce;
+ * we can still read it.
+ */
+ used = unpack_object_header_buffer(map, mapsize, &type, &size);
+ if (!used || !valid_loose_object_type[type])
+ return -1;
+ map += used;
+ mapsize -= used;
- /*
- * There used to be a second loose object header format which
- * was meant to mimic the in-pack format, allowing for direct
- * copy of the object data. This format turned up not to be
- * really worth it and we don't write it any longer. But we
- * can still read it.
- */
- used = unpack_object_header_buffer(map, mapsize, &type, &size);
- if (!used || !valid_loose_object_type[type])
- return -1;
- map += used;
- mapsize -= used;
+ /* Set up the stream for the rest.. */
+ stream->next_in = map;
+ stream->avail_in = mapsize;
+ git_inflate_init(stream);
- /* Set up the stream for the rest.. */
- stream->next_in = map;
- stream->avail_in = mapsize;
+ /* And generate the fake traditional header */
+ stream->total_out = 1 + snprintf(buffer, bufsiz, "%s %lu",
+ typename(type), size);
+ return 0;
+ }
git_inflate_init(stream);
-
- /* And generate the fake traditional header */
- stream->total_out = 1 + snprintf(buffer, bufsiz, "%s %lu",
- typename(type), size);
- return 0;
+ return git_inflate(stream, 0);
}
static void *unpack_sha1_rest(z_stream *stream, void *buffer, unsigned long size, const unsigned char *sha1)
reply other threads:[~2011-06-08 18:29 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7vaads2n4i.fsf@alter.siamese.dyndns.org \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).