2007-01-06 11:16:17 +01:00
|
|
|
#ifndef REACHEABLE_H
|
|
|
|
|
#define REACHEABLE_H
|
|
|
|
|
|
2011-11-05 13:00:08 +01:00
|
|
|
struct progress;
|
2018-08-15 19:54:05 +02:00
|
|
|
struct rev_info;
|
builtin/pack-objects.c: --cruft with expiration
In a previous patch, pack-objects learned how to generate a cruft pack
so long as no objects are dropped.
This patch teaches pack-objects to handle the case where a non-never
`--cruft-expiration` value is passed. This case is slightly more
complicated than before, because we want pack-objects to save
unreachable objects which would have been pruned when there is another
recent (i.e., non-prunable) unreachable object which reaches the other.
We'll call these objects "unreachable but reachable-from-recent".
Here is how pack-objects handles `--cruft-expiration`:
- Instead of adding all objects outside of the kept pack(s) into the
packing list, only handle the ones whose mtime is within the grace
period.
- Construct a reachability traversal whose tips are the
unreachable-but-recent objects.
- Then, walk along that traversal, stopping if we reach an object in
the kept pack. At each step along the traversal, we add the object
we are visiting to the packing list.
In the majority of these cases, any object we visit in this traversal
will already be in our packing list. But we will sometimes encounter
reachable-from-recent cruft objects, which we want to retain even if
they aged out of the grace period.
The most subtle point of this process is that we actually don't need to
bother to update the rescued object's mtime. Even though we will write
an .mtimes file with a value that is older than the expiration window,
it will continue to survive cruft repacks so long as any objects which
reach it haven't aged out.
That is, a future repack will also exclude that object from the initial
packing list, only to discover it later on when doing the reachability
traversal.
Finally, stopping early once an object is found in a kept pack is safe
to do because the kept packs ordinarily represent which packs will
survive after repacking. Assuming that it _isn't_ safe to halt a
traversal early would mean that there is some ancestor object which is
missing, which implies repository corruption (i.e., the complete set of
reachable objects isn't present).
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-05-21 01:18:00 +02:00
|
|
|
struct object;
|
|
|
|
|
struct packed_git;
|
2018-08-15 19:54:05 +02:00
|
|
|
|
2022-05-21 01:17:54 +02:00
|
|
|
typedef void report_recent_object_fn(const struct object *, struct packed_git *,
|
|
|
|
|
off_t, time_t);
|
|
|
|
|
|
2019-04-29 10:28:14 +02:00
|
|
|
int add_unseen_recent_objects_to_traversal(struct rev_info *revs,
|
2022-05-21 01:17:54 +02:00
|
|
|
timestamp_t timestamp,
|
|
|
|
|
report_recent_object_fn cb,
|
|
|
|
|
int ignore_in_core_kept_packs);
|
2019-04-29 10:28:14 +02:00
|
|
|
void mark_reachable_objects(struct rev_info *revs, int mark_reflog,
|
2019-04-29 10:28:23 +02:00
|
|
|
timestamp_t mark_recent, struct progress *);
|
2007-01-06 11:16:17 +01:00
|
|
|
|
|
|
|
|
#endif
|