| Message ID | b4b842fa1e8c711af30cc93b6f1100661791416c.1612998106.git.me@ttaylorr.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | midx: implement a multi-pack reverse index | expand |
On 2/10/21 6:02 PM, Taylor Blau wrote: > + unsigned char midx_hash[GIT_MAX_RAWSZ]; I was initially thinking we should use something like 'struct object_id' here, but the hash we are storing doesn't correspond to an object, which would be confusing. I suppose this is the most correct thing to do. > - finalize_hashfile(f, NULL, CSUM_FSYNC | CSUM_HASH_IN_STREAM); > + finalize_hashfile(f, midx_hash, CSUM_FSYNC | CSUM_HASH_IN_STREAM); And this is of course correct. The issue will be what happens to 'midx_hash' in the later changes. Will keep reading. Thanks, -Stolee
On Wed, Feb 10, 2021 at 09:33:36PM -0500, Derrick Stolee wrote: > On 2/10/21 6:02 PM, Taylor Blau wrote: > > + unsigned char midx_hash[GIT_MAX_RAWSZ]; > > I was initially thinking we should use something like > 'struct object_id' here, but the hash we are storing > doesn't correspond to an object, which would be > confusing. I suppose this is the most correct thing > to do. Yeah. There are a number of places that abuse the unsigned char array inside of object_id, but there's no good reason to. Thanks, Taylor
diff --git a/midx.c b/midx.c index 34fb9de3f3..6e47c726af 100644 --- a/midx.c +++ b/midx.c @@ -837,6 +837,7 @@ static int write_midx_internal(const char *object_dir, struct multi_pack_index * { unsigned char cur_chunk, num_chunks = 0; char *midx_name; + unsigned char midx_hash[GIT_MAX_RAWSZ]; uint32_t i; struct hashfile *f = NULL; struct lock_file lk; @@ -1098,7 +1099,7 @@ static int write_midx_internal(const char *object_dir, struct multi_pack_index * written, chunk_offsets[num_chunks]); - finalize_hashfile(f, NULL, CSUM_FSYNC | CSUM_HASH_IN_STREAM); + finalize_hashfile(f, midx_hash, CSUM_FSYNC | CSUM_HASH_IN_STREAM); commit_lock_file(&lk); cleanup:
write_midx_internal() uses a hashfile to write the multi-pack index, but discards its checksum. This makes sense, since nothing that takes place after writing the MIDX cares about its checksum. That is about to change in a subsequent patch, when the optional reverse index corresponding to the MIDX will want to include the MIDX's checksum. Store the checksum of the MIDX in preparation for that. Signed-off-by: Taylor Blau <me@ttaylorr.com> --- midx.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)