Re: What's cooking in git.git (Jul 2023, #02; Mon, 10)

[Taylor Blau <me@ttaylorr.com>]

On Mon, Jul 10, 2023 at 06:05:01PM -0700, Junio C Hamano wrote:
> * tb/fsck-no-progress (2023-07-10) 6 commits
>  - commit-graph.c: avoid duplicated progress output during `verify`
>  - commit-graph.c: pass progress to `verify_one_commit_graph()`
>  - commit-graph.c: iteratively verify commit-graph chains
>  - commit-graph.c: extract `verify_one_commit_graph()`
>  - fsck: suppress MIDX output with `--no-progress`
>  - fsck: suppress commit-graph output with `--no-progress`
>
>  "git fsck --no-progress" still spewed noise from the commit-graph
>  subsystem, which has been corrected.
>
>  Will merge to 'next'.
>  source: <cover.1688776280.git.me@ttaylorr.com>

Thanks, this one is fairly innocuous and shouldn't cause any problems.

> * tb/repack-cleanup (2023-07-10) 2 commits
>  - builtin/repack.c: avoid dir traversal in `collect_pack_filenames()`
>  - builtin/repack.c: only repack `.pack`s that exist
>
>  The recent change to "git repack" made it react less nicely when a
>  leftover .idx file that no longer has the corresponding .pack file
>  in the repository, which has been corrected.
>
>  Will merge to 'next'.
>  source: <cover.1689017830.git.me@ttaylorr.com>

This one is definitely a higher risk change, but I am as confident as I
can be in terms of its correctness. I sent a new version[1] to remove the
unnecessary 'ls'-to-'find' conversion, but feel free to queue either.

> * cc/repack-sift-filtered-objects-to-separate-pack (2023-07-05) 8 commits
>  - gc: add `gc.repackFilterTo` config option
>  - repack: implement `--filter-to` for storing filtered out objects
>  - gc: add `gc.repackFilter` config option
>  - repack: add `--filter=<filter-spec>` option
>  - repack: refactor finding pack prefix
>  - repack: refactor finishing pack-objects command
>  - t/helper: add 'find-pack' test-tool
>  - pack-objects: allow `--filter` without `--stdout`
>
>  "git repack" machinery learns to pay attention to the "--filter="
>  option.
>
>  Comments?
>  cf. <xmqqh6qi1byn.fsf@gitster.g>
>  source: <20230705060812.2865188-1-christian.couder@gmail.com>

This is on my review queue, sorry for the delay in responding to the
rest of the newer version.

> * jt/path-filter-fix (2023-06-13) 4 commits
>  - commit-graph: new filter ver. that fixes murmur3
>  - repo-settings: introduce commitgraph.changedPathsVersion
>  - t4216: test changed path filters with high bit paths
>  - gitformat-commit-graph: describe version 2 of BDAT
>
>  The Bloom filter used for path limited history traversal was broken
>  on systems whose "char" is unsigned; update the implementation and
>  bump the format version to 2.
>
>  Expecting a reroll.
>  cf. <c7b66d2c-cdc3-1f0f-60a0-a2ee21c277bf@github.com>
>  source: <cover.1686677910.git.jonathantanmy@google.com>

This is also on my review queue as soon as the reroll appears on the
list.

> * tb/refs-exclusion-and-packed-refs (2023-07-10) 16 commits
>  - ls-refs.c: avoid enumerating hidden refs where possible
>  - upload-pack.c: avoid enumerating hidden refs where possible
>  - builtin/receive-pack.c: avoid enumerating hidden references
>  - refs.h: implement `hidden_refs_to_excludes()`
>  - refs.h: let `for_each_namespaced_ref()` take excluded patterns
>  - revision.h: store hidden refs in a `strvec`
>  - refs/packed-backend.c: add trace2 counters for jump list
>  - refs/packed-backend.c: implement jump lists to avoid excluded pattern(s)
>  - refs/packed-backend.c: refactor `find_reference_location()`
>  - refs: plumb `exclude_patterns` argument throughout
>  - builtin/for-each-ref.c: add `--exclude` option
>  - ref-filter.c: parameterize match functions over patterns
>  - ref-filter: add `ref_filter_clear()`
>  - ref-filter: clear reachable list pointers after freeing
>  - ref-filter.h: provide `REF_FILTER_INIT`
>  - refs.c: rename `ref_filter`
>
>  Enumerating refs in the packed-refs file, while excluding refs that
>  match certain patterns, has been optimized.
>
>  Under discussion.
>  source: <cover.1689023520.git.me@ttaylorr.com>

Patrick took a look[2] at this (which you responded to), and gave an
ack, so this one should be ready to go down to 'next', too.

Thanks,
Taylor

[1]: https://lore.kernel.org/git/cover.1689096750.git.me@ttaylorr.com/
[2]: https://lore.kernel.org/git/eddehgbfqnmkhvhkacbvnqiiripbn6jvjawpy76ysfnpohsygt@a43fbutqg64z/