On Wed, 14 May 2008, Juergen Ruehle wrote:
>
> Previously --unpacked would filter on the commit level, ignoring whether the
> objects comprising the commit actually were packed or unpacked.
I think this patch is correct, but I wonder why you removed the pruning
from revision.c? Why do we want to process trees for commits that aren't
going to be shown? This is going to slow down things a lot, and we've long
had the rule that commits have to be complete in the packs that are kept
(ie you should never have a pack-file that points to an unpacked object).
So I'd suggest a slightly less intrusive patch (untested!!) instead, which
leaves the commit object logic alone.
(Your test-case should obviously be merged regardless)
Linus
---
list-objects.c | 8 ++++++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/list-objects.c b/list-objects.c
index c8b8375..8cb05ca 100644
--- a/list-objects.c
+++ b/list-objects.c
@@ -172,8 +172,12 @@ void traverse_commit_list(struct rev_info *revs,
die("unknown pending object %s (%s)",
sha1_to_hex(obj->sha1), name);
}
- for (i = 0; i < objects.nr; i++)
- show_object(&objects.objects[i]);
+ for (i = 0; i < objects.nr; i++) {
+ struct object_array_entry *entry = &objects.objects[i];
+ if (revs->unpacked && has_sha1_pack(entry->item->sha1, revs->ignore_packed))
+ continue;
+ show_object(entry);
+ }
free(objects.objects);
if (revs->pending.nr) {
free(revs->pending.objects);
--
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
