rev-list: handle flags for --indexed-objects

When a traversal sees the --indexed-objects option, it adds
all blobs and valid cache-trees from the index to the
traversal using add_index_objects_to_pending(). But that
function totally ignores its flags parameter!

That means that doing:

  git rev-list --objects --indexed-objects

and

  git rev-list --objects --not --indexed-objects

produce the same output, because we ignore the UNINTERESTING
flag when walking the index in the second example.

Nobody noticed because this feature was added as a way for
tools like repack to increase their coverage of reachable
objects, meaning it would only be used like the first
example above.

But since it's user facing (and because the documentation
describes it "as if the objects are listed on the command
line"), we should make sure the negative case behaves
sensibly.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This commit is contained in:
Jeff King
2018-11-02 01:22:59 -04:00
committed by Junio C Hamano
parent d582ea202b
commit b4cfcde4db
2 changed files with 16 additions and 6 deletions

View File

@ -90,11 +90,18 @@ test_expect_success 'rev-list can show index objects' '
9200b628cf9dc883a85a7abc8d6e6730baee589c two
EOF
echo only-in-index >only-in-index &&
test_when_finished "git reset --hard" &&
git add only-in-index &&
git rev-list --objects --indexed-objects >actual &&
test_cmp expect actual
'
test_expect_success 'rev-list can negate index objects' '
git rev-parse HEAD >expect &&
git rev-list -1 --objects HEAD --not --indexed-objects >actual &&
test_cmp expect actual
'
test_expect_success '--bisect and --first-parent can not be combined' '
test_must_fail git rev-list --bisect --first-parent HEAD
'