(command.CommandList children: [ (command.ShAssignment pairs: [ (assign_pair lhs: (sh_lhs_expr.Name name:test_description) op: assign_op.Equal rhs: { (SQ <'test handling of inter-pack delta cycles during repack\n'> <'\n'> < 'The goal here is to create a situation where we have two blobs, A and B, with A\n' > <'as a delta against B in one pack, and vice versa in the other. Then if we can\n'> <'persuade a full repack to find A from one pack and B from the other, that will\n'> <'give us a cycle when we attempt to reuse those deltas.\n'> <'\n'> <'The trick is in the "persuade" step, as it depends on the internals of how\n'> <'pack-objects picks which pack to reuse the deltas from. But we can assume\n'> <'that it does so in one of two general strategies:\n'> <'\n'> <' 1. Using a static ordering of packs. In this case, no inter-pack cycles can\n'> <' happen. Any objects with a delta relationship must be present in the same\n'> <' pack (i.e., no "--thin" packs on disk), so we will find all related objects\n'> <' from that pack. So assuming there are no cycles within a single pack (and\n'> <' we avoid generating them via pack-objects or importing them via\n'> <' index-pack), then our result will have no cycles.\n'> <'\n'> <' So this case should pass the tests no matter how we arrange things.\n'> <'\n'> <' 2. Picking the next pack to examine based on locality (i.e., where we found\n'> <' something else recently).\n'> <'\n'> < ' In this case, we want to make sure that we find the delta versions of A and\n' > <' B and not their base versions. We can do this by putting two blobs in each\n'> <' pack. The first is a "dummy" blob that can only be found in the pack in\n'> <' question. And then the second is the actual delta we want to find.\n'> <'\n'> < ' The two blobs must be present in the same tree, not present in other trees,\n' > <' and the dummy pathname must sort before the delta path.\n'> <'\n'> <'The setup below focuses on case 2. We have two commits HEAD and HEAD^, each\n'> <'which has two files: "dummy" and "file". Then we can make two packs which\n'> <'contain:\n'> <'\n'> <' [pack one]\n'> <' HEAD:dummy\n'> <' HEAD:file (as delta against HEAD^:file)\n'> <' HEAD^:file (as base)\n'> <'\n'> <' [pack two]\n'> <' HEAD^:dummy\n'> <' HEAD^:file (as delta against HEAD:file)\n'> <' HEAD:file (as base)\n'> <'\n'> <'Then no matter which order we start looking at the packs in, we know that we\n'> <'will always find a delta for "file", because its lookup will always come\n'> <'immediately after the lookup for "dummy".\n'> ) } spids: [4] ) ] ) (C {<.>} {<'./test-lib.sh'>}) (command.ShFunction name: make_pack body: (BraceGroup children: [ (command.Pipeline children: [ (BraceGroup children: [ (C {<printf>} {(SQ <'%s\\n'>)} { (DQ <-> (command_sub left_token: <Id.Left_DollarParen '$('> child: (C {<git>} {<rev-parse>} {($ Id.VSub_Number '$2')}) ) ) } ) (C {<printf>} {(SQ <'%s dummy\\n'>)} { (DQ (command_sub left_token: <Id.Left_DollarParen '$('> child: (C {<git>} {<rev-parse>} {($ Id.VSub_Number '$1') <Id.Lit_Colon ':'> <dummy>} ) ) ) } ) (C {<printf>} {(SQ <'%s file\\n'>)} { (DQ (command_sub left_token: <Id.Left_DollarParen '$('> child: (C {<git>} {<rev-parse>} {($ Id.VSub_Number '$1') <Id.Lit_Colon ':'> <file>} ) ) ) } ) ] ) (C {<git>} {<pack-objects>} {<--stdout>}) (C {<git>} {<index-pack>} {<--stdin>} {<--fix-thin>}) ] negated: F ) ] ) ) (C {<test_expect_success>} {(SQ <setup>)} { (SQ <'\n'> <'\ttest-genrandom base 4096 >base &&\n'> <'\tfor i in one two\n'> <'\tdo\n'> <'\t\t# we want shared content here to encourage deltas...\n'> <'\t\tcp base file &&\n'> <'\t\techo $i >>file &&\n'> <'\n'> <'\t\t# ...whereas dummy should be short, because we do not want\n'> <'\t\t# deltas that would create duplicates when we --fix-thin\n'> <'\t\techo $i >dummy &&\n'> <'\n'> <'\t\tgit add file dummy &&\n'> <'\t\ttest_tick &&\n'> <'\t\tgit commit -m $i ||\n'> <'\t\treturn 1\n'> <'\tdone &&\n'> <'\n'> <'\tmake_pack HEAD^ HEAD &&\n'> <'\tmake_pack HEAD HEAD^\n'> ) } ) (C {<test_expect_success>} {(SQ <repack>)} { (SQ <'\n'> <'\t# We first want to check that we do not have any internal errors,\n'> <'\t# and also that we do not hit the last-ditch cycle-breaking code\n'> <'\t# in write_object(), which will issue a warning to stderr.\n'> <'\t>expect &&\n'> <'\tgit repack -ad 2>stderr &&\n'> <'\ttest_cmp expect stderr &&\n'> <'\n'> <'\t# And then double-check that the resulting pack is usable (i.e.,\n'> <'\t# we did not fail to notice any cycles). We know we are accessing\n'> <'\t# the objects via the new pack here, because "repack -d" will have\n'> <'\t# removed the others.\n'> <'\tgit cat-file blob HEAD:file >/dev/null &&\n'> <'\tgit cat-file blob HEAD^:file >/dev/null\n'> ) } ) (C {<test_done>}) ] )