git/pack-bitmap-write.c, branch v2.40.2

pack-bitmap-write.c: instrument number of reused bitmaps

2022-10-13T20:35:08Z

When debugging bitmap generation performance, it is useful to know how many bitmaps were generated from scratch, and how many were the result of permuting the bit-order of an existing bitmap. Keep track of the latter, and emit the count as a trace2_data line to aid in debugging. Signed-off-by: Taylor Blau Signed-off-by: Junio C Hamano

pack-bitmap-write: drop unused pack_idx_entry parameters

2022-08-28T20:23:37Z

Our write_selected_commits_v1() function takes an array of pack_idx_entry structs. We used to need them for computing commit positions, but since aa30162559 (bitmap: move `get commit positions` code to `bitmap_writer_finish`, 2022-08-14), the caller passes in a separate array of positions for us. We can drop the unused array (and its matching length parameter). Likewise, when we added write_lookup_table() in 93eb41e240 (pack-bitmap-write.c: write lookup table extension, 2022-08-14), it receives the same array of positions. So its "index" parameter was never used at all. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

pack-bitmap-write.c: write lookup table extension

2022-08-26T17:13:50Z

The bitmap lookup table extension was documented by an earlier change, but Git does not yet know how to write that extension. Teach Git to write bitmap lookup table extension. The table contains the list of `N` ` triplets. These triplets are sorted according to their commit pos (ascending order). The meaning of each data in the i'th triplet is given below: - commit_pos stores commit position (in the pack-index or midx). It is a 4 byte network byte order unsigned integer. - offset is the position (in the bitmap file) from which that commit's bitmap can be read. - xor_row is the position of the triplet in the lookup table whose bitmap is used to compress this bitmap, or `0xffffffff` if no such bitmap exists. Mentored-by: Taylor Blau Co-mentored-by: Kaartic Sivaraam Co-authored-by: Taylor Blau Signed-off-by: Abhradeep Chakraborty Reviewed-by: Taylor Blau Signed-off-by: Junio C Hamano

bitmap: move `get commit positions` code to `bitmap_writer_finish`

2022-08-26T17:13:47Z

The `write_selected_commits_v1` function takes care of writing commit positions along with their corresponding bitmaps in the disk. It is OK because this `search commit position of a given commit` algorithm is needed only once here. But in later changes of the `lookup table extension series`, we need same commit positions which means we have to run the above mentioned algorithm one more time. Move the `search commit position of a given commit` algorithm to `bitmap_writer_finish()` and use the `commit_positions` array to get commit positions of their corresponding bitmaps. Signed-off-by: Abhradeep Chakraborty Reviewed-by: Taylor Blau Signed-off-by: Junio C Hamano

pack-bitmap-write: use const for hashes

2022-07-19T15:38:17Z

The next change will use a const array when calling this method. There is no need for the non-const version, so let's do this cleanup quickly. Signed-off-by: Derrick Stolee Signed-off-by: Junio C Hamano

Merge branch 'ab/plug-leak-in-revisions'

2022-06-07T21:10:56Z

Plug the memory leaks from the trickiest API of all, the revision walker. * ab/plug-leak-in-revisions: (27 commits) revisions API: add a TODO for diff_free(&revs->diffopt) revisions API: have release_revisions() release "topo_walk_info" revisions API: have release_revisions() release "date_mode" revisions API: call diff_free(&revs->pruning) in revisions_release() revisions API: release "reflog_info" in release revisions() revisions API: clear "boundary_commits" in release_revisions() revisions API: have release_revisions() release "prune_data" revisions API: have release_revisions() release "grep_filter" revisions API: have release_revisions() release "filter" revisions API: have release_revisions() release "cmdline" revisions API: have release_revisions() release "mailmap" revisions API: have release_revisions() release "commits" revisions API users: use release_revisions() for "prune_data" users revisions API users: use release_revisions() with UNLEAK() revisions API users: use release_revisions() in builtin/log.c revisions API users: use release_revisions() in http-push.c revisions API users: add "goto cleanup" for release_revisions() stash: always have the owner of "stash_info" free it revisions API users: use release_revisions() needing REV_INFO_INIT revision.[ch]: document and move code declared around "init" ...

revisions API users: add straightforward release_revisions()

2022-04-14T06:56:08Z

Add a release_revisions() to various users of "struct rev_list" in those straightforward cases where we only need to add the release_revisions() call to the end of a block, and don't need to e.g. refactor anything to use a "goto cleanup" pattern. Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

core.fsync: introduce granular fsync control infrastructure

2022-03-10T23:10:22Z

This commit introduces the infrastructure for the core.fsync configuration knob. The repository components we want to sync are identified by flags so that we can turn on or off syncing for specific components. If core.fsyncObjectFiles is set and the core.fsync configuration also includes FSYNC_COMPONENT_LOOSE_OBJECT, we will fsync any loose objects. This picks the strictest data integrity behavior if core.fsync and core.fsyncObjectFiles are set to conflicting values. This change introduces the currently unused fsync_component helper, which will be used by a later patch that adds fsyncing to the refs backend. Actual configuration and documentation of the fsync components list are in other patches in the series to separate review of the underlying mechanism from the policy of how it's configured. Helped-by: Patrick Steinhardt Signed-off-by: Neeraj Singh Signed-off-by: Junio C Hamano

Merge branch 'ab/only-single-progress-at-once'

2022-02-25T23:47:35Z

Further tweaks on progress API. * ab/only-single-progress-at-once: pack-bitmap-write.c: don't return without stop_progress() progress API: unify stop_progress{,_msg}(), fix trace2 bug progress.c: refactor stop_progress{,_msg}() to use helpers progress.c: use dereferenced "progress" variable, not "(*p_progress)" progress.h: format and be consistent with progress.c naming progress.c tests: test some invalid usage progress.c tests: make start/stop commands on stdin progress.c test helper: add missing braces leak tests: fix a memory leak in "test-progress" helper

pack-bitmap-write.c: don't return without stop_progress()

2022-02-03T23:40:00Z

Fix a bug that's been here since 7cc8f971085 (pack-objects: implement bitmap writing, 2013-12-21), we did not call stop_progress() if we reached the early exit in this function. We could call stop_progress() before we return, but better yet is to defer calling start_progress() until we need it. For now this only matters in practice because we'd previously omit the "region_leave" for the progress trace2 event. Suggested-by: SZEDER Gábor Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano