All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Shawn O. Pearce" <spearce@spearce.org>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, Nicolas Pitre <nico@cam.org>
Subject: Re: RFC: Allow missing objects during packing
Date: Mon, 11 Aug 2008 18:28:59 -0700	[thread overview]
Message-ID: <20080812012859.GT26363@spearce.org> (raw)
In-Reply-To: <20080811224404.GQ26363@spearce.org>

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

We also don't even need to report the error from sha1_object_info
as it already issues an error message (see sha1_loose_object_info).

--8<--
pack-objects: Allow missing base objects when creating thin packs

If we are building a thin pack and one of the base objects we would
consider for deltification is missing its OK, the other side already
has that base object.  We may be able to get a delta from another
object, or we can simply send the new object whole (no delta).

This allows a shallow clone which may have only commits and trees
(but only partial blobs) to generate a pack for a fetch client,
so the shallow clone only needs to contain objects that are not
in the common base.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
 builtin-pack-objects.c |    5 ++---
 1 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
index 2dadec1..187cb19 100644
--- a/builtin-pack-objects.c
+++ b/builtin-pack-objects.c
@@ -243,6 +243,8 @@ static unsigned long write_object(struct sha1file *f,
 		crc32_begin(f);
 
 	type = entry->type;
+	if (type < 0)
+		die("unable to read object %s", sha1_to_hex(entry->idx.sha1));
 
 	/* write limit if limited packsize and not first object */
 	limit = pack_size_limit && nr_written ?
@@ -1096,9 +1098,6 @@ static void check_object(struct object_entry *entry)
 	}
 
 	entry->type = sha1_object_info(entry->idx.sha1, &entry->size);
-	if (entry->type < 0)
-		die("unable to get type of object %s",
-		    sha1_to_hex(entry->idx.sha1));
 }
 
 static int pack_offset_sort(const void *_a, const void *_b)
-- 
1.6.0.rc2.22.g71b99

-- 
Shawn.

  reply	other threads:[~2008-08-12  1:30 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 [this message]
2008-08-12  2:08       ` Junio C Hamano
2008-08-12  4:44       ` Nicolas Pitre
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=20080812012859.GT26363@spearce.org \
    --to=spearce@spearce.org \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=nico@cam.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.