git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
a8c1bc0f66b0da238af0cf1051bb7cfafbf27db8 blob 3138 bytes (raw)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
 
#!/bin/sh

test_description='pack-objects breaks long cross-pack delta chains'
. ./test-lib.sh

# This mirrors a repeated push setup:
#
# 1. A client repeatedly modifies some files, makes a
#      commit, and pushes the result. It does this N times
#      before we get around to repacking.
#
# 2. Each push generates a thin pack with the new version of
#    various objects. Let's consider some file in the root tree
#    which is updated in each commit.
#
#    When generating push number X, we feed commit X-1 (and
#    thus blob X-1) as a preferred base. The resulting pack has
#    blob X as a thin delta against blob X-1.
#
#    On the receiving end, "index-pack --fix-thin" will
#    complete the pack with a base copy of blob X-1.
#
# 3. In older versions of git, if we used the delta from
#    pack X, then we'd always find blob X-1 as a base in the
#    same pack (and generate a fresh delta).
#
#    But with the pack mru, we jump from delta to delta
#    following the traversal order:
#
#      a. We grab blob X from pack X as a delta, putting it at
#         the tip of our mru list.
#
#      b. Eventually we move onto commit X-1. We need other
#         objects which are only in pack X-1 (in the test code
#         below, it's the containing tree). That puts pack X-1
#         at the tip of our mru list.
#
#      c. Eventually we look for blob X-1, and we find the
#         version in pack X-1 (because it's the mru tip).
#
# Now we have blob X as a delta against X-1, which is a delta
# against X-2, and so forth.
#
# In the real world, these small pushes would get exploded by
# unpack-objects rather than "index-pack --fix-thin", but the
# same principle applies to larger pushes (they only need one
# repeatedly-modified file to generate the delta chain).

test_expect_success 'create series of packs' '
	test-tool genrandom foo 4096 >content &&
	prev= &&
	for i in $(test_seq 1 10)
	do
		cat content >file &&
		echo $i >>file &&
		git add file &&
		git commit -m $i &&
		cur=$(git rev-parse HEAD^{tree}) &&
		{
			test -n "$prev" && echo "-$prev"
			echo $cur
			echo "$(git rev-parse :file) file"
		} | git pack-objects --stdout >tmp &&
		git index-pack --stdin --fix-thin <tmp || return 1
		prev=$cur
	done
'

max_chain() {
	git index-pack --verify-stat-only "$1" >output &&
	perl -lne '
	  /chain length = (\d+)/ and $len = $1;
	  END { print $len }
	' output
}

# Note that this whole setup is pretty reliant on the current
# packing heuristics. We double-check that our test case
# actually produces a long chain. If it doesn't, it should be
# adjusted (or scrapped if the heuristics have become too unreliable)
test_expect_success 'packing produces a long delta' '
	# Use --window=0 to make sure we are seeing reused deltas,
	# not computing a new long chain.
	pack=$(git pack-objects --all --window=0 </dev/null pack) &&
	echo 9 >expect &&
	max_chain pack-$pack.pack >actual &&
	test_cmp expect actual
'

test_expect_success '--depth limits depth' '
	pack=$(git pack-objects --all --depth=5 </dev/null pack) &&
	echo 5 >expect &&
	max_chain pack-$pack.pack >actual &&
	test_cmp expect actual
'

test_done
debug log:

solving a8c1bc0f66 ...
found a8c1bc0f66 in https://80x24.org/mirrors/git.git

Code repositories for project(s) associated with this inbox:

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).