When we calculate the "wants" and "haves" for a pack, we
only add the objects in the boundary commits as preferred
bases. However, we know that every object reachable from the
"haves" could be a preferred base.
We probably don't want to add these to our preferred base
list, because they would clog the delta-search window.
However, there is no reason we cannot reuse an on-disk delta
against such a deep "have" base, avoiding the delta search
for that object altogether.
Signed-off-by: Jeff King <peff@xxxxxxxx>
---
builtin/pack-objects.c | 16 +++++++++++++++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c
index 7950c43..92bd682 100644
--- a/builtin/pack-objects.c
+++ b/builtin/pack-objects.c
@@ -53,6 +53,7 @@ static unsigned long pack_size_limit;
static int depth = 50;
static int delta_search_threads;
static int pack_to_stdout;
+static int thin = 0;
static int num_preferred_base;
static struct progress *progress_state;
static int pack_compression_level = Z_DEFAULT_COMPRESSION;
@@ -1419,6 +1420,20 @@ static void check_object(struct object_entry *entry)
base_entry->delta_child = entry;
unuse_pack(&w_curs);
return;
+ } else if(thin && base_ref && bitmap_have(base_ref)) {
+ entry->type = entry->in_pack_type;
+ entry->delta_size = entry->size;
+ /*
+ * XXX we'll leak this, but it's probably OK
+ * since we'll exit immediately after the packing
+ * is done
+ */
+ entry->delta = xcalloc(1, sizeof(*entry->delta));
+ hashcpy(entry->delta->idx.sha1, base_ref);
+ entry->delta->preferred_base = 1;
+ entry->delta->filled = 1;
+ unuse_pack(&w_curs);
+ return;
}
if (entry->type) {
@@ -2559,7 +2574,6 @@ static int option_parse_ulong(const struct option *opt,
int cmd_pack_objects(int argc, const char **argv, const char *prefix)
{
int use_internal_rev_list = 0;
- int thin = 0;
int all_progress_implied = 0;
const char *rp_av[6];
int rp_ac = 0;
--
1.9.1.601.g7ec968e
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html