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

[Junio C Hamano <gitster@pobox.com>]

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

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

> 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)"?