builtin/repack.c: add '--geometric' option
Often it is useful to both:
- have relatively few packfiles in a repository, and
- avoid having so few packfiles in a repository that we repack its
entire contents regularly
This patch implements a '--geometric=<n>' option in 'git repack'. This
allows the caller to specify that they would like each pack to be at
least a factor times as large as the previous largest pack (by object
count).
Concretely, say that a repository has 'n' packfiles, labeled P1, P2,
..., up to Pn. Each packfile has an object count equal to 'objects(Pn)'.
With a geometric factor of 'r', it should be that:
objects(Pi) > r*objects(P(i-1))
for all i in [1, n], where the packs are sorted by
objects(P1) <= objects(P2) <= ... <= objects(Pn).
Since finding a true optimal repacking is NP-hard, we approximate it
along two directions:
1. We assume that there is a cutoff of packs _before starting the
repack_ where everything to the right of that cut-off already forms
a geometric progression (or no cutoff exists and everything must be
repacked).
2. We assume that everything smaller than the cutoff count must be
repacked. This forms our base assumption, but it can also cause
even the "heavy" packs to get repacked, for e.g., if we have 6
packs containing the following number of objects:
1, 1, 1, 2, 4, 32
then we would place the cutoff between '1, 1' and '1, 2, 4, 32',
rolling up the first two packs into a pack with 2 objects. That
breaks our progression and leaves us:
2, 1, 2, 4, 32
^
(where the '^' indicates the position of our split). To restore a
progression, we move the split forward (towards larger packs)
joining each pack into our new pack until a geometric progression
is restored. Here, that looks like:
2, 1, 2, 4, 32 ~> 3, 2, 4, 32 ~> 5, 4, 32 ~> ... ~> 9, 32
^ ^ ^ ^
This has the advantage of not repacking the heavy-side of packs too
often while also only creating one new pack at a time. Another wrinkle
is that we assume that loose, indexed, and reflog'd objects are
insignificant, and lump them into any new pack that we create. This can
lead to non-idempotent results.
Suggested-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Reviewed-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-02-23 02:25:27 +00:00
|
|
|
#!/bin/sh
|
|
|
|
|
|
|
|
|
|
test_description='git repack --geometric works correctly'
|
|
|
|
|
|
|
|
|
|
. ./test-lib.sh
|
|
|
|
|
|
|
|
|
|
GIT_TEST_MULTI_PACK_INDEX=0
|
|
|
|
|
|
|
|
|
|
objdir=.git/objects
|
t7703: demonstrate object corruption with pack.packSizeLimit
When doing a `--geometric=<d>` repack, `git repack` determines a
splitting point among packs ordered by their object count such that:
- each pack above the split has at least `<d>` times as many objects
as the next-largest pack by object count, and
- the first pack above the split has at least `<d>` times as many
object as the sum of all packs below the split line combined
`git repack` then creates a pack containing all of the objects contained
in packs below the split line by running `git pack-objects
--stdin-packs` underneath. Once packs are moved into place, then any
packs below the split line are removed, since their objects were just
combined into a new pack.
But `git repack` tries to be careful to avoid removing a pack that it
just wrote, by checking:
struct packed_git *p = geometry->pack[i];
if (string_list_has_string(&names, hash_to_hex(p->hash)))
continue;
in the `delete_redundant` and `geometric` conditional towards the end of
`cmd_repack`.
But it's possible to trick `git repack` into not recognizing a pack that
it just wrote when `names` is out-of-order (which violates
`string_list_has_string()`'s assumption that the list is sorted and thus
binary search-able).
When this happens in just the right circumstances, it is possible to
remove a pack that we just wrote, leading to object corruption.
Luckily, this is quite difficult to provoke in practice (for a couple of
reasons):
- we ordinarily write just one pack, so `names` usually contains just
one entry, and is thus sorted
- when we do write more than one pack (e.g., due to `--max-pack-size`)
we have to: (a) write a pack identical to one that already
exists, (b) have that pack be below the split line, and (c) have
the set of packs written by `pack-objects` occur in an order which
tricks `string_list_has_string()`.
Demonstrate the above scenario in a failing test, which causes `git
repack --geometric` to write a pack which occurs below the split line,
_and_ fail to recognize that it wrote that pack.
The following patch will fix this bug.
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-05-20 19:01:48 +00:00
|
|
|
packdir=$objdir/pack
|
builtin/repack.c: add '--geometric' option
Often it is useful to both:
- have relatively few packfiles in a repository, and
- avoid having so few packfiles in a repository that we repack its
entire contents regularly
This patch implements a '--geometric=<n>' option in 'git repack'. This
allows the caller to specify that they would like each pack to be at
least a factor times as large as the previous largest pack (by object
count).
Concretely, say that a repository has 'n' packfiles, labeled P1, P2,
..., up to Pn. Each packfile has an object count equal to 'objects(Pn)'.
With a geometric factor of 'r', it should be that:
objects(Pi) > r*objects(P(i-1))
for all i in [1, n], where the packs are sorted by
objects(P1) <= objects(P2) <= ... <= objects(Pn).
Since finding a true optimal repacking is NP-hard, we approximate it
along two directions:
1. We assume that there is a cutoff of packs _before starting the
repack_ where everything to the right of that cut-off already forms
a geometric progression (or no cutoff exists and everything must be
repacked).
2. We assume that everything smaller than the cutoff count must be
repacked. This forms our base assumption, but it can also cause
even the "heavy" packs to get repacked, for e.g., if we have 6
packs containing the following number of objects:
1, 1, 1, 2, 4, 32
then we would place the cutoff between '1, 1' and '1, 2, 4, 32',
rolling up the first two packs into a pack with 2 objects. That
breaks our progression and leaves us:
2, 1, 2, 4, 32
^
(where the '^' indicates the position of our split). To restore a
progression, we move the split forward (towards larger packs)
joining each pack into our new pack until a geometric progression
is restored. Here, that looks like:
2, 1, 2, 4, 32 ~> 3, 2, 4, 32 ~> 5, 4, 32 ~> ... ~> 9, 32
^ ^ ^ ^
This has the advantage of not repacking the heavy-side of packs too
often while also only creating one new pack at a time. Another wrinkle
is that we assume that loose, indexed, and reflog'd objects are
insignificant, and lump them into any new pack that we create. This can
lead to non-idempotent results.
Suggested-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Reviewed-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-02-23 02:25:27 +00:00
|
|
|
midx=$objdir/pack/multi-pack-index
|
|
|
|
|
|
2023-04-14 06:02:08 +00:00
|
|
|
packed_objects () {
|
|
|
|
|
git show-index <"$1" >tmp-object-list &&
|
|
|
|
|
cut -d' ' -f2 tmp-object-list | sort &&
|
|
|
|
|
rm tmp-object-list
|
|
|
|
|
}
|
|
|
|
|
|
builtin/repack.c: add '--geometric' option
Often it is useful to both:
- have relatively few packfiles in a repository, and
- avoid having so few packfiles in a repository that we repack its
entire contents regularly
This patch implements a '--geometric=<n>' option in 'git repack'. This
allows the caller to specify that they would like each pack to be at
least a factor times as large as the previous largest pack (by object
count).
Concretely, say that a repository has 'n' packfiles, labeled P1, P2,
..., up to Pn. Each packfile has an object count equal to 'objects(Pn)'.
With a geometric factor of 'r', it should be that:
objects(Pi) > r*objects(P(i-1))
for all i in [1, n], where the packs are sorted by
objects(P1) <= objects(P2) <= ... <= objects(Pn).
Since finding a true optimal repacking is NP-hard, we approximate it
along two directions:
1. We assume that there is a cutoff of packs _before starting the
repack_ where everything to the right of that cut-off already forms
a geometric progression (or no cutoff exists and everything must be
repacked).
2. We assume that everything smaller than the cutoff count must be
repacked. This forms our base assumption, but it can also cause
even the "heavy" packs to get repacked, for e.g., if we have 6
packs containing the following number of objects:
1, 1, 1, 2, 4, 32
then we would place the cutoff between '1, 1' and '1, 2, 4, 32',
rolling up the first two packs into a pack with 2 objects. That
breaks our progression and leaves us:
2, 1, 2, 4, 32
^
(where the '^' indicates the position of our split). To restore a
progression, we move the split forward (towards larger packs)
joining each pack into our new pack until a geometric progression
is restored. Here, that looks like:
2, 1, 2, 4, 32 ~> 3, 2, 4, 32 ~> 5, 4, 32 ~> ... ~> 9, 32
^ ^ ^ ^
This has the advantage of not repacking the heavy-side of packs too
often while also only creating one new pack at a time. Another wrinkle
is that we assume that loose, indexed, and reflog'd objects are
insignificant, and lump them into any new pack that we create. This can
lead to non-idempotent results.
Suggested-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Reviewed-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-02-23 02:25:27 +00:00
|
|
|
test_expect_success '--geometric with no packs' '
|
|
|
|
|
git init geometric &&
|
|
|
|
|
test_when_finished "rm -fr geometric" &&
|
|
|
|
|
(
|
|
|
|
|
cd geometric &&
|
|
|
|
|
|
builtin/repack.c: support writing a MIDX while repacking
Teach `git repack` a new `--write-midx` option for callers that wish to
persist a multi-pack index in their repository while repacking.
There are two existing alternatives to this new flag, but they don't
cover our particular use-case. These alternatives are:
- Call 'git multi-pack-index write' after running 'git repack', or
- Set 'GIT_TEST_MULTI_PACK_INDEX=1' in your environment when running
'git repack'.
The former works, but introduces a gap in bitmap coverage between
repacking and writing a new MIDX (since the repack may have deleted a
pack included in the existing MIDX, invalidating it altogether).
Setting the 'GIT_TEST_' environment variable is obviously unsupported.
In fact, even if it were supported officially, it still wouldn't work,
because it generates the MIDX *after* redundant packs have been dropped,
leading to the same issue as above.
Introduce a new option which eliminates this race by teaching `git
repack` to generate the MIDX at the critical point: after the new packs
have been written and moved into place, but before the redundant packs
have been removed.
This option is compatible with `git repack`'s '--bitmap' option (it
changes the interpretation to be: "write a bitmap corresponding to the
MIDX after one has been generated").
There is a little bit of additional noise in the patch below to avoid
repeating ourselves when selecting which packs to delete. Instead of a
single loop as before (where we iterate over 'existing_packs', decide if
a pack is worth deleting, and if so, delete it), we have two loops (the
first where we decide which ones are worth deleting, and the second
where we actually do the deleting). This makes it so we have a single
check we can make consistently when (1) telling the MIDX which packs we
want to exclude, and (2) actually unlinking the redundant packs.
There is also a tiny change to short-circuit the body of
write_midx_included_packs() when no packs remain in the case of an empty
repository. The MIDX code does not handle this, so avoid trying to
generate a MIDX covering zero packs in the first place.
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-29 01:55:18 +00:00
|
|
|
git repack --write-midx --geometric 2 >out &&
|
builtin/repack.c: add '--geometric' option
Often it is useful to both:
- have relatively few packfiles in a repository, and
- avoid having so few packfiles in a repository that we repack its
entire contents regularly
This patch implements a '--geometric=<n>' option in 'git repack'. This
allows the caller to specify that they would like each pack to be at
least a factor times as large as the previous largest pack (by object
count).
Concretely, say that a repository has 'n' packfiles, labeled P1, P2,
..., up to Pn. Each packfile has an object count equal to 'objects(Pn)'.
With a geometric factor of 'r', it should be that:
objects(Pi) > r*objects(P(i-1))
for all i in [1, n], where the packs are sorted by
objects(P1) <= objects(P2) <= ... <= objects(Pn).
Since finding a true optimal repacking is NP-hard, we approximate it
along two directions:
1. We assume that there is a cutoff of packs _before starting the
repack_ where everything to the right of that cut-off already forms
a geometric progression (or no cutoff exists and everything must be
repacked).
2. We assume that everything smaller than the cutoff count must be
repacked. This forms our base assumption, but it can also cause
even the "heavy" packs to get repacked, for e.g., if we have 6
packs containing the following number of objects:
1, 1, 1, 2, 4, 32
then we would place the cutoff between '1, 1' and '1, 2, 4, 32',
rolling up the first two packs into a pack with 2 objects. That
breaks our progression and leaves us:
2, 1, 2, 4, 32
^
(where the '^' indicates the position of our split). To restore a
progression, we move the split forward (towards larger packs)
joining each pack into our new pack until a geometric progression
is restored. Here, that looks like:
2, 1, 2, 4, 32 ~> 3, 2, 4, 32 ~> 5, 4, 32 ~> ... ~> 9, 32
^ ^ ^ ^
This has the advantage of not repacking the heavy-side of packs too
often while also only creating one new pack at a time. Another wrinkle
is that we assume that loose, indexed, and reflog'd objects are
insignificant, and lump them into any new pack that we create. This can
lead to non-idempotent results.
Suggested-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Reviewed-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-02-23 02:25:27 +00:00
|
|
|
test_i18ngrep "Nothing new to pack" out
|
|
|
|
|
)
|
|
|
|
|
'
|
|
|
|
|
|
2021-03-05 15:21:37 +00:00
|
|
|
test_expect_success '--geometric with one pack' '
|
|
|
|
|
git init geometric &&
|
|
|
|
|
test_when_finished "rm -fr geometric" &&
|
|
|
|
|
(
|
|
|
|
|
cd geometric &&
|
|
|
|
|
|
|
|
|
|
test_commit "base" &&
|
|
|
|
|
git repack -d &&
|
|
|
|
|
|
|
|
|
|
git repack --geometric 2 >out &&
|
|
|
|
|
|
|
|
|
|
test_i18ngrep "Nothing new to pack" out
|
|
|
|
|
)
|
|
|
|
|
'
|
|
|
|
|
|
builtin/repack.c: add '--geometric' option
Often it is useful to both:
- have relatively few packfiles in a repository, and
- avoid having so few packfiles in a repository that we repack its
entire contents regularly
This patch implements a '--geometric=<n>' option in 'git repack'. This
allows the caller to specify that they would like each pack to be at
least a factor times as large as the previous largest pack (by object
count).
Concretely, say that a repository has 'n' packfiles, labeled P1, P2,
..., up to Pn. Each packfile has an object count equal to 'objects(Pn)'.
With a geometric factor of 'r', it should be that:
objects(Pi) > r*objects(P(i-1))
for all i in [1, n], where the packs are sorted by
objects(P1) <= objects(P2) <= ... <= objects(Pn).
Since finding a true optimal repacking is NP-hard, we approximate it
along two directions:
1. We assume that there is a cutoff of packs _before starting the
repack_ where everything to the right of that cut-off already forms
a geometric progression (or no cutoff exists and everything must be
repacked).
2. We assume that everything smaller than the cutoff count must be
repacked. This forms our base assumption, but it can also cause
even the "heavy" packs to get repacked, for e.g., if we have 6
packs containing the following number of objects:
1, 1, 1, 2, 4, 32
then we would place the cutoff between '1, 1' and '1, 2, 4, 32',
rolling up the first two packs into a pack with 2 objects. That
breaks our progression and leaves us:
2, 1, 2, 4, 32
^
(where the '^' indicates the position of our split). To restore a
progression, we move the split forward (towards larger packs)
joining each pack into our new pack until a geometric progression
is restored. Here, that looks like:
2, 1, 2, 4, 32 ~> 3, 2, 4, 32 ~> 5, 4, 32 ~> ... ~> 9, 32
^ ^ ^ ^
This has the advantage of not repacking the heavy-side of packs too
often while also only creating one new pack at a time. Another wrinkle
is that we assume that loose, indexed, and reflog'd objects are
insignificant, and lump them into any new pack that we create. This can
lead to non-idempotent results.
Suggested-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Reviewed-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-02-23 02:25:27 +00:00
|
|
|
test_expect_success '--geometric with an intact progression' '
|
|
|
|
|
git init geometric &&
|
|
|
|
|
test_when_finished "rm -fr geometric" &&
|
|
|
|
|
(
|
|
|
|
|
cd geometric &&
|
|
|
|
|
|
|
|
|
|
# These packs already form a geometric progression.
|
|
|
|
|
test_commit_bulk --start=1 1 && # 3 objects
|
|
|
|
|
test_commit_bulk --start=2 2 && # 6 objects
|
|
|
|
|
test_commit_bulk --start=4 4 && # 12 objects
|
|
|
|
|
|
|
|
|
|
find $objdir/pack -name "*.pack" | sort >expect &&
|
|
|
|
|
git repack --geometric 2 -d &&
|
|
|
|
|
find $objdir/pack -name "*.pack" | sort >actual &&
|
|
|
|
|
|
|
|
|
|
test_cmp expect actual
|
|
|
|
|
)
|
|
|
|
|
'
|
|
|
|
|
|
2021-03-05 15:21:43 +00:00
|
|
|
test_expect_success '--geometric with loose objects' '
|
|
|
|
|
git init geometric &&
|
|
|
|
|
test_when_finished "rm -fr geometric" &&
|
|
|
|
|
(
|
|
|
|
|
cd geometric &&
|
|
|
|
|
|
|
|
|
|
# These packs already form a geometric progression.
|
|
|
|
|
test_commit_bulk --start=1 1 && # 3 objects
|
|
|
|
|
test_commit_bulk --start=2 2 && # 6 objects
|
|
|
|
|
# The loose objects are packed together, breaking the
|
|
|
|
|
# progression.
|
|
|
|
|
test_commit loose && # 3 objects
|
|
|
|
|
|
|
|
|
|
find $objdir/pack -name "*.pack" | sort >before &&
|
|
|
|
|
git repack --geometric 2 -d &&
|
|
|
|
|
find $objdir/pack -name "*.pack" | sort >after &&
|
|
|
|
|
|
|
|
|
|
comm -13 before after >new &&
|
|
|
|
|
comm -23 before after >removed &&
|
|
|
|
|
|
|
|
|
|
test_line_count = 1 new &&
|
|
|
|
|
test_must_be_empty removed &&
|
|
|
|
|
|
|
|
|
|
git repack --geometric 2 -d &&
|
|
|
|
|
find $objdir/pack -name "*.pack" | sort >after &&
|
|
|
|
|
|
|
|
|
|
# The progression (3, 3, 6) is combined into one new pack.
|
|
|
|
|
test_line_count = 1 after
|
|
|
|
|
)
|
|
|
|
|
'
|
|
|
|
|
|
builtin/repack.c: add '--geometric' option
Often it is useful to both:
- have relatively few packfiles in a repository, and
- avoid having so few packfiles in a repository that we repack its
entire contents regularly
This patch implements a '--geometric=<n>' option in 'git repack'. This
allows the caller to specify that they would like each pack to be at
least a factor times as large as the previous largest pack (by object
count).
Concretely, say that a repository has 'n' packfiles, labeled P1, P2,
..., up to Pn. Each packfile has an object count equal to 'objects(Pn)'.
With a geometric factor of 'r', it should be that:
objects(Pi) > r*objects(P(i-1))
for all i in [1, n], where the packs are sorted by
objects(P1) <= objects(P2) <= ... <= objects(Pn).
Since finding a true optimal repacking is NP-hard, we approximate it
along two directions:
1. We assume that there is a cutoff of packs _before starting the
repack_ where everything to the right of that cut-off already forms
a geometric progression (or no cutoff exists and everything must be
repacked).
2. We assume that everything smaller than the cutoff count must be
repacked. This forms our base assumption, but it can also cause
even the "heavy" packs to get repacked, for e.g., if we have 6
packs containing the following number of objects:
1, 1, 1, 2, 4, 32
then we would place the cutoff between '1, 1' and '1, 2, 4, 32',
rolling up the first two packs into a pack with 2 objects. That
breaks our progression and leaves us:
2, 1, 2, 4, 32
^
(where the '^' indicates the position of our split). To restore a
progression, we move the split forward (towards larger packs)
joining each pack into our new pack until a geometric progression
is restored. Here, that looks like:
2, 1, 2, 4, 32 ~> 3, 2, 4, 32 ~> 5, 4, 32 ~> ... ~> 9, 32
^ ^ ^ ^
This has the advantage of not repacking the heavy-side of packs too
often while also only creating one new pack at a time. Another wrinkle
is that we assume that loose, indexed, and reflog'd objects are
insignificant, and lump them into any new pack that we create. This can
lead to non-idempotent results.
Suggested-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Reviewed-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-02-23 02:25:27 +00:00
|
|
|
test_expect_success '--geometric with small-pack rollup' '
|
|
|
|
|
git init geometric &&
|
|
|
|
|
test_when_finished "rm -fr geometric" &&
|
|
|
|
|
(
|
|
|
|
|
cd geometric &&
|
|
|
|
|
|
|
|
|
|
test_commit_bulk --start=1 1 && # 3 objects
|
|
|
|
|
test_commit_bulk --start=2 1 && # 3 objects
|
|
|
|
|
find $objdir/pack -name "*.pack" | sort >small &&
|
|
|
|
|
test_commit_bulk --start=3 4 && # 12 objects
|
|
|
|
|
test_commit_bulk --start=7 8 && # 24 objects
|
|
|
|
|
find $objdir/pack -name "*.pack" | sort >before &&
|
|
|
|
|
|
|
|
|
|
git repack --geometric 2 -d &&
|
|
|
|
|
|
|
|
|
|
# Three packs in total; two of the existing large ones, and one
|
|
|
|
|
# new one.
|
|
|
|
|
find $objdir/pack -name "*.pack" | sort >after &&
|
|
|
|
|
test_line_count = 3 after &&
|
|
|
|
|
comm -3 small before | tr -d "\t" >large &&
|
|
|
|
|
grep -qFf large after
|
|
|
|
|
)
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success '--geometric with small- and large-pack rollup' '
|
|
|
|
|
git init geometric &&
|
|
|
|
|
test_when_finished "rm -fr geometric" &&
|
|
|
|
|
(
|
|
|
|
|
cd geometric &&
|
|
|
|
|
|
|
|
|
|
# size(small1) + size(small2) > size(medium) / 2
|
|
|
|
|
test_commit_bulk --start=1 1 && # 3 objects
|
|
|
|
|
test_commit_bulk --start=2 1 && # 3 objects
|
|
|
|
|
test_commit_bulk --start=2 3 && # 7 objects
|
|
|
|
|
test_commit_bulk --start=6 9 && # 27 objects &&
|
|
|
|
|
|
|
|
|
|
find $objdir/pack -name "*.pack" | sort >before &&
|
|
|
|
|
|
|
|
|
|
git repack --geometric 2 -d &&
|
|
|
|
|
|
|
|
|
|
find $objdir/pack -name "*.pack" | sort >after &&
|
|
|
|
|
comm -12 before after >untouched &&
|
|
|
|
|
|
|
|
|
|
# Two packs in total; the largest pack from before running "git
|
|
|
|
|
# repack", and one new one.
|
|
|
|
|
test_line_count = 1 untouched &&
|
|
|
|
|
test_line_count = 2 after
|
|
|
|
|
)
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success '--geometric ignores kept packs' '
|
|
|
|
|
git init geometric &&
|
|
|
|
|
test_when_finished "rm -fr geometric" &&
|
|
|
|
|
(
|
|
|
|
|
cd geometric &&
|
|
|
|
|
|
|
|
|
|
test_commit kept && # 3 objects
|
|
|
|
|
test_commit pack && # 3 objects
|
|
|
|
|
|
|
|
|
|
KEPT=$(git pack-objects --revs $objdir/pack/pack <<-EOF
|
|
|
|
|
refs/tags/kept
|
|
|
|
|
EOF
|
|
|
|
|
) &&
|
|
|
|
|
PACK=$(git pack-objects --revs $objdir/pack/pack <<-EOF
|
|
|
|
|
refs/tags/pack
|
|
|
|
|
^refs/tags/kept
|
|
|
|
|
EOF
|
|
|
|
|
) &&
|
|
|
|
|
|
|
|
|
|
# neither pack contains more than twice the number of objects in
|
|
|
|
|
# the other, so they should be combined. but, marking one as
|
|
|
|
|
# .kept on disk will "freeze" it, so the pack structure should
|
|
|
|
|
# remain unchanged.
|
|
|
|
|
touch $objdir/pack/pack-$KEPT.keep &&
|
|
|
|
|
|
|
|
|
|
find $objdir/pack -name "*.pack" | sort >before &&
|
|
|
|
|
git repack --geometric 2 -d &&
|
|
|
|
|
find $objdir/pack -name "*.pack" | sort >after &&
|
|
|
|
|
|
|
|
|
|
# both packs should still exist
|
|
|
|
|
test_path_is_file $objdir/pack/pack-$KEPT.pack &&
|
|
|
|
|
test_path_is_file $objdir/pack/pack-$PACK.pack &&
|
|
|
|
|
|
|
|
|
|
# and no new packs should be created
|
|
|
|
|
test_cmp before after &&
|
|
|
|
|
|
|
|
|
|
# Passing --pack-kept-objects causes packs with a .keep file to
|
|
|
|
|
# be repacked, too.
|
|
|
|
|
git repack --geometric 2 -d --pack-kept-objects &&
|
|
|
|
|
|
repack: don't remove .keep packs with `--pack-kept-objects`
`git repack` supports a `--pack-kept-objects` flag which more or less
translates to whether or not we pass `--honor-pack-keep` down to `git
pack-objects` when assembling a new pack.
This behavior has existed since ee34a2bead (repack: add
`repack.packKeptObjects` config var, 2014-03-03). In that commit, the
documentation was extended to say:
[...] Note that we still do not delete `.keep` packs after
`pack-objects` finishes.
Unfortunately, this is not the case when `--pack-kept-objects` is
combined with a `--geometric` repack. When doing a geometric repack, we
include `.keep` packs when enumerating available packs only when
`pack_kept_objects` is set.
So this all works fine when `--no-pack-kept-objects` (or similar) is
given. Kept packs are excluded from the geometric roll-up, so when we go
to delete redundant packs (with `-d`), no `.keep` packs appear "below
the split" in our geometric progression.
But when `--pack-kept-objects` is given, things can go awry. Namely,
when a kept pack is included in the list of packs tracked by the
`pack_geometry` struct *and* part of the pack roll-up, we will delete
the `.keep` pack when we shouldn't.
Note that this *doesn't* result in object corruption, since the `.keep`
pack's objects are still present in the new pack. But the `.keep` pack
itself is removed, which violates our promise from back in ee34a2bead.
But there's more. Because `repack` computes the geometric roll-up
independently from selecting which packs belong in a MIDX (with
`--write-midx`), this can lead to odd behavior. Consider when a `.keep`
pack appears below the geometric split (ie., its objects will be part of
the new pack we generate).
We'll write a MIDX containing the new pack along with the existing
`.keep` pack. But because the `.keep` pack appears below the geometric
split line, we'll (incorrectly) try to remove it. While this doesn't
corrupt the repository, it does cause us to remove the MIDX we just
wrote, since removing that pack would invalidate the new MIDX.
Funny enough, this behavior became far less noticeable after e4d0c11c04
(repack: respect kept objects with '--write-midx -b', 2021-12-20), which
made `pack_kept_objects` be enabled by default only when we were writing
a non-MIDX bitmap.
But e4d0c11c04 didn't resolve this bug, it just made it harder to notice
unless callers explicitly passed `--pack-kept-objects`.
The solution is to avoid trying to remove `.keep` packs during
`--geometric` repacks, even when they appear below the geometric split
line, which is the approach this patch implements.
Co-authored-by: Victoria Dye <vdye@github.com>
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-10-18 02:26:06 +00:00
|
|
|
# After repacking, two packs remain: one new one (containing the
|
|
|
|
|
# objects in both the .keep and non-kept pack), and the .keep
|
|
|
|
|
# pack (since `--pack-kept-objects -d` does not actually delete
|
|
|
|
|
# the kept pack).
|
builtin/repack.c: add '--geometric' option
Often it is useful to both:
- have relatively few packfiles in a repository, and
- avoid having so few packfiles in a repository that we repack its
entire contents regularly
This patch implements a '--geometric=<n>' option in 'git repack'. This
allows the caller to specify that they would like each pack to be at
least a factor times as large as the previous largest pack (by object
count).
Concretely, say that a repository has 'n' packfiles, labeled P1, P2,
..., up to Pn. Each packfile has an object count equal to 'objects(Pn)'.
With a geometric factor of 'r', it should be that:
objects(Pi) > r*objects(P(i-1))
for all i in [1, n], where the packs are sorted by
objects(P1) <= objects(P2) <= ... <= objects(Pn).
Since finding a true optimal repacking is NP-hard, we approximate it
along two directions:
1. We assume that there is a cutoff of packs _before starting the
repack_ where everything to the right of that cut-off already forms
a geometric progression (or no cutoff exists and everything must be
repacked).
2. We assume that everything smaller than the cutoff count must be
repacked. This forms our base assumption, but it can also cause
even the "heavy" packs to get repacked, for e.g., if we have 6
packs containing the following number of objects:
1, 1, 1, 2, 4, 32
then we would place the cutoff between '1, 1' and '1, 2, 4, 32',
rolling up the first two packs into a pack with 2 objects. That
breaks our progression and leaves us:
2, 1, 2, 4, 32
^
(where the '^' indicates the position of our split). To restore a
progression, we move the split forward (towards larger packs)
joining each pack into our new pack until a geometric progression
is restored. Here, that looks like:
2, 1, 2, 4, 32 ~> 3, 2, 4, 32 ~> 5, 4, 32 ~> ... ~> 9, 32
^ ^ ^ ^
This has the advantage of not repacking the heavy-side of packs too
often while also only creating one new pack at a time. Another wrinkle
is that we assume that loose, indexed, and reflog'd objects are
insignificant, and lump them into any new pack that we create. This can
lead to non-idempotent results.
Suggested-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Reviewed-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-02-23 02:25:27 +00:00
|
|
|
find $objdir/pack -name "*.pack" >after &&
|
repack: don't remove .keep packs with `--pack-kept-objects`
`git repack` supports a `--pack-kept-objects` flag which more or less
translates to whether or not we pass `--honor-pack-keep` down to `git
pack-objects` when assembling a new pack.
This behavior has existed since ee34a2bead (repack: add
`repack.packKeptObjects` config var, 2014-03-03). In that commit, the
documentation was extended to say:
[...] Note that we still do not delete `.keep` packs after
`pack-objects` finishes.
Unfortunately, this is not the case when `--pack-kept-objects` is
combined with a `--geometric` repack. When doing a geometric repack, we
include `.keep` packs when enumerating available packs only when
`pack_kept_objects` is set.
So this all works fine when `--no-pack-kept-objects` (or similar) is
given. Kept packs are excluded from the geometric roll-up, so when we go
to delete redundant packs (with `-d`), no `.keep` packs appear "below
the split" in our geometric progression.
But when `--pack-kept-objects` is given, things can go awry. Namely,
when a kept pack is included in the list of packs tracked by the
`pack_geometry` struct *and* part of the pack roll-up, we will delete
the `.keep` pack when we shouldn't.
Note that this *doesn't* result in object corruption, since the `.keep`
pack's objects are still present in the new pack. But the `.keep` pack
itself is removed, which violates our promise from back in ee34a2bead.
But there's more. Because `repack` computes the geometric roll-up
independently from selecting which packs belong in a MIDX (with
`--write-midx`), this can lead to odd behavior. Consider when a `.keep`
pack appears below the geometric split (ie., its objects will be part of
the new pack we generate).
We'll write a MIDX containing the new pack along with the existing
`.keep` pack. But because the `.keep` pack appears below the geometric
split line, we'll (incorrectly) try to remove it. While this doesn't
corrupt the repository, it does cause us to remove the MIDX we just
wrote, since removing that pack would invalidate the new MIDX.
Funny enough, this behavior became far less noticeable after e4d0c11c04
(repack: respect kept objects with '--write-midx -b', 2021-12-20), which
made `pack_kept_objects` be enabled by default only when we were writing
a non-MIDX bitmap.
But e4d0c11c04 didn't resolve this bug, it just made it harder to notice
unless callers explicitly passed `--pack-kept-objects`.
The solution is to avoid trying to remove `.keep` packs during
`--geometric` repacks, even when they appear below the geometric split
line, which is the approach this patch implements.
Co-authored-by: Victoria Dye <vdye@github.com>
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-10-18 02:26:06 +00:00
|
|
|
test_line_count = 2 after
|
builtin/repack.c: add '--geometric' option
Often it is useful to both:
- have relatively few packfiles in a repository, and
- avoid having so few packfiles in a repository that we repack its
entire contents regularly
This patch implements a '--geometric=<n>' option in 'git repack'. This
allows the caller to specify that they would like each pack to be at
least a factor times as large as the previous largest pack (by object
count).
Concretely, say that a repository has 'n' packfiles, labeled P1, P2,
..., up to Pn. Each packfile has an object count equal to 'objects(Pn)'.
With a geometric factor of 'r', it should be that:
objects(Pi) > r*objects(P(i-1))
for all i in [1, n], where the packs are sorted by
objects(P1) <= objects(P2) <= ... <= objects(Pn).
Since finding a true optimal repacking is NP-hard, we approximate it
along two directions:
1. We assume that there is a cutoff of packs _before starting the
repack_ where everything to the right of that cut-off already forms
a geometric progression (or no cutoff exists and everything must be
repacked).
2. We assume that everything smaller than the cutoff count must be
repacked. This forms our base assumption, but it can also cause
even the "heavy" packs to get repacked, for e.g., if we have 6
packs containing the following number of objects:
1, 1, 1, 2, 4, 32
then we would place the cutoff between '1, 1' and '1, 2, 4, 32',
rolling up the first two packs into a pack with 2 objects. That
breaks our progression and leaves us:
2, 1, 2, 4, 32
^
(where the '^' indicates the position of our split). To restore a
progression, we move the split forward (towards larger packs)
joining each pack into our new pack until a geometric progression
is restored. Here, that looks like:
2, 1, 2, 4, 32 ~> 3, 2, 4, 32 ~> 5, 4, 32 ~> ... ~> 9, 32
^ ^ ^ ^
This has the advantage of not repacking the heavy-side of packs too
often while also only creating one new pack at a time. Another wrinkle
is that we assume that loose, indexed, and reflog'd objects are
insignificant, and lump them into any new pack that we create. This can
lead to non-idempotent results.
Suggested-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Reviewed-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-02-23 02:25:27 +00:00
|
|
|
)
|
|
|
|
|
'
|
|
|
|
|
|
2022-05-20 19:01:45 +00:00
|
|
|
test_expect_success '--geometric ignores --keep-pack packs' '
|
|
|
|
|
git init geometric &&
|
|
|
|
|
test_when_finished "rm -fr geometric" &&
|
|
|
|
|
(
|
|
|
|
|
cd geometric &&
|
|
|
|
|
|
|
|
|
|
# Create two equal-sized packs
|
|
|
|
|
test_commit kept && # 3 objects
|
|
|
|
|
git repack -d &&
|
|
|
|
|
test_commit pack && # 3 objects
|
|
|
|
|
git repack -d &&
|
|
|
|
|
|
|
|
|
|
find $objdir/pack -type f -name "*.pack" | sort >packs.before &&
|
|
|
|
|
git repack --geometric 2 -dm \
|
|
|
|
|
--keep-pack="$(basename "$(head -n 1 packs.before)")" >out &&
|
|
|
|
|
find $objdir/pack -type f -name "*.pack" | sort >packs.after &&
|
|
|
|
|
|
|
|
|
|
# Packs should not have changed (only one non-kept pack, no
|
|
|
|
|
# loose objects), but $midx should now exist.
|
|
|
|
|
grep "Nothing new to pack" out &&
|
|
|
|
|
test_path_is_file $midx &&
|
|
|
|
|
|
|
|
|
|
test_cmp packs.before packs.after &&
|
|
|
|
|
|
|
|
|
|
git fsck
|
|
|
|
|
)
|
|
|
|
|
'
|
|
|
|
|
|
2021-09-29 01:55:20 +00:00
|
|
|
test_expect_success '--geometric chooses largest MIDX preferred pack' '
|
|
|
|
|
git init geometric &&
|
|
|
|
|
test_when_finished "rm -fr geometric" &&
|
|
|
|
|
(
|
|
|
|
|
cd geometric &&
|
|
|
|
|
|
|
|
|
|
# These packs already form a geometric progression.
|
|
|
|
|
test_commit_bulk --start=1 1 && # 3 objects
|
|
|
|
|
test_commit_bulk --start=2 2 && # 6 objects
|
|
|
|
|
ls $objdir/pack/pack-*.idx >before &&
|
|
|
|
|
test_commit_bulk --start=4 4 && # 12 objects
|
|
|
|
|
ls $objdir/pack/pack-*.idx >after &&
|
|
|
|
|
|
|
|
|
|
git repack --geometric 2 -dbm &&
|
|
|
|
|
|
|
|
|
|
comm -3 before after | xargs -n 1 basename >expect &&
|
|
|
|
|
test-tool read-midx --preferred-pack $objdir >actual &&
|
|
|
|
|
|
|
|
|
|
test_cmp expect actual
|
|
|
|
|
)
|
|
|
|
|
'
|
|
|
|
|
|
2022-05-20 19:01:51 +00:00
|
|
|
test_expect_success '--geometric with pack.packSizeLimit' '
|
t7703: demonstrate object corruption with pack.packSizeLimit
When doing a `--geometric=<d>` repack, `git repack` determines a
splitting point among packs ordered by their object count such that:
- each pack above the split has at least `<d>` times as many objects
as the next-largest pack by object count, and
- the first pack above the split has at least `<d>` times as many
object as the sum of all packs below the split line combined
`git repack` then creates a pack containing all of the objects contained
in packs below the split line by running `git pack-objects
--stdin-packs` underneath. Once packs are moved into place, then any
packs below the split line are removed, since their objects were just
combined into a new pack.
But `git repack` tries to be careful to avoid removing a pack that it
just wrote, by checking:
struct packed_git *p = geometry->pack[i];
if (string_list_has_string(&names, hash_to_hex(p->hash)))
continue;
in the `delete_redundant` and `geometric` conditional towards the end of
`cmd_repack`.
But it's possible to trick `git repack` into not recognizing a pack that
it just wrote when `names` is out-of-order (which violates
`string_list_has_string()`'s assumption that the list is sorted and thus
binary search-able).
When this happens in just the right circumstances, it is possible to
remove a pack that we just wrote, leading to object corruption.
Luckily, this is quite difficult to provoke in practice (for a couple of
reasons):
- we ordinarily write just one pack, so `names` usually contains just
one entry, and is thus sorted
- when we do write more than one pack (e.g., due to `--max-pack-size`)
we have to: (a) write a pack identical to one that already
exists, (b) have that pack be below the split line, and (c) have
the set of packs written by `pack-objects` occur in an order which
tricks `string_list_has_string()`.
Demonstrate the above scenario in a failing test, which causes `git
repack --geometric` to write a pack which occurs below the split line,
_and_ fail to recognize that it wrote that pack.
The following patch will fix this bug.
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-05-20 19:01:48 +00:00
|
|
|
git init pack-rewrite &&
|
|
|
|
|
test_when_finished "rm -fr pack-rewrite" &&
|
|
|
|
|
(
|
|
|
|
|
cd pack-rewrite &&
|
|
|
|
|
|
|
|
|
|
test-tool genrandom foo 1048576 >foo &&
|
|
|
|
|
test-tool genrandom bar 1048576 >bar &&
|
|
|
|
|
|
|
|
|
|
git add foo bar &&
|
|
|
|
|
test_tick &&
|
|
|
|
|
git commit -m base &&
|
|
|
|
|
|
|
|
|
|
git rev-parse HEAD:foo HEAD:bar >p1.objects &&
|
|
|
|
|
git rev-parse HEAD HEAD^{tree} >p2.objects &&
|
|
|
|
|
|
|
|
|
|
# These two packs each contain two objects, so the following
|
|
|
|
|
# `--geometric` repack will try to combine them.
|
|
|
|
|
p1="$(git pack-objects $packdir/pack <p1.objects)" &&
|
|
|
|
|
p2="$(git pack-objects $packdir/pack <p2.objects)" &&
|
|
|
|
|
|
|
|
|
|
# Remove any loose objects in packs, since we do not want extra
|
|
|
|
|
# copies around (which would mask over potential object
|
|
|
|
|
# corruption issues).
|
|
|
|
|
git prune-packed &&
|
|
|
|
|
|
|
|
|
|
# Both p1 and p2 will be rolled up, but pack-objects will write
|
|
|
|
|
# three packs:
|
|
|
|
|
#
|
|
|
|
|
# - one containing object "foo",
|
|
|
|
|
# - another containing object "bar",
|
|
|
|
|
# - a final pack containing the commit and tree objects
|
|
|
|
|
# (identical to p2 above)
|
|
|
|
|
git repack --geometric 2 -d --max-pack-size=1048576 &&
|
|
|
|
|
|
|
|
|
|
# Ensure `repack` can detect that the third pack it wrote
|
|
|
|
|
# (containing just the tree and commit objects) was identical to
|
|
|
|
|
# one that was below the geometric split, so that we can save it
|
|
|
|
|
# from deletion.
|
|
|
|
|
#
|
|
|
|
|
# If `repack` fails to do that, we will incorrectly delete p2,
|
|
|
|
|
# causing object corruption.
|
|
|
|
|
git fsck
|
|
|
|
|
)
|
|
|
|
|
'
|
|
|
|
|
|
2023-04-14 06:01:36 +00:00
|
|
|
test_expect_success '--geometric --write-midx with packfiles in main and alternate ODB' '
|
|
|
|
|
test_when_finished "rm -fr shared member" &&
|
|
|
|
|
|
|
|
|
|
# Create a shared repository that will serve as the alternate object
|
|
|
|
|
# database for the member linked to it. It has got some objects on its
|
|
|
|
|
# own that are packed into a single packfile.
|
|
|
|
|
git init shared &&
|
|
|
|
|
test_commit -C shared common-object &&
|
|
|
|
|
git -C shared repack -ad &&
|
|
|
|
|
|
|
|
|
|
# We create member so that its alternates file points to the shared
|
|
|
|
|
# repository. We then create a commit in it so that git-repack(1) has
|
|
|
|
|
# something to repack.
|
|
|
|
|
# of the shared object database.
|
|
|
|
|
git clone --shared shared member &&
|
|
|
|
|
test_commit -C member unique-object &&
|
|
|
|
|
git -C member repack --geometric=2 --write-midx 2>err &&
|
|
|
|
|
test_must_be_empty err &&
|
|
|
|
|
|
|
|
|
|
# We should see that a new packfile was generated.
|
|
|
|
|
find shared/.git/objects/pack -type f -name "*.pack" >packs &&
|
|
|
|
|
test_line_count = 1 packs &&
|
|
|
|
|
|
|
|
|
|
# We should also see a multi-pack-index. This multi-pack-index should
|
|
|
|
|
# never refer to any packfiles in the alternate object database.
|
|
|
|
|
test_path_is_file member/.git/objects/pack/multi-pack-index &&
|
|
|
|
|
test-tool read-midx member/.git/objects >packs.midx &&
|
|
|
|
|
grep "^pack-.*\.idx$" packs.midx | sort >actual &&
|
|
|
|
|
basename member/.git/objects/pack/pack-*.idx >expect &&
|
|
|
|
|
test_cmp expect actual
|
|
|
|
|
'
|
|
|
|
|
|
2023-04-14 06:01:40 +00:00
|
|
|
test_expect_success '--geometric --with-midx with no local objects' '
|
|
|
|
|
test_when_finished "rm -fr shared member" &&
|
|
|
|
|
|
|
|
|
|
# Create a repository with a single packfile that acts as alternate
|
|
|
|
|
# object database.
|
|
|
|
|
git init shared &&
|
|
|
|
|
test_commit -C shared "shared-objects" &&
|
|
|
|
|
git -C shared repack -ad &&
|
|
|
|
|
|
|
|
|
|
# Create a second repository linked to the first one and perform a
|
|
|
|
|
# geometric repack on it.
|
|
|
|
|
git clone --shared shared member &&
|
|
|
|
|
git -C member repack --geometric 2 --write-midx 2>err &&
|
|
|
|
|
test_must_be_empty err &&
|
|
|
|
|
|
|
|
|
|
# Assert that we wrote neither a new packfile nor a multi-pack-index.
|
|
|
|
|
# We should not have a packfile because the single packfile in the
|
|
|
|
|
# alternate object database does not invalidate the geometric sequence.
|
|
|
|
|
# And we should not have a multi-pack-index because these only index
|
|
|
|
|
# local packfiles, and there are none.
|
|
|
|
|
test_dir_is_empty member/$packdir
|
|
|
|
|
'
|
|
|
|
|
|
2023-04-14 06:01:49 +00:00
|
|
|
test_expect_success '--geometric with same pack in main and alternate ODB' '
|
|
|
|
|
test_when_finished "rm -fr shared member" &&
|
|
|
|
|
|
|
|
|
|
# Create a repository with a single packfile that acts as alternate
|
|
|
|
|
# object database.
|
|
|
|
|
git init shared &&
|
|
|
|
|
test_commit -C shared "shared-objects" &&
|
|
|
|
|
git -C shared repack -ad &&
|
|
|
|
|
|
|
|
|
|
# We create the member repository as an exact copy so that it has the
|
|
|
|
|
# same packfile.
|
|
|
|
|
cp -r shared member &&
|
|
|
|
|
test-tool path-utils real_path shared/.git/objects >member/.git/objects/info/alternates &&
|
|
|
|
|
find shared/.git/objects -type f >expected-files &&
|
|
|
|
|
|
|
|
|
|
# Verify that we can repack objects as expected without observing any
|
|
|
|
|
# error. Having the same packfile in both ODBs used to cause an error
|
|
|
|
|
# in git-pack-objects(1).
|
|
|
|
|
git -C member repack --geometric 2 2>err &&
|
|
|
|
|
test_must_be_empty err &&
|
|
|
|
|
# Nothing should have changed.
|
|
|
|
|
find shared/.git/objects -type f >actual-files &&
|
|
|
|
|
test_cmp expected-files actual-files
|
|
|
|
|
'
|
|
|
|
|
|
2023-04-14 06:02:08 +00:00
|
|
|
test_expect_success '--geometric -l with non-intact geometric sequence across ODBs' '
|
|
|
|
|
test_when_finished "rm -fr shared member" &&
|
|
|
|
|
|
|
|
|
|
git init shared &&
|
|
|
|
|
test_commit_bulk -C shared --start=1 1 &&
|
|
|
|
|
|
|
|
|
|
git clone --shared shared member &&
|
|
|
|
|
test_commit_bulk -C member --start=2 1 &&
|
|
|
|
|
|
|
|
|
|
# Verify that our assumptions actually hold: both generated packfiles
|
|
|
|
|
# should have three objects and should be non-equal.
|
|
|
|
|
packed_objects shared/.git/objects/pack/pack-*.idx >shared-objects &&
|
|
|
|
|
packed_objects member/.git/objects/pack/pack-*.idx >member-objects &&
|
|
|
|
|
test_line_count = 3 shared-objects &&
|
|
|
|
|
test_line_count = 3 member-objects &&
|
|
|
|
|
! test_cmp shared-objects member-objects &&
|
|
|
|
|
|
|
|
|
|
# Perform the geometric repack. With `-l`, we should only see the local
|
|
|
|
|
# packfile and thus arrive at the conclusion that the geometric
|
|
|
|
|
# sequence is intact. We thus expect no changes.
|
|
|
|
|
#
|
|
|
|
|
# Note that we are tweaking mtimes of the packfiles so that we can
|
|
|
|
|
# verify they did not change. This is done in order to detect the case
|
|
|
|
|
# where we do repack objects, but the resulting packfile is the same.
|
|
|
|
|
test-tool chmtime --verbose =0 member/.git/objects/pack/* >expected-member-packs &&
|
|
|
|
|
git -C member repack --geometric=2 -l -d &&
|
|
|
|
|
test-tool chmtime --verbose member/.git/objects/pack/* >actual-member-packs &&
|
|
|
|
|
test_cmp expected-member-packs actual-member-packs &&
|
|
|
|
|
|
|
|
|
|
{
|
|
|
|
|
packed_objects shared/.git/objects/pack/pack-*.idx &&
|
|
|
|
|
packed_objects member/.git/objects/pack/pack-*.idx
|
|
|
|
|
} | sort >expected-objects &&
|
|
|
|
|
|
|
|
|
|
# On the other hand, when doing a non-local geometric repack we should
|
|
|
|
|
# see both packfiles and thus repack them. We expect that the shared
|
|
|
|
|
# object database was not changed.
|
|
|
|
|
test-tool chmtime --verbose =0 shared/.git/objects/pack/* >expected-shared-packs &&
|
|
|
|
|
git -C member repack --geometric=2 -d &&
|
|
|
|
|
test-tool chmtime --verbose shared/.git/objects/pack/* >actual-shared-packs &&
|
|
|
|
|
test_cmp expected-shared-packs actual-shared-packs &&
|
|
|
|
|
|
|
|
|
|
# Furthermore, we expect that the member repository now has a single
|
|
|
|
|
# packfile that contains the combined shared and non-shared objects.
|
|
|
|
|
ls member/.git/objects/pack/pack-*.idx >actual &&
|
|
|
|
|
test_line_count = 1 actual &&
|
|
|
|
|
packed_objects member/.git/objects/pack/pack-*.idx >actual-objects &&
|
|
|
|
|
test_line_count = 6 actual-objects &&
|
|
|
|
|
test_cmp expected-objects actual-objects
|
|
|
|
|
'
|
|
|
|
|
|
2023-04-14 06:02:12 +00:00
|
|
|
test_expect_success '--geometric -l disables writing bitmaps with non-local packfiles' '
|
|
|
|
|
test_when_finished "rm -fr shared member" &&
|
|
|
|
|
|
|
|
|
|
git init shared &&
|
|
|
|
|
test_commit_bulk -C shared --start=1 1 &&
|
|
|
|
|
|
|
|
|
|
git clone --shared shared member &&
|
|
|
|
|
test_commit_bulk -C member --start=2 1 &&
|
|
|
|
|
|
|
|
|
|
# When performing a geometric repack with `-l` while connected to an
|
|
|
|
|
# alternate object database that has a packfile we do not have full
|
|
|
|
|
# coverage of objects. As a result, we expect that writing the bitmap
|
|
|
|
|
# will be disabled.
|
|
|
|
|
git -C member repack -l --geometric=2 --write-midx --write-bitmap-index 2>err &&
|
|
|
|
|
cat >expect <<-EOF &&
|
|
|
|
|
warning: disabling bitmap writing, as some objects are not being packed
|
|
|
|
|
EOF
|
|
|
|
|
test_cmp expect err &&
|
|
|
|
|
test_path_is_missing member/.git/objects/pack/multi-pack-index-*.bitmap &&
|
|
|
|
|
|
|
|
|
|
# On the other hand, when we repack without `-l`, we should see that
|
|
|
|
|
# the bitmap gets created.
|
|
|
|
|
git -C member repack --geometric=2 --write-midx --write-bitmap-index 2>err &&
|
|
|
|
|
test_must_be_empty err &&
|
|
|
|
|
test_path_is_file member/.git/objects/pack/multi-pack-index-*.bitmap
|
|
|
|
|
'
|
|
|
|
|
|
builtin/repack.c: add '--geometric' option
Often it is useful to both:
- have relatively few packfiles in a repository, and
- avoid having so few packfiles in a repository that we repack its
entire contents regularly
This patch implements a '--geometric=<n>' option in 'git repack'. This
allows the caller to specify that they would like each pack to be at
least a factor times as large as the previous largest pack (by object
count).
Concretely, say that a repository has 'n' packfiles, labeled P1, P2,
..., up to Pn. Each packfile has an object count equal to 'objects(Pn)'.
With a geometric factor of 'r', it should be that:
objects(Pi) > r*objects(P(i-1))
for all i in [1, n], where the packs are sorted by
objects(P1) <= objects(P2) <= ... <= objects(Pn).
Since finding a true optimal repacking is NP-hard, we approximate it
along two directions:
1. We assume that there is a cutoff of packs _before starting the
repack_ where everything to the right of that cut-off already forms
a geometric progression (or no cutoff exists and everything must be
repacked).
2. We assume that everything smaller than the cutoff count must be
repacked. This forms our base assumption, but it can also cause
even the "heavy" packs to get repacked, for e.g., if we have 6
packs containing the following number of objects:
1, 1, 1, 2, 4, 32
then we would place the cutoff between '1, 1' and '1, 2, 4, 32',
rolling up the first two packs into a pack with 2 objects. That
breaks our progression and leaves us:
2, 1, 2, 4, 32
^
(where the '^' indicates the position of our split). To restore a
progression, we move the split forward (towards larger packs)
joining each pack into our new pack until a geometric progression
is restored. Here, that looks like:
2, 1, 2, 4, 32 ~> 3, 2, 4, 32 ~> 5, 4, 32 ~> ... ~> 9, 32
^ ^ ^ ^
This has the advantage of not repacking the heavy-side of packs too
often while also only creating one new pack at a time. Another wrinkle
is that we assume that loose, indexed, and reflog'd objects are
insignificant, and lump them into any new pack that we create. This can
lead to non-idempotent results.
Suggested-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Reviewed-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-02-23 02:25:27 +00:00
|
|
|
test_done
|