Re: Why repository grows after "git gc"? / Purpose of *.keep files?
From: Junio C Hamano <hidden>
Date: 2016-06-15 22:44:36
Juergen Ruehle [off-list ref] 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?
quoted hunk
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)"?