Re: Why repository grows after "git gc"? / Purpose of *.keep files?

From: Junio C Hamano <gitster@pobox.com>
Date: May 14, 2008, 17:03 UTC
Message-ID: <7vd4noq0ms.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <18474.44155.823000.368851@lapjr.intranet.kiel.bmiag.de>

Juergen Ruehle <j.ruehle@bmiag.de> writes:

Show 6 quoted lines

> Previously --unpacked would filter on the commit level, ignoring whether the
> objects comprising the commit actually were packed or unpacked.
>
> This makes it impossible to store e.g. excessively large blobs in
> different packs from the commits referencing them, since the next repack of
> such a commit will suck all referenced blobs into the same pack.

Doesn't this patch essentially make the --unpacked option to rev-list and the --incremental option to pack-objects the same thing?

The semantics of the --unpacked has been defined that way from the very beginning, and I've always wondered how the option and --incremental should interact with each other. I think the approach your patch takes makes sense.

> This change moves the unpacked check to the output stage and no longer checks
> the flag during commit traversal and adds a trivial test demonstrating the
> problem.

Sign-off?

Show 11 quoted lines

> diff --git a/t/t6009-rev-list-unpacked.sh b/t/t6009-rev-list-unpacked.sh
> new file mode 100644
> index 0000000..6b65e83
> --- /dev/null
> +++ b/t/t6009-rev-list-unpacked.sh
> @@ -0,0 +1,32 @@
> ...
> +test_expect_success \
> +    'unpacked object list should not contain foo' '
> +    test_must_fail "git rev-list --all --unpacked --objects | grep -q \"foo\""
> +'

Ahhh.  Ugly but don't you mean "! (rev-list | grep)"?