Merge branch 'js/blame-lib'
[git] / t / t5314-pack-cycle-detection.sh
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 . ./test-lib.sh
53
54
55
56 # Create a pack containing the the tree $1 and blob $1:file, with
57 # the latter stored as a delta against $2:file.
58 #
59 # We convince pack-objects to make the delta in the direction of our choosing
60 # by marking $2 as a preferred-base edge. That results in $1:file as a thin
61 # delta, and index-pack completes it by adding $2:file as a base.
62 #
63 # Note that the two variants of "file" must be similar enough to convince git
64 # to create the delta.
65 make_pack () {
66         {
67                 printf '%s\n' "-$(git rev-parse $2)"
68                 printf '%s dummy\n' "$(git rev-parse $1:dummy)"
69                 printf '%s file\n' "$(git rev-parse $1:file)"
70         } |
71         git pack-objects --stdout |
72         git index-pack --stdin --fix-thin
73 }
74
75 test_expect_success 'setup' '
76         test-genrandom base 4096 >base &&
77         for i in one two
78         do
79                 # we want shared content here to encourage deltas...
80                 cp base file &&
81                 echo $i >>file &&
82
83                 # ...whereas dummy should be short, because we do not want
84                 # deltas that would create duplicates when we --fix-thin
85                 echo $i >dummy &&
86
87                 git add file dummy &&
88                 test_tick &&
89                 git commit -m $i ||
90                 return 1
91         done &&
92
93         make_pack HEAD^ HEAD &&
94         make_pack HEAD HEAD^
95 '
96
97 test_expect_success 'repack' '
98         # We first want to check that we do not have any internal errors,
99         # and also that we do not hit the last-ditch cycle-breaking code
100         # in write_object(), which will issue a warning to stderr.
101         >expect &&
102         git repack -ad 2>stderr &&
103         test_cmp expect stderr &&
104
105         # And then double-check that the resulting pack is usable (i.e.,
106         # we did not fail to notice any cycles). We know we are accessing
107         # the objects via the new pack here, because "repack -d" will have
108         # removed the others.
109         git cat-file blob HEAD:file >/dev/null &&
110         git cat-file blob HEAD^:file >/dev/null
111 '
112
113 test_done