| 1 | #!/bin/sh |
| 2 | |
| 3 | test_description='test handling of inter-pack delta cycles during repack |
| 4 | |
| 5 | The goal here is to create a situation where we have two blobs, A and B, with A |
| 6 | as a delta against B in one pack, and vice versa in the other. Then if we can |
| 7 | persuade a full repack to find A from one pack and B from the other, that will |
| 8 | give us a cycle when we attempt to reuse those deltas. |
| 9 | |
| 10 | The trick is in the "persuade" step, as it depends on the internals of how |
| 11 | pack-objects picks which pack to reuse the deltas from. But we can assume |
| 12 | that it does so in one of two general strategies: |
| 13 | |
| 14 | 1. Using a static ordering of packs. In this case, no inter-pack cycles can |
| 15 | happen. Any objects with a delta relationship must be present in the same |
| 16 | pack (i.e., no "--thin" packs on disk), so we will find all related objects |
| 17 | from that pack. So assuming there are no cycles within a single pack (and |
| 18 | we avoid generating them via pack-objects or importing them via |
| 19 | index-pack), then our result will have no cycles. |
| 20 | |
| 21 | So this case should pass the tests no matter how we arrange things. |
| 22 | |
| 23 | 2. Picking the next pack to examine based on locality (i.e., where we found |
| 24 | something else recently). |
| 25 | |
| 26 | In this case, we want to make sure that we find the delta versions of A and |
| 27 | B and not their base versions. We can do this by putting two blobs in each |
| 28 | pack. The first is a "dummy" blob that can only be found in the pack in |
| 29 | question. And then the second is the actual delta we want to find. |
| 30 | |
| 31 | The two blobs must be present in the same tree, not present in other trees, |
| 32 | and the dummy pathname must sort before the delta path. |
| 33 | |
| 34 | The setup below focuses on case 2. We have two commits HEAD and HEAD^, each |
| 35 | which has two files: "dummy" and "file". Then we can make two packs which |
| 36 | contain: |
| 37 | |
| 38 | [pack one] |
| 39 | HEAD:dummy |
| 40 | HEAD:file (as delta against HEAD^:file) |
| 41 | HEAD^:file (as base) |
| 42 | |
| 43 | [pack two] |
| 44 | HEAD^:dummy |
| 45 | HEAD^:file (as delta against HEAD:file) |
| 46 | HEAD:file (as base) |
| 47 | |
| 48 | Then no matter which order we start looking at the packs in, we know that we |
| 49 | will always find a delta for "file", because its lookup will always come |
| 50 | immediately after the lookup for "dummy". |
| 51 | ' |
| 52 | |
| 53 | . ./test-lib.sh |
| 54 | |
| 55 | # Create a pack containing the tree $1 and blob $1:file, with |
| 56 | # the latter stored as a delta against $2:file. |
| 57 | # |
| 58 | # We convince pack-objects to make the delta in the direction of our choosing |
| 59 | # by marking $2 as a preferred-base edge. That results in $1:file as a thin |
| 60 | # delta, and index-pack completes it by adding $2:file as a base. |
| 61 | # |
| 62 | # Note that the two variants of "file" must be similar enough to convince git |
| 63 | # to create the delta. |
| 64 | make_pack () { |
| 65 | ln1=$(git rev-parse "$2") && |
| 66 | ln2=$(git rev-parse "$1:dummy") && |
| 67 | ln3=$(git rev-parse "$1:file") && |
| 68 | cat >list <<-EOF |
| 69 | -$ln1 |
| 70 | $ln2 dummy |
| 71 | $ln3 file |
| 72 | EOF |
| 73 | git pack-objects --stdout <list >pack && |
| 74 | git index-pack --stdin --fix-thin <pack |
| 75 | } |
| 76 | |
| 77 | test_expect_success 'setup' ' |
| 78 | test-tool genrandom base 4096 >base && |
| 79 | for i in one two |
| 80 | do |
| 81 | # we want shared content here to encourage deltas... |
| 82 | cp base file && |
| 83 | echo $i >>file && |
| 84 | |
| 85 | # ...whereas dummy should be short, because we do not want |
| 86 | # deltas that would create duplicates when we --fix-thin |
| 87 | echo $i >dummy && |
| 88 | |
| 89 | git add file dummy && |
| 90 | test_tick && |
| 91 | git commit -m $i || |
| 92 | return 1 |
| 93 | done && |
| 94 | |
| 95 | make_pack HEAD^ HEAD && |
| 96 | make_pack HEAD HEAD^ |
| 97 | ' |
| 98 | |
| 99 | test_expect_success 'repack' ' |
| 100 | # We first want to check that we do not have any internal errors, |
| 101 | # and also that we do not hit the last-ditch cycle-breaking code |
| 102 | # in write_object(), which will issue a warning to stderr. |
| 103 | git repack -ad 2>stderr && |
| 104 | test_must_be_empty stderr && |
| 105 | |
| 106 | # And then double-check that the resulting pack is usable (i.e., |
| 107 | # we did not fail to notice any cycles). We know we are accessing |
| 108 | # the objects via the new pack here, because "repack -d" will have |
| 109 | # removed the others. |
| 110 | git cat-file blob HEAD:file >/dev/null && |
| 111 | git cat-file blob HEAD^:file >/dev/null |
| 112 | ' |
| 113 | |
| 114 | test_done |