2017-08-19 00:20:16 +02:00
|
|
|
#ifndef PACKFILE_H
|
|
|
|
|
#define PACKFILE_H
|
|
|
|
|
|
2018-07-25 23:56:07 +02:00
|
|
|
#include "cache.h"
|
2017-12-05 17:58:44 +01:00
|
|
|
#include "oidset.h"
|
|
|
|
|
|
2018-05-16 01:42:15 +02:00
|
|
|
/* in object-store.h */
|
|
|
|
|
struct packed_git;
|
|
|
|
|
struct object_info;
|
|
|
|
|
|
2017-08-19 00:20:16 +02:00
|
|
|
/*
|
|
|
|
|
* Generate the filename to be used for a pack file with checksum "sha1" and
|
|
|
|
|
* extension "ext". The result is written into the strbuf "buf", overwriting
|
|
|
|
|
* any existing contents. A pointer to buf->buf is returned as a convenience.
|
|
|
|
|
*
|
|
|
|
|
* Example: odb_pack_name(out, sha1, "idx") => ".git/objects/pack/pack-1234..idx"
|
|
|
|
|
*/
|
2019-04-05 20:03:41 +02:00
|
|
|
char *odb_pack_name(struct strbuf *buf, const unsigned char *sha1, const char *ext);
|
2017-08-19 00:20:16 +02:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Return the name of the (local) packfile with the specified sha1 in
|
|
|
|
|
* its name. The return value is a pointer to memory that is
|
|
|
|
|
* overwritten each time this function is called.
|
|
|
|
|
*/
|
2019-04-05 20:03:41 +02:00
|
|
|
char *sha1_pack_name(const unsigned char *sha1);
|
2017-08-19 00:20:16 +02:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Return the name of the (local) pack index file with the specified
|
|
|
|
|
* sha1 in its name. The return value is a pointer to memory that is
|
|
|
|
|
* overwritten each time this function is called.
|
|
|
|
|
*/
|
2019-04-05 20:03:41 +02:00
|
|
|
char *sha1_pack_index_name(const unsigned char *sha1);
|
2017-08-19 00:20:16 +02:00
|
|
|
|
2019-04-05 20:06:22 +02:00
|
|
|
/*
|
|
|
|
|
* Return the basename of the packfile, omitting any containing directory
|
|
|
|
|
* (e.g., "pack-1234abcd[...].pack").
|
|
|
|
|
*/
|
|
|
|
|
const char *pack_basename(struct packed_git *p);
|
|
|
|
|
|
2019-04-05 20:03:41 +02:00
|
|
|
struct packed_git *parse_pack_index(unsigned char *sha1, const char *idx_path);
|
2017-08-19 00:20:19 +02:00
|
|
|
|
2018-07-12 21:39:25 +02:00
|
|
|
typedef void each_file_in_pack_dir_fn(const char *full_path, size_t full_path_len,
|
|
|
|
|
const char *file_pach, void *data);
|
|
|
|
|
void for_each_file_in_pack_dir(const char *objdir,
|
|
|
|
|
each_file_in_pack_dir_fn fn,
|
|
|
|
|
void *data);
|
|
|
|
|
|
2017-08-19 00:20:26 +02:00
|
|
|
/* A hook to report invalid files in pack directory */
|
|
|
|
|
#define PACKDIR_FILE_PACK 1
|
|
|
|
|
#define PACKDIR_FILE_IDX 2
|
|
|
|
|
#define PACKDIR_FILE_GARBAGE 4
|
|
|
|
|
extern void (*report_garbage)(unsigned seen_bits, const char *path);
|
|
|
|
|
|
2019-04-05 20:03:41 +02:00
|
|
|
void reprepare_packed_git(struct repository *r);
|
|
|
|
|
void install_packed_git(struct repository *r, struct packed_git *pack);
|
2017-08-19 00:20:25 +02:00
|
|
|
|
2018-03-23 18:20:59 +01:00
|
|
|
struct packed_git *get_packed_git(struct repository *r);
|
|
|
|
|
struct list_head *get_packed_git_mru(struct repository *r);
|
2018-07-12 21:39:35 +02:00
|
|
|
struct multi_pack_index *get_multi_pack_index(struct repository *r);
|
midx: traverse the local MIDX first
When a repository has an alternate object directory configured, callers
can traverse through each alternate's MIDX by walking the '->next'
pointer.
But, when 'prepare_multi_pack_index_one()' loads multiple MIDXs, it
places the new ones at the front of this pointer chain, not at the end.
This can be confusing for callers such as 'git repack -ad', causing test
failures like in t7700.6 with 'GIT_TEST_MULTI_PACK_INDEX=1'.
The occurs when dropping a pack known to the local MIDX with alternates
configured that have their own MIDX. Since the alternate's MIDX is
returned via 'get_multi_pack_index()', 'midx_contains_pack()' returns
true (which is correct, since it traverses through the '->next' pointer
to find the MIDX in the chain that does contain the requested object).
But, we call 'clear_midx_file()' on 'the_repository', which drops the
MIDX at the path of the first MIDX in the chain, which (in the case of
t7700.6 is the one in the alternate).
This patch addresses that by:
- placing the local MIDX first in the chain when calling
'prepare_multi_pack_index_one()', and
- introducing a new 'get_local_multi_pack_index()', which explicitly
returns the repository-local MIDX, if any.
Don't impose an additional order on the MIDX's '->next' pointer beyond
that the first item in the chain must be local if one exists so that we
avoid a quadratic insertion.
Likewise, use 'get_local_multi_pack_index()' in
'remove_redundant_pack()' to fix the formerly broken t7700.6 when run
with 'GIT_TEST_MULTI_PACK_INDEX=1'.
Finally, note that the MIDX ordering invariant is only preserved by the
insertion order in 'prepare_packed_git()', which traverses through the
ODB's '->next' pointer, meaning we visit the local object store first.
This fragility makes this an undesirable long-term solution if more
callers are added, but it is acceptable for now since this is the only
caller.
Helped-by: Jeff King <peff@peff.net>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-28 22:22:13 +02:00
|
|
|
struct multi_pack_index *get_local_multi_pack_index(struct repository *r);
|
2018-08-20 18:52:02 +02:00
|
|
|
struct packed_git *get_all_packs(struct repository *r);
|
2018-03-23 18:20:59 +01:00
|
|
|
|
2017-08-19 00:20:26 +02:00
|
|
|
/*
|
|
|
|
|
* Give a rough count of objects in the repository. This sacrifices accuracy
|
|
|
|
|
* for speed.
|
|
|
|
|
*/
|
2019-04-06 13:34:23 +02:00
|
|
|
unsigned long repo_approximate_object_count(struct repository *r);
|
|
|
|
|
#define approximate_object_count() repo_approximate_object_count(the_repository)
|
2017-08-19 00:20:26 +02:00
|
|
|
|
2019-04-05 20:03:41 +02:00
|
|
|
struct packed_git *find_sha1_pack(const unsigned char *sha1,
|
|
|
|
|
struct packed_git *packs);
|
2017-08-19 00:20:34 +02:00
|
|
|
|
2019-04-05 20:03:41 +02:00
|
|
|
void pack_report(void);
|
2017-08-19 00:20:18 +02:00
|
|
|
|
2017-08-19 00:20:19 +02:00
|
|
|
/*
|
|
|
|
|
* mmap the index file for the specified packfile (if it is not
|
|
|
|
|
* already mmapped). Return 0 on success.
|
|
|
|
|
*/
|
2019-04-05 20:03:41 +02:00
|
|
|
int open_pack_index(struct packed_git *);
|
2017-08-19 00:20:19 +02:00
|
|
|
|
2017-08-19 00:20:21 +02:00
|
|
|
/*
|
|
|
|
|
* munmap the index file for the specified packfile (if it is
|
|
|
|
|
* currently mmapped).
|
|
|
|
|
*/
|
2019-04-05 20:03:41 +02:00
|
|
|
void close_pack_index(struct packed_git *);
|
2017-08-19 00:20:21 +02:00
|
|
|
|
2019-03-21 20:36:15 +01:00
|
|
|
int close_pack_fd(struct packed_git *p);
|
|
|
|
|
|
2019-04-05 20:03:41 +02:00
|
|
|
uint32_t get_pack_fanout(struct packed_git *p, uint32_t value);
|
2018-07-12 21:39:29 +02:00
|
|
|
|
2019-04-05 20:03:41 +02:00
|
|
|
unsigned char *use_pack(struct packed_git *, struct pack_window **, off_t, unsigned long *);
|
|
|
|
|
void close_pack_windows(struct packed_git *);
|
packfile: prepare for the existence of '*.rev' files
Specify the format of the on-disk reverse index 'pack-*.rev' file, as
well as prepare the code for the existence of such files.
The reverse index maps from pack relative positions (i.e., an index into
the array of object which is sorted by their offsets within the
packfile) to their position within the 'pack-*.idx' file. Today, this is
done by building up a list of (off_t, uint32_t) tuples for each object
(the off_t corresponding to that object's offset, and the uint32_t
corresponding to its position in the index). To convert between pack and
index position quickly, this array of tuples is radix sorted based on
its offset.
This has two major drawbacks:
First, the in-memory cost scales linearly with the number of objects in
a pack. Each 'struct revindex_entry' is sizeof(off_t) +
sizeof(uint32_t) + padding bytes for a total of 16.
To observe this, force Git to load the reverse index by, for e.g.,
running 'git cat-file --batch-check="%(objectsize:disk)"'. When asking
for a single object in a fresh clone of the kernel, Git needs to
allocate 120+ MB of memory in order to hold the reverse index in memory.
Second, the cost to sort also scales with the size of the pack.
Luckily, this is a linear function since 'load_pack_revindex()' uses a
radix sort, but this cost still must be paid once per pack per process.
As an example, it takes ~60x longer to print the _size_ of an object as
it does to print that entire object's _contents_:
Benchmark #1: git.compile cat-file --batch <obj
Time (mean ± σ): 3.4 ms ± 0.1 ms [User: 3.3 ms, System: 2.1 ms]
Range (min … max): 3.2 ms … 3.7 ms 726 runs
Benchmark #2: git.compile cat-file --batch-check="%(objectsize:disk)" <obj
Time (mean ± σ): 210.3 ms ± 8.9 ms [User: 188.2 ms, System: 23.2 ms]
Range (min … max): 193.7 ms … 224.4 ms 13 runs
Instead, avoid computing and sorting the revindex once per process by
writing it to a file when the pack itself is generated.
The format is relatively straightforward. It contains an array of
uint32_t's, the length of which is equal to the number of objects in the
pack. The ith entry in this table contains the index position of the
ith object in the pack, where "ith object in the pack" is determined by
pack offset.
One thing that the on-disk format does _not_ contain is the full (up to)
eight-byte offset corresponding to each object. This is something that
the in-memory revindex contains (it stores an off_t in 'struct
revindex_entry' along with the same uint32_t that the on-disk format
has). Omit it in the on-disk format, since knowing the index position
for some object is sufficient to get a constant-time lookup in the
pack-*.idx file to ask for an object's offset within the pack.
This trades off between the on-disk size of the 'pack-*.rev' file for
runtime to chase down the offset for some object. Even though the lookup
is constant time, the constant is heavier, since it can potentially
involve two pointer walks in v2 indexes (one to access the 4-byte offset
table, and potentially a second to access the double wide offset table).
Consider trying to map an object's pack offset to a relative position
within that pack. In a cold-cache scenario, more page faults occur while
switching between binary searching through the reverse index and
searching through the *.idx file for an object's offset. Sure enough,
with a cold cache (writing '3' into '/proc/sys/vm/drop_caches' after
'sync'ing), printing out the entire object's contents is still
marginally faster than printing its size:
Benchmark #1: git.compile cat-file --batch-check="%(objectsize:disk)" <obj >/dev/null
Time (mean ± σ): 22.6 ms ± 0.5 ms [User: 2.4 ms, System: 7.9 ms]
Range (min … max): 21.4 ms … 23.5 ms 41 runs
Benchmark #2: git.compile cat-file --batch <obj >/dev/null
Time (mean ± σ): 17.2 ms ± 0.7 ms [User: 2.8 ms, System: 5.5 ms]
Range (min … max): 15.6 ms … 18.2 ms 45 runs
(Numbers taken in the kernel after cheating and using the next patch to
generate a reverse index). There are a couple of approaches to improve
cold cache performance not pursued here:
- We could include the object offsets in the reverse index format.
Predictably, this does result in fewer page faults, but it triples
the size of the file, while simultaneously duplicating a ton of data
already available in the .idx file. (This was the original way I
implemented the format, and it did show
`--batch-check='%(objectsize:disk)'` winning out against `--batch`.)
On the other hand, this increase in size also results in a large
block-cache footprint, which could potentially hurt other workloads.
- We could store the mapping from pack to index position in more
cache-friendly way, like constructing a binary search tree from the
table and writing the values in breadth-first order. This would
result in much better locality, but the price you pay is trading
O(1) lookup in 'pack_pos_to_index()' for an O(log n) one (since you
can no longer directly index the table).
So, neither of these approaches are taken here. (Thankfully, the format
is versioned, so we are free to pursue these in the future.) But, cold
cache performance likely isn't interesting outside of one-off cases like
asking for the size of an object directly. In real-world usage, Git is
often performing many operations in the revindex (i.e., asking about
many objects rather than a single one).
The trade-off is worth it, since we will avoid the vast majority of the
cost of generating the revindex that the extra pointer chase will look
like noise in the following patch's benchmarks.
This patch describes the format and prepares callers (like in
pack-revindex.c) to be able to read *.rev files once they exist. An
implementation of the writer will appear in the next patch, and callers
will gradually begin to start using the writer in the patches that
follow after that.
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-01-26 00:37:14 +01:00
|
|
|
void close_pack_revindex(struct packed_git *);
|
2019-04-05 20:03:41 +02:00
|
|
|
void close_pack(struct packed_git *);
|
2019-07-10 00:25:37 +02:00
|
|
|
void close_object_store(struct raw_object_store *o);
|
2019-04-05 20:03:41 +02:00
|
|
|
void unuse_pack(struct pack_window **);
|
|
|
|
|
void clear_delta_base_cache(void);
|
|
|
|
|
struct packed_git *add_packed_git(const char *path, size_t path_len, int local);
|
2017-08-19 00:20:21 +02:00
|
|
|
|
2019-06-11 01:35:22 +02:00
|
|
|
/*
|
|
|
|
|
* Unlink the .pack and associated extension files.
|
|
|
|
|
* Does not unlink if 'force_delete' is false and the pack-file is
|
|
|
|
|
* marked as ".keep".
|
|
|
|
|
*/
|
2019-08-19 08:26:19 +02:00
|
|
|
void unlink_pack_path(const char *pack_name, int force_delete);
|
2019-06-11 01:35:22 +02:00
|
|
|
|
2017-08-19 00:20:32 +02:00
|
|
|
/*
|
|
|
|
|
* Make sure that a pointer access into an mmap'd index file is within bounds,
|
|
|
|
|
* and can provide at least 8 bytes of data.
|
|
|
|
|
*
|
|
|
|
|
* Note that this is only necessary for variable-length segments of the file
|
|
|
|
|
* (like the 64-bit extended offset table), as we compare the size to the
|
|
|
|
|
* fixed-length parts when we open the file.
|
|
|
|
|
*/
|
2019-04-05 20:03:41 +02:00
|
|
|
void check_pack_index_ptr(const struct packed_git *p, const void *ptr);
|
2017-08-19 00:20:32 +02:00
|
|
|
|
2018-03-22 18:40:09 +01:00
|
|
|
/*
|
|
|
|
|
* Perform binary search on a pack-index for a given oid. Packfile is expected to
|
|
|
|
|
* have a valid pack-index.
|
|
|
|
|
*
|
|
|
|
|
* See 'bsearch_hash' for more information.
|
|
|
|
|
*/
|
|
|
|
|
int bsearch_pack(const struct object_id *oid, const struct packed_git *p, uint32_t *result);
|
|
|
|
|
|
2017-08-19 00:20:31 +02:00
|
|
|
/*
|
2020-02-24 05:37:54 +01:00
|
|
|
* Write the oid of the nth object within the specified packfile into the first
|
|
|
|
|
* parameter. Open the index if it is not already open. Returns 0 on success,
|
|
|
|
|
* negative otherwise.
|
2017-08-19 00:20:31 +02:00
|
|
|
*/
|
2020-02-24 05:27:36 +01:00
|
|
|
int nth_packed_object_id(struct object_id *, struct packed_git *, uint32_t n);
|
2017-08-19 00:20:31 +02:00
|
|
|
|
2017-08-19 00:20:32 +02:00
|
|
|
/*
|
|
|
|
|
* Return the offset of the nth object within the specified packfile.
|
|
|
|
|
* The index must already be opened.
|
|
|
|
|
*/
|
2019-04-05 20:03:41 +02:00
|
|
|
off_t nth_packed_object_offset(const struct packed_git *, uint32_t n);
|
2017-08-19 00:20:31 +02:00
|
|
|
|
2017-08-19 00:20:33 +02:00
|
|
|
/*
|
|
|
|
|
* If the object named sha1 is present in the specified packfile,
|
|
|
|
|
* return its offset within the packfile; otherwise, return 0.
|
|
|
|
|
*/
|
2019-04-05 20:03:41 +02:00
|
|
|
off_t find_pack_entry_one(const unsigned char *sha1, struct packed_git *);
|
2017-08-19 00:20:33 +02:00
|
|
|
|
2019-04-05 20:03:41 +02:00
|
|
|
int is_pack_valid(struct packed_git *);
|
|
|
|
|
void *unpack_entry(struct repository *r, struct packed_git *, off_t, enum object_type *, unsigned long *);
|
|
|
|
|
unsigned long unpack_object_header_buffer(const unsigned char *buf, unsigned long len, enum object_type *type, unsigned long *sizep);
|
|
|
|
|
unsigned long get_size_from_delta(struct packed_git *, struct pack_window **, off_t);
|
|
|
|
|
int unpack_object_header(struct packed_git *, struct pack_window **, off_t *, unsigned long *);
|
2019-09-13 15:02:18 +02:00
|
|
|
off_t get_delta_base(struct packed_git *p, struct pack_window **w_curs,
|
|
|
|
|
off_t *curpos, enum object_type type,
|
|
|
|
|
off_t delta_obj_offset);
|
2017-08-19 00:20:27 +02:00
|
|
|
|
2019-04-05 20:03:41 +02:00
|
|
|
void release_pack_memory(size_t);
|
2017-08-19 00:20:20 +02:00
|
|
|
|
2017-08-19 00:20:30 +02:00
|
|
|
/* global flag to enable extra checks when accessing packed objects */
|
|
|
|
|
extern int do_check_packed_object_crc;
|
|
|
|
|
|
2019-04-05 20:03:41 +02:00
|
|
|
int packed_object_info(struct repository *r,
|
|
|
|
|
struct packed_git *pack,
|
|
|
|
|
off_t offset, struct object_info *);
|
2017-08-19 00:20:30 +02:00
|
|
|
|
2021-09-11 22:40:33 +02:00
|
|
|
void mark_bad_packed_object(struct packed_git *, const struct object_id *);
|
2021-09-11 22:42:20 +02:00
|
|
|
const struct packed_git *has_packed_and_bad(struct repository *, const struct object_id *);
|
2017-08-19 00:20:32 +02:00
|
|
|
|
packfile: introduce 'find_kept_pack_entry()'
Future callers will want a function to fill a 'struct pack_entry' for a
given object id but _only_ from its position in any kept pack(s).
In particular, an new 'git repack' mode which ensures the resulting
packs form a geometric progress by object count will mark packs that it
does not want to repack as "kept in-core", and it will want to halt a
reachability traversal as soon as it visits an object in any of the kept
packs. But, it does not want to halt the traversal at non-kept, or
.keep packs.
The obvious alternative is 'find_pack_entry()', but this doesn't quite
suffice since it only returns the first pack it finds, which may or may
not be kept (and the mru cache makes it unpredictable which one you'll
get if there are options).
Short of that, you could walk over all packs looking for the object in
each one, but it scales with the number of packs, which may be
prohibitive.
Introduce 'find_kept_pack_entry()', a function which is like
'find_pack_entry()', but only fills in objects in the kept packs.
Handle packs which have .keep files, as well as in-core kept packs
separately, since certain callers will want to distinguish one from the
other. (Though on-disk and in-core kept packs share the adjective
"kept", it is best to think of the two sets as independent.)
There is a gotcha when looking up objects that are duplicated in kept
and non-kept packs, particularly when the MIDX stores the non-kept
version and the caller asked for kept objects only. This could be
resolved by teaching the MIDX to resolve duplicates by always favoring
the kept pack (if one exists), but this breaks an assumption in existing
MIDXs, and so it would require a format change.
The benefit to changing the MIDX in this way is marginal, so we instead
have a more thorough check here which is explained with a comment.
Callers will be added in subsequent patches.
Co-authored-by: Jeff King <peff@peff.net>
Signed-off-by: Jeff King <peff@peff.net>
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 03:25:03 +01:00
|
|
|
#define ON_DISK_KEEP_PACKS 1
|
|
|
|
|
#define IN_CORE_KEEP_PACKS 2
|
|
|
|
|
|
2018-03-23 18:45:25 +01:00
|
|
|
/*
|
|
|
|
|
* Iff a pack file in the given repository contains the object named by sha1,
|
|
|
|
|
* return true and store its location to e.
|
|
|
|
|
*/
|
2019-04-05 20:03:41 +02:00
|
|
|
int find_pack_entry(struct repository *r, const struct object_id *oid, struct pack_entry *e);
|
packfile: introduce 'find_kept_pack_entry()'
Future callers will want a function to fill a 'struct pack_entry' for a
given object id but _only_ from its position in any kept pack(s).
In particular, an new 'git repack' mode which ensures the resulting
packs form a geometric progress by object count will mark packs that it
does not want to repack as "kept in-core", and it will want to halt a
reachability traversal as soon as it visits an object in any of the kept
packs. But, it does not want to halt the traversal at non-kept, or
.keep packs.
The obvious alternative is 'find_pack_entry()', but this doesn't quite
suffice since it only returns the first pack it finds, which may or may
not be kept (and the mru cache makes it unpredictable which one you'll
get if there are options).
Short of that, you could walk over all packs looking for the object in
each one, but it scales with the number of packs, which may be
prohibitive.
Introduce 'find_kept_pack_entry()', a function which is like
'find_pack_entry()', but only fills in objects in the kept packs.
Handle packs which have .keep files, as well as in-core kept packs
separately, since certain callers will want to distinguish one from the
other. (Though on-disk and in-core kept packs share the adjective
"kept", it is best to think of the two sets as independent.)
There is a gotcha when looking up objects that are duplicated in kept
and non-kept packs, particularly when the MIDX stores the non-kept
version and the caller asked for kept objects only. This could be
resolved by teaching the MIDX to resolve duplicates by always favoring
the kept pack (if one exists), but this breaks an assumption in existing
MIDXs, and so it would require a format change.
The benefit to changing the MIDX in this way is marginal, so we instead
have a more thorough check here which is explained with a comment.
Callers will be added in subsequent patches.
Co-authored-by: Jeff King <peff@peff.net>
Signed-off-by: Jeff King <peff@peff.net>
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 03:25:03 +01:00
|
|
|
int find_kept_pack_entry(struct repository *r, const struct object_id *oid, unsigned flags, struct pack_entry *e);
|
2017-08-19 00:20:35 +02:00
|
|
|
|
2019-04-05 20:03:41 +02:00
|
|
|
int has_object_pack(const struct object_id *oid);
|
packfile: introduce 'find_kept_pack_entry()'
Future callers will want a function to fill a 'struct pack_entry' for a
given object id but _only_ from its position in any kept pack(s).
In particular, an new 'git repack' mode which ensures the resulting
packs form a geometric progress by object count will mark packs that it
does not want to repack as "kept in-core", and it will want to halt a
reachability traversal as soon as it visits an object in any of the kept
packs. But, it does not want to halt the traversal at non-kept, or
.keep packs.
The obvious alternative is 'find_pack_entry()', but this doesn't quite
suffice since it only returns the first pack it finds, which may or may
not be kept (and the mru cache makes it unpredictable which one you'll
get if there are options).
Short of that, you could walk over all packs looking for the object in
each one, but it scales with the number of packs, which may be
prohibitive.
Introduce 'find_kept_pack_entry()', a function which is like
'find_pack_entry()', but only fills in objects in the kept packs.
Handle packs which have .keep files, as well as in-core kept packs
separately, since certain callers will want to distinguish one from the
other. (Though on-disk and in-core kept packs share the adjective
"kept", it is best to think of the two sets as independent.)
There is a gotcha when looking up objects that are duplicated in kept
and non-kept packs, particularly when the MIDX stores the non-kept
version and the caller asked for kept objects only. This could be
resolved by teaching the MIDX to resolve duplicates by always favoring
the kept pack (if one exists), but this breaks an assumption in existing
MIDXs, and so it would require a format change.
The benefit to changing the MIDX in this way is marginal, so we instead
have a more thorough check here which is explained with a comment.
Callers will be added in subsequent patches.
Co-authored-by: Jeff King <peff@peff.net>
Signed-off-by: Jeff King <peff@peff.net>
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 03:25:03 +01:00
|
|
|
int has_object_kept_pack(const struct object_id *oid, unsigned flags);
|
2017-08-19 00:20:36 +02:00
|
|
|
|
2019-04-05 20:03:41 +02:00
|
|
|
int has_pack_index(const unsigned char *sha1);
|
2017-08-19 00:20:37 +02:00
|
|
|
|
2017-12-05 17:58:44 +01:00
|
|
|
/*
|
|
|
|
|
* Return 1 if an object in a promisor packfile is or refers to the given
|
|
|
|
|
* object, 0 otherwise.
|
|
|
|
|
*/
|
2019-04-05 20:03:41 +02:00
|
|
|
int is_promisor_object(const struct object_id *oid);
|
2017-12-05 17:58:44 +01:00
|
|
|
|
2018-10-13 02:58:41 +02:00
|
|
|
/*
|
|
|
|
|
* Expose a function for fuzz testing.
|
|
|
|
|
*
|
|
|
|
|
* load_idx() parses a block of memory as a packfile index and puts the results
|
|
|
|
|
* into a struct packed_git.
|
|
|
|
|
*
|
|
|
|
|
* This function should not be used directly. It is exposed here only so that we
|
|
|
|
|
* have a convenient entry-point for fuzz testing. For real uses, you should
|
|
|
|
|
* probably use open_pack_index() or parse_pack_index() instead.
|
|
|
|
|
*/
|
2019-04-05 20:03:41 +02:00
|
|
|
int load_idx(const char *path, const unsigned int hashsz, void *idx_map,
|
|
|
|
|
size_t idx_size, struct packed_git *p);
|
2018-10-13 02:58:41 +02:00
|
|
|
|
2017-08-19 00:20:16 +02:00
|
|
|
#endif
|