From: Nicolas Pitre <nico@cam.org>
To: "Shawn O. Pearce" <spearce@spearce.org>
Cc: Junio C Hamano <gitster@pobox.com>, git@vger.kernel.org
Subject: Re: RFC: Allow missing objects during packing
Date: Tue, 12 Aug 2008 00:44:11 -0400 (EDT) [thread overview]
Message-ID: <alpine.LFD.1.10.0808120023250.22892@xanadu.home> (raw)
In-Reply-To: <20080812012859.GT26363@spearce.org>
On Mon, 11 Aug 2008, Shawn O. Pearce wrote:
> > Junio C Hamano <gitster@pobox.com> wrote:
> > > If the check is only about a thin delta base that is not going to be
> > > transmit, I'd agree. But I do not see how you are distinguishing that
> > > case and the case where an object you are actually sending is missing (in
> > > which case we would want to error out, wouldn't we?)
>
> Turns out to be pretty simple I think. We just delay the
> error handling for ->type < 0 until write_object(). If we
> get this far we know we wanted to include the object but
> we really don't have it. Up until that point its fine
> for us to get objects which are missing, we'll just wind
> up with a suboptimal pack.
If you're going to die anyway due to an object with unknown type, better
do so _before_ going through the delta search phase and leaving a
partial pack behind. IOW, the type check can be performed in
prepare_pack() instead of write_object() like:
diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
index 2dadec1..01ab49c 100644
--- a/builtin-pack-objects.c
+++ b/builtin-pack-objects.c
@@ -1722,8 +1733,12 @@ static void prepare_pack(int window, int depth)
if (entry->no_try_delta)
continue;
- if (!entry->preferred_base)
+ if (!entry->preferred_base) {
nr_deltas++;
+ if (entry->type < 0)
+ die("unable to get type of object %s",
+ sha1_to_hex(entry->idx.sha1));
+ }
delta_list[n++] = entry;
}
Also a comment in check_object() mentioning where the return value of
sha1_object_info() is verified would be in order.
And I also agree with Junio about a test script for this so the usage is
fully demonstrated, and to ensure it keeps on working as intended
(most people will simply never exercise this otherwise).
Nicolas
next prev parent reply other threads:[~2008-08-12 4:52 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-08-11 18:28 RFC: Allow missing objects during packing Shawn O. Pearce
2008-08-11 22:39 ` Junio C Hamano
2008-08-11 22:44 ` Shawn O. Pearce
2008-08-12 1:28 ` Shawn O. Pearce
2008-08-12 2:08 ` Junio C Hamano
2008-08-12 4:44 ` Nicolas Pitre [this message]
2008-08-12 16:41 ` [PATCH] pack-objects: Allow missing base objects when creating thin packs Shawn O. Pearce
2008-08-12 18:12 ` Nicolas Pitre
2008-08-12 18:18 ` Shawn O. Pearce
2008-08-12 18:26 ` Nicolas Pitre
2008-08-12 18:31 ` [PATCH v2] " Shawn O. Pearce
2008-08-12 18:43 ` Nicolas Pitre
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=alpine.LFD.1.10.0808120023250.22892@xanadu.home \
--to=nico@cam.org \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=spearce@spearce.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).