On Wed, Nov 20, 2024 at 05:49:34PM +0900, Junio C Hamano wrote: > * ps/gc-stale-lock-warning (2024-11-20) 1 commit > - builtin/gc: provide hint when maintenance hits a stale schedule lock > > Give a bit of advice/hint message when "git gc" stops finding a > lock file left by another instance of "git gc" that still is > potentially running. > > Will merge to 'next'. > source: <20241119-pks-maintenance-hint-with-stale-lock-v1-1-f9f9a98e12a0@xxxxxx> Note that this message should speak of "git maintenance", not "git gc". The confusion probably comes from the commit message's subject, which speak of "builtin/gc", which is because the implementation on these commands are both hosted in "builtin/gc.c". I'm never quite sure whether I should speak of the command or the code unit in this edge case, but this message here seems to indicate that it would be preferable to mention the actual command instead. > * ps/send-pack-unhide-error-in-atomic-push (2024-11-15) 6 commits > - push: not send push-options to server with --dry-run > - push: only ignore finish_connect() for dry-run mode > - t5543: atomic push reports exit code failure > - t5504: modernize test by moving heredocs into test bodies > - push: fix the behavior of the Done message for porcelain > - t5548: new test cases for push --porcelain and --dry-run > > "git push --atomic --porcelain" used to ignore failures from the > other side, losing the error status from the child process, which > has been corrected. > > Needs review. > source: <cover.1731603991.git.zhiyou.jx@xxxxxxxxxxxxxxx> I'll review this patch series later this week. > * ps/leakfixes-part-10 (2024-11-13) 28 commits > - t: remove TEST_PASSES_SANITIZE_LEAK annotations > - test-lib: unconditionally enable leak checking > - t: remove unneeded !SANITIZE_LEAK prerequisites > - t: mark some tests as leak free > - t5601: work around leak sanitizer issue > - git-compat-util: drop now-unused `UNLEAK()` macro > - global: drop `UNLEAK()` annotation > - t/helper: fix leaking commit graph in "read-graph" subcommand > - builtin/branch: fix leaking sorting options > - builtin/init-db: fix leaking directory paths > - builtin/help: fix leaks in `check_git_cmd()` > - help: fix leaking return value from `help_unknown_cmd()` > - help: fix leaking `struct cmdnames` > - help: refactor to not use globals for reading config > - builtin/sparse-checkout: fix leaking sanitized patterns > - split-index: fix memory leak in `move_cache_to_base_index()` > - git: refactor builtin handling to use a `struct strvec` > - git: refactor alias handling to use a `struct strvec` > - strvec: introduce new `strvec_splice()` function > - line-log: fix leak when rewriting commit parents > - bisect: fix various cases where we leak commit list items > - bisect: fix leaking commit list items in `check_merge_base()` > - bisect: fix multiple leaks in `bisect_next_all()` > - bisect: fix leaking `current_bad_oid` > - bisect: fix leaking string in `handle_bad_merge_base()` > - bisect: fix leaking good/bad terms when reading multipe times > - builtin/blame: fix leaking blame entries with `--incremental` > - Merge branch 'ps/leakfixes-part-9' into ps/leakfixes-part-10 > > Leakfixes. > > Will merge to 'next'? > source: <20241111-b4-pks-leak-fixes-pt10-v2-0-6154bf91f0b0@xxxxxx> Toon left another comment that I'll want to have a look at before merging this to "next". > * ds/path-walk-1 (2024-11-11) 6 commits > - path-walk: mark trees and blobs as UNINTERESTING > - path-walk: visit tags and cached objects > - path-walk: allow consumer to specify object types > - t6601: add helper for testing path-walk API > - test-lib-functions: add test_cmp_sorted > - path-walk: introduce an object walk by path > > Introduce a new API to visit objects in batches based on a common > path, or by type. > > Comments? > source: <pull.1818.v2.git.1731181272.gitgitgadget@xxxxxxxxx> I think what's interesting in this case is the incompatibility between the path-walk API and bitmaps. It seems like there is some push back based on this, but from my point of view the path-walk API still has uses where bitmaps don't matter that much, like in the proposed new git-backfill and git-survey tools. Both of which are of interest to me. > * cc/promisor-remote-capability (2024-09-10) 4 commits > - promisor-remote: check advertised name or URL > - Add 'promisor-remote' capability to protocol v2 > - strbuf: refactor strbuf_trim_trailing_ch() > - version: refactor strbuf_sanitize() > > The v2 protocol learned to allow the server to advertise possible > promisor remotes, and the client to respond with what promissor > remotes it uses, so that the server side can omit objects that the > client can lazily obtain from these other promissor remotes. > > Comments? I got an impression that this is premature without > finishing the discussion on a larger picture. > cf. <ZvpZv_fed_su4w2-@xxxxxx> > source: <20240910163000.1985723-1-christian.couder@xxxxxxxxx> Chris is currently writing such a doc that tries to clarify the bigger picture. So I guess we can evict this topic for now, start to discuss the vision and then once we're all on the same page start to think re-submit the topic. I've Cc'd him in case he disagrees with me. > * sj/ref-contents-check (2024-11-15) 9 commits > - ref: add symlink ref content check for files backend > - ref: check whether the target of the symref is a ref > - ref: add basic symref content check for files backend > - ref: add more strict checks for regular refs > - ref: port git-fsck(1) regular refs check for files backend > - ref: support multiple worktrees check for refs > - ref: initialize ref name outside of check functions > - ref: check the full refname instead of basename > - ref: initialize "fsck_ref_report" with zero > > "git fsck" learned to issue warnings on "curiously formatted" ref > contents that have always been taken valid but something Git > wouldn't have written itself (e.g., missing terminating end-of-line > after the full object name). > > Comments? > source: <ZzYqoai8X_Wdtbmt@ArchLinux> I've already reviewed this version and expect a (probably final) reroll. Patrick
