Juergen Ruehle <j.ruehle@xxxxxxxx> 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)"? -- 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
