Re: Why repository grows after "git gc"? / Purpose of *.keep files?
- From
Linus Torvalds <torvalds@linux-foundation.org>
- Date
- May 14, 2008, 20:06 UTC
- Message-ID
- <alpine.LFD.1.10.0805141247560.3019@woody.linux-foundation.org>
- In-Reply-To
- <18474.44155.823000.368851@lapjr.intranet.kiel.bmiag.de>
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);