What's cooking in git.git (Nov 2024, #07; Wed, 20)

What's cooking in git.git (Nov 2024, #07; Wed, 20)

[Junio C Hamano]

Here are the topics that have been cooking in my tree.  Commits
prefixed with '+' are in 'next' (being in 'next' is a sign that a
topic is stable enough to be used and are candidate to be in a
future release).  Commits prefixed with '-' are only in 'seen', and
aren't considered "accepted" at all and may be annotated with an URL
to a message that raises issues but they are no means exhaustive.  A
topic without enough support may be discarded after a long period of
no activity (of course they can be resubmit when new interests
arise).

Copies of the source code to Git live in many repositories, and the
following is a list of the ones I push into or their mirrors.  Some
repositories have only a subset of branches.

With maint, master, next, seen, todo:

	git://git.kernel.org/pub/scm/git/git.git/
	git://repo.or.cz/alt-git.git/
	https://kernel.googlesource.com/pub/scm/git/git/
	https://github.com/git/git/
	https://gitlab.com/git-scm/git/

With all the integration branches and topics broken out:

	https://github.com/gitster/git/

Even though the preformatted documentation in HTML and man format
are not sources, they are published in these repositories for
convenience (replace "htmldocs" with "manpages" for the manual
pages):

	git://git.kernel.org/pub/scm/git/git-htmldocs.git/
	https://github.com/gitster/git-htmldocs.git/

Release tarballs are available at:

	https://www.kernel.org/pub/software/scm/git/

--------------------------------------------------
[Graduated to 'master']

* ja/git-add-doc-markup (2024-11-12) 1 commit
  (merged to 'next' on 2024-11-13 at 1af6d17105)
 + doc: git-add.txt: convert to new style convention

 Documentation mark-up updates.
 
 source: <pull.1826.git.1731348891108.gitgitgadget@gmail.com>


* jt/repack-local-promisor (2024-11-12) 4 commits
  (merged to 'next' on 2024-11-13 at 895d633576)
 + index-pack: repack local links into promisor packs
 + t5300: move --window clamp test next to unclamped
 + t0410: use from-scratch server
 + t0410: make test description clearer
 (this branch is used by jt/index-pack-allow-promisor-only-while-fetching.)

 "git gc" discards any objects that are outside promisor packs that
 are referred to by an object in a promisor pack, and we do not
 refetch them from the promisor at runtime, resulting an unusable
 repository.  Work it around by including these objects in the
 referring promisor pack at the receiving end of the fetch.
 
 source: <cover.1730491845.git.jonathantanmy@google.com>


* la/trailer-info (2024-10-14) 1 commit
  (merged to 'next' on 2024-11-13 at f038e226f6)
 + trailer: spread usage of "trailer_block" language

 Renaming a handful of variables and structure fields.
 
 source: <pull.1811.git.git.1728820722580.gitgitgadget@gmail.com>

--------------------------------------------------
[New Topics]

* bc/allow-upload-pack-from-other-people (2024-11-15) 1 commit
 - Allow cloning from repositories owned by another user

 Loosen overly strict ownership check introduced in the recent past,
 to keep the promise "cloning a suspicious repository is a safe
 first step to inspect it".

 Comments?
 source: <20241115005404.3747302-2-sandals@crustytoothpaste.net>


* kn/ref-transaction-hook-with-reflog (2024-11-15) 1 commit
 - refs: don't invoke reference-transaction hook for reflogs

 The ref-transaction hook triggered for reflog updates, which has
 been corrected.

 Will merge to 'next'.
 source: <20241114-348-do-not-call-the-reference-transaction-hooks-for-reflogs-v1-1-ece7260ee3c1@gmail.com>


* bc/c23 (2024-11-18) 2 commits
  (merged to 'next' on 2024-11-20 at bd29255bf3)
 + reflog: rename unreachable
 + index-pack: rename struct thread_local

 C23 compatibility updates.

 Will merge to 'master'.
 source: <20241117013149.576671-1-sandals@crustytoothpaste.net>


* jk/gcc15 (2024-11-18) 6 commits
  (merged to 'next' on 2024-11-20 at fa92bcdeb9)
 + object-file: inline empty tree and blob literals
 + object-file: treat cached_object values as const
 + object-file: drop oid field from find_cached_object() return value
 + object-file: move empty_tree struct into find_cached_object()
 + object-file: drop confusing oid initializer of empty_tree struct
 + object-file: prefer array-of-bytes initializer for hash literals

 GCC 15 compatibility updates.

 Will merge to 'master'.
 source: <20241118095423.GA3990835@coredump.intra.peff.net>


* kh/trailer-in-glossary (2024-11-18) 1 commit
  (merged to 'next' on 2024-11-20 at fad433e2f4)
 + Documentation/glossary: describe "trailer"

 Doc updates.

 Will merge to 'master'.
 source: <ba35ba3ec212860a3151cfad582a384a50c55e6a.1731871683.git.code@khaugsbakk.name>


* en/fast-import-avoid-self-replace (2024-11-19) 1 commit
  (merged to 'next' on 2024-11-20 at 751ee6b395)
 + fast-import: avoid making replace refs point to themselves

 "git fast-import" can be tricked into a replace ref that maps an
 object to itself, which is a useless thing to do.

 Will merge to 'master'.
 source: <pull.1824.v2.git.1731968389590.gitgitgadget@gmail.com>


* jt/index-pack-allow-promisor-only-while-fetching (2024-11-20) 1 commit
  (merged to 'next' on 2024-11-20 at 9bd7657760)
 + index-pack: teach --promisor to forbid pack name

 We now ensure "index-pack" is used with the "--promisor" option
 only during a "git fetch".

 Will merge to 'master'.
 source: <20241119201016.22713-1-jonathantanmy@google.com>


* 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@pks.im>


* tb/incremental-midx-part-2 (2024-11-20) 15 commits
 - midx: implement writing incremental MIDX bitmaps
 - pack-bitmap.c: use `ewah_or_iterator` for type bitmap iterators
 - pack-bitmap.c: keep track of each layer's type bitmaps
 - ewah: implement `struct ewah_or_iterator`
 - pack-bitmap.c: apply pseudo-merge commits with incremental MIDXs
 - pack-bitmap.c: compute disk-usage with incremental MIDXs
 - pack-bitmap.c: teach `rev-list --test-bitmap` about incremental MIDXs
 - pack-bitmap.c: support bitmap pack-reuse with incremental MIDXs
 - pack-bitmap.c: teach `show_objects_for_type()` about incremental MIDXs
 - pack-bitmap.c: teach `bitmap_for_commit()` about incremental MIDXs
 - pack-bitmap.c: open and store incremental bitmap layers
 - pack-revindex: prepare for incremental MIDX bitmaps
 - Documentation: describe incremental MIDX bitmaps
 - Merge branch 'tb/pseudo-merge-bitmap-fixes' into tb/incremental-midx-part-2
 - Merge branch 'tb/incremental-midx-part-1' into tb/incremental-midx-part-2

 Incrementally updating multi-pack index files.

 Needs review.
 source: <cover.1732054032.git.me@ttaylorr.com>

--------------------------------------------------
[Cooking]

* ja/git-diff-doc-markup (2024-11-19) 5 commits
 - doc: git-diff: apply format changes to config part
 - doc: git-diff: apply format changes to diff-generate-patch
 - doc: git-diff: apply format changes to diff-format
 - doc: git-diff: apply format changes to diff-options
 - doc: git-diff: apply new documentation guidelines

 Documentation mark-up updates.

 Will merge to 'next'?
 source: <pull.1769.v4.git.1731967553.gitgitgadget@gmail.com>


* jk/test-malloc-debug-check (2024-11-14) 2 commits
  (merged to 'next' on 2024-11-15 at 4f8a448748)
 + test-lib: move malloc-debug setup after $PATH setup
  (merged to 'next' on 2024-11-13 at 9aa0331ba1)
 + test-lib: check malloc debug LD_PRELOAD before using

 Avoid build/test breakage on a system without working malloc debug
 support dynamic library.

 Will merge to 'master'.
 source: <20241111070134.GA675125@coredump.intra.peff.net>
 source: <20241114012729.GA1148710@coredump.intra.peff.net>


* ps/clar-build-improvement (2024-11-18) 4 commits
  (merged to 'next' on 2024-11-20 at d88840a15d)
 + Makefile: let clar header targets depend on their scripts
 + cmake: use verbatim arguments when invoking clar commands
 + cmake: use SH_EXE to execute clar scripts
 + t/unit-tests: convert "clar-generate.awk" into a shell script

 Fix for clar unit tests to support CMake build.

 Will merge to 'master'.
 source: <20241115-pks-clar-build-improvements-v3-0-29672bf65ec6@pks.im>


* jk/fetch-prefetch-double-free-fix (2024-11-12) 3 commits
  (merged to 'next' on 2024-11-15 at 178c112999)
 + refspec: store raw refspecs inside refspec_item
 + refspec: drop separate raw_nr count
 + fetch: adjust refspec->raw_nr when filtering prefetch refspecs

 Double-free fix.

 Will merge to 'master'.
 source: <20241112083204.GA2636868@coredump.intra.peff.net>


* pb/mergetool-errors (2024-11-13) 5 commits
 - git-difftool--helper.sh: exit upon initialize_merge_tool errors
 - git-mergetool--lib.sh: add error message for unknown tool variant
 - git-mergetool--lib.sh: add error message in 'setup_user_tool'
 - git-mergetool--lib.sh: use TOOL_MODE when erroring about unknown tool
 - completion: complete '--tool-help' in 'git mergetool'

 End-user experience of "git mergetool" when the command errors out
 has been improved.

 Will merge to 'next'?
 source: <pull.1827.git.1731459128.gitgitgadget@gmail.com>


* 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@alibaba-inc.com>


* sm/difftool (2024-11-13) 1 commit
  (merged to 'next' on 2024-11-15 at a323438b13)
 + builtin/difftool: intialize some hashmap variables

 Use of some uninitialized variables in "git difftool" has been
 corrected.

 Will merge to 'master'.
 source: <20241112162320.818091-1-simon.marchi@polymtl.ca>


* tb/multi-pack-reuse-dupfix (2024-11-15) 2 commits
  (merged to 'next' on 2024-11-16 at 32792297e5)
 + pack-objects: only perform verbatim reuse on the preferred pack
 + t5332-multi-pack-reuse.sh: demonstrate duplicate packing failure

 Object reuse code based on multi-pack-index sent an unwanted copy
 of object.

 Will merge to 'master'.
 source: <cover.1731591708.git.me@ttaylorr.com>


* ps/ref-backend-migration-optim (2024-11-08) 10 commits
 - reftable/block: optimize allocations by using scratch buffer
 - reftable/block: rename `block_writer::buf` variable
 - reftable/writer: optimize allocations by using a scratch buffer
 - refs: don't normalize log messages with `REF_SKIP_CREATE_REFLOG`
 - refs: skip collision checks in initial transactions
 - refs: use "initial" transaction semantics to migrate refs
 - refs/files: support symbolic and root refs in initial transaction
 - refs: introduce "initial" transaction flag
 - refs/files: move logic to commit initial transaction
 - refs: allow passing flags when setting up a transaction

 Optimize migration procedure between two ref backends.

 Needs review.
 source: <20241108-pks-refs-optimize-migrations-v1-0-7fd37fa80e35@pks.im>


* js/log-remerge-keep-ancestry (2024-11-12) 1 commit
 - log: --remerge-diff needs to keep around commit parents

 "git log -p --remerge-diff --reverse" was completely broken.

 Expecting a hopefully small and final reroll.
 cf. <xmqqa5e5berx.fsf@gitster.g>
 source: <pull.1825.v2.git.1731350009491.gitgitgadget@gmail.com>


* ps/reftable-iterator-reuse (2024-11-19) 9 commits
 - refs/reftable: reuse iterators when reading refs
 - reftable/merged: drain priority queue on reseek
 - reftable/stack: add mechanism to notify callers on reload
 - refs/reftable: refactor reflog expiry to use reftable backend
 - refs/reftable: refactor reading symbolic refs to use reftable backend
 - refs/reftable: read references via `struct reftable_backend`
 - refs/reftable: handle reloading stacks in the reftable backend
 - refs/reftable: encapsulate reftable stack
 - Merge branch 'ps/reftable-detach' into ps/reftable-iterator-reuse
 (this branch uses ps/reftable-detach.)

 Optimize reading random references out of the reftable backend by
 allowing reuse of iterator objects.

 Needs review.
 source: <cover.1730792627.git.ps@pks.im>


* jc/move-is-bare-repository-cfg-variable-to-repo (2024-11-07) 3 commits
 - repository: BUG when is_bare_cfg is not initialized
 - setup: initialize is_bare_cfg
 - git: remove is_bare_repository_cfg global variable

 Code rewrite to turn the is_bare_repository_cfg global variable
 into a member in the the_repo singleton repository object.

 Waiting for response to reviews.
 source: <pull.1826.git.git.1730926082.gitgitgadget@gmail.com>


* jk/describe-perf (2024-11-07) 4 commits
 - describe: stop traversing when we run out of names
 - describe: stop digging for max_candidates+1
 - t/perf: add tests for git-describe
 - t6120: demonstrate weakness in disjoint-root handling

 "git describe" optimization.

 Comments?
 source: <20241106192236.GC880133@coredump.intra.peff.net>


* js/range-diff-diff-merges (2024-11-11) 1 commit
 - range-diff: optionally include merge commits' diffs in the analysis

 "git range-diff" learned to optionally show and compare merge
 commits in the ranges being compared, with the --diff-merges
 option.

 Almost there.
 cf. <CABPp-BHNVEvYx4KwmiSQhPqidhPffb5hGBt=uT5NKqBPXC4j0w@mail.gmail.com>
 source: <pull.1734.v2.git.1731073383564.gitgitgadget@gmail.com>


* 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@pks.im>


* kh/sequencer-comment-char (2024-11-13) 3 commits
 - sequencer: comment commit messages properly
 - sequencer: comment `--reference` subject line properly
 - sequencer: comment checked-out branch properly

 The sequencer failed to honor core.commentString in some places.

 Expecting a reroll to improve tests.
 cf. <5ed77fab-678d-4a06-bbd0-ea25462a7562@gmail.com>
 cf. <4c623fcf-01dd-4056-80c1-b3c860ab7f87@gmail.com>
 cf. <711b59d7-e649-4031-8924-a16fb632b4d4@gmail.com>
 source: <cover.1731406513.git.code@khaugsbakk.name>


* ds/full-name-hash (2024-11-04) 7 commits
 - test-tool: add helper for name-hash values
 - pack-objects: disable --full-name-hash when shallow
 - p5313: add size comparison test
 - git-repack: update usage to match docs
 - pack-objects: add GIT_TEST_FULL_NAME_HASH
 - repack: add --full-name-hash option
 - pack-objects: add --full-name-hash option

 "git pack-objects" and its wrapper "git repack" learned an option
 to use an alternative path-hash function to improve delta-base
 selection to produce a packfile with deeper history than window
 size.

 Needs review.
 source: <pull.1823.git.1730775907.gitgitgadget@gmail.com>


* 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@gmail.com>


* bc/ancient-ci (2024-11-01) 3 commits
 - Add additional CI jobs to avoid accidental breakage
 - ci: remove clause for Ubuntu 16.04
 - gitlab-ci: switch from Ubuntu 16.04 to 20.04

 Drop support for ancient environments in various CI jobs.

 Needs review.
 source: <20241031234934.3451390-1-sandals@crustytoothpaste.net>


* cw/worktree-extension (2024-11-01) 9 commits
 - worktree: refactor `repair_worktree_after_gitdir_move()`
 - worktree: add relative cli/config options to `repair` command
 - worktree: add relative cli/config options to `move` command
 - worktree: add relative cli/config options to `add` command
 - worktree: add `write_worktree_linking_files()` function
 - worktree: refactor infer_backlink return
 - worktree: add `relativeWorktrees` extension
 - setup: correctly reinitialize repository version
 - Merge branch 'cw/config-extensions' into cw/worktree

 Introduce a new repository extension to prevent older Git versions
 from mis-interpreting worktrees created with relative paths.

 Needs review.
 source: <20241031-wt_relative_options-v4-0-07a3dc0f02a3@pm.me>


* kh/bundle-docs (2024-11-18) 4 commits
  (merged to 'next' on 2024-11-20 at d70c2c32ce)
 + Documentation/git-bundle.txt: discuss naïve backups
 + Documentation/git-bundle.txt: mention --all in spec. refs
 + Documentation/git-bundle.txt: remove old `--all` example
 + Documentation/git-bundle.txt: mention full backup example

 Documentation improvements to more prominently call out the use of
 '--all' when creating bundles.

 Will merge to 'master'.
 source: <cover.1731768344.git.code@khaugsbakk.name>


* as/show-index-uninitialized-hash (2024-11-11) 2 commits
 - t5300: add test for 'show-index --object-format'
 - show-index: fix uninitialized hash function

 Regression fix for 'show-index' when run outside of a repository.

 Comments?
 source: <20241109092739.14276-1-abhijeet.nkt@gmail.com>


* ps/reftable-detach (2024-11-19) 8 commits
 - reftable/system: provide thin wrapper for lockfile subsystem
 - reftable/stack: drop only use of `get_locked_file_path()`
 - reftable/system: provide thin wrapper for tempfile subsystem
 - reftable/stack: stop using `fsync_component()` directly
 - reftable/system: stop depending on "hash.h"
 - reftable: explicitly handle hash format IDs
 - reftable/system: move "dir.h" to its only user
 - Merge branch 'ps/reftable-strbuf' into ps/reftable-detach
 (this branch is used by ps/reftable-iterator-reuse.)

 Isolates the reftable subsystem from the rest of Git's codebase by
 using fewer pieces of Git's infrastructure.

 Needs review.
 source: <cover.1731943954.git.ps@pks.im>


* km/config-remote-by-name (2024-10-21) 1 commit
 - config: support remote name in includeIf.hasconfig condition

 Support conditionally including configuration by remote name, instead
 of just URL.

 Needs review.
 source: <20241020173216.40852-2-ken@kmatsui.me>


* y5/diff-pager (2024-10-21) 1 commit
 - diff: setup pager only before diff contents truly ready

 Delay setting up the pager in 'git diff' until after the diff contents
 itself is fully prepared.

 Needs review.
 source: <pull.1817.git.git.1729370390416.gitgitgadget@gmail.com>


* bc/drop-ancient-libcurl-and-perl (2024-10-23) 12 commits
 - gitweb: make use of s///r
 - Require Perl 5.26.0
 - INSTALL: document requirement for libcurl 7.61.0
 - git-curl-compat: remove check for curl 7.56.0
 - git-curl-compat: remove check for curl 7.53.0
 - git-curl-compat: remove check for curl 7.52.0
 - git-curl-compat: remove check for curl 7.44.0
 - git-curl-compat: remove check for curl 7.43.0
 - git-curl-compat: remove check for curl 7.39.0
 - git-curl-compat: remove check for curl 7.34.0
 - git-curl-compat: remove check for curl 7.25.0
 - git-curl-compat: remove check for curl 7.21.5

 Drop support for older libcURL and Perl.

 Under discussion.
 source: <20241023004600.1645313-1-sandals@crustytoothpaste.net>


* es/oss-fuzz (2024-10-16) 3 commits
 - fuzz: port fuzz-url-decode-mem from OSS-Fuzz
 - fuzz: port fuzz-parse-attr-line from OSS-Fuzz
 - fuzz: port fuzz-credential-from-url-gently from OSS-Fuzz

 Backport oss-fuzz tests for us to our codebase.

 Needs review.
 source: <cover.1728939687.git.steadmon@google.com>


* bf/set-head-symref (2024-11-19) 9 commits
 - fetch set_head: handle mirrored bare repositories
 - fetch: set remote/HEAD if it does not exist
 - refs: add create_only option to refs_update_symref_extended
 - refs: add TRANSACTION_CREATE_EXISTS error
 - remote set-head: better output for --auto
 - remote set-head: refactor for readability
 - refs: atomically record overwritten ref in update_symref
 - refs: standardize output of refs_read_symbolic_ref
 - t/t5505-remote: set default branch to main

 When "git fetch $remote" notices that refs/remotes/$remote/HEAD is
 missing and discovers what branch the other side points with its
 HEAD, refs/remotes/$remote/HEAD is updated to point to it.

 Looking good.
 source: <20241118151755.756265-1-bence@ferdinandy.com>


* ps/build (2024-11-20) 23 commits
 . meson: fix conflicts with in-flight topics
 . Introduce support for the Meson build system
 . Documentation: add comparison of build systems
 . t: allow overriding build dir
 . t: better support for out-of-tree builds
 . Documentation: extract script to generate a list of mergetools
 . Documentation: teach "cmd-list.perl" about out-of-tree builds
 . Documentation: allow sourcing generated includes from separate dir
 . Makefile: simplify building of templates
 . Makefile: allow "bin-wrappers/" directory to exist
 . Makefile: refactor generators to be PWD-independent
 . Makefile: extract script to generate gitweb.js
 . Makefile: extract script to generate gitweb.cgi
 . Makefile: extract script to massage Shell scripts
 . Makefile: use "generate-perl.sh" to massage Perl library
 . Makefile: extract script to massage Perl scripts
 . Makefile: consistently use PERL_PATH
 . Makefile: generate doc versions via GIT-VERSION-GEN
 . Makefile: generate "git.rc" via GIT-VERSION-GEN
 . Makefile: propagate Git version via generated header
 . Makefile: refactor GIT-VERSION-GEN to be reusable
 . Makefile: consistently use @PLACEHOLDER@ to substitute
 . Makefile: use common template for GIT-BUILD-OPTIONS

 Build procedure update plus introduction of Mason based builds

 Getting there.
 cf. <xmqq7c8y7aep.fsf@gitster.g>
 source: <20241119-pks-meson-v8-0-809bf7f042f3@pks.im>


* ej/cat-file-remote-object-info (2024-11-11) 6 commits
 - cat-file: add remote-object-info to batch-command
 - transport: add client support for object-info
 - serve: advertise object-info feature
 - fetch-pack: move fetch initialization
 - fetch-pack: refactor packet writing
 - cat-file: add declaration of variable i inside its for loop

 "git cat-file --batch" and friends can optionally ask a remote
 server about objects it does not have.

 Needs review.
 source: <20241108162441.50736-1-eric.peijian@gmail.com>


* 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-@pks.im>
 source: <20240910163000.1985723-1-christian.couder@gmail.com>


* 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>


* js/libgit-rust (2024-10-16) 5 commits
 - Makefile: add option to build and test libgit-rs and libgit-rs-sys
 - libgit: add higher-level libgit crate
 - libgit-sys: also export some config_set functions
 - libgit-sys: introduce Rust wrapper for libgit.a
 - common-main: split init and exit code into new files

 An rust binding to libgit.a functions has been introduced.

 Needs review.
 source: <cover.1729032373.git.steadmon@google.com>


* kn/the-repository (2024-11-12) 9 commits
 - midx: add repository to `multi_pack_index` struct
 - config: make `packed_git_(limit|window_size)` non-global variables
 - config: make `delta_base_cache_limit` a non-global variable
 - packfile: pass down repository to `for_each_packed_object`
 - packfile: pass down repository to `has_object[_kept]_pack`
 - packfile: pass down repository to `odb_pack_name`
 - packfile: pass `repository` to static function in the file
 - packfile: use `repository` from `packed_git` directly
 - packfile: add repository to struct `packed_git`

 Various implicit uses of 'the_repoository' in the packfile code
 have been eliminated.
 source: <cover.1731323350.git.karthik.188@gmail.com>

Re: What's cooking in git.git (Nov 2024, #07; Wed, 20)

[Patrick Steinhardt]

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@pks.im>

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@alibaba-inc.com>

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@pks.im>

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@gmail.com>

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-@pks.im>
>  source: <20240910163000.1985723-1-christian.couder@gmail.com>

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

Re: What's cooking in git.git (Nov 2024, #07; Wed, 20)

[karthik nayak]

[-- Attachment #1: Type: text/plain, Size: 911 bytes --]

Junio C Hamano <gitster@pobox.com> writes:

> * kn/the-repository (2024-11-12) 9 commits
>  - midx: add repository to `multi_pack_index` struct
>  - config: make `packed_git_(limit|window_size)` non-global variables
>  - config: make `delta_base_cache_limit` a non-global variable
>  - packfile: pass down repository to `for_each_packed_object`
>  - packfile: pass down repository to `has_object[_kept]_pack`
>  - packfile: pass down repository to `odb_pack_name`
>  - packfile: pass `repository` to static function in the file
>  - packfile: use `repository` from `packed_git` directly
>  - packfile: add repository to struct `packed_git`
>
>  Various implicit uses of 'the_repoository' in the packfile code
>  have been eliminated.
>  source: <cover.1731323350.git.karthik.188@gmail.com>

Anything I can do here? I think Toon and Jeff already reviewed the
previous version. Happy to reroll if needed!

Thanks

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 690 bytes --]

Re: What's cooking in git.git (Nov 2024, #07; Wed, 20)

[shejialuo]

On Wed, Nov 20, 2024 at 11:36:10AM +0100, Patrick Steinhardt wrote:
> > * 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.
> 

I have already being waiting a couple of days for more comments. And I
have submitted a new version just now.

Thanks,
Jialuo

Re: What's cooking in git.git (Nov 2024, #07; Wed, 20)

[Taylor Blau]

On Wed, Nov 20, 2024 at 05:49:34PM +0900, Junio C Hamano wrote:
> * tb/incremental-midx-part-2 (2024-11-20) 15 commits
>  - midx: implement writing incremental MIDX bitmaps
>  - pack-bitmap.c: use `ewah_or_iterator` for type bitmap iterators
>  - pack-bitmap.c: keep track of each layer's type bitmaps
>  - ewah: implement `struct ewah_or_iterator`
>  - pack-bitmap.c: apply pseudo-merge commits with incremental MIDXs
>  - pack-bitmap.c: compute disk-usage with incremental MIDXs
>  - pack-bitmap.c: teach `rev-list --test-bitmap` about incremental MIDXs
>  - pack-bitmap.c: support bitmap pack-reuse with incremental MIDXs
>  - pack-bitmap.c: teach `show_objects_for_type()` about incremental MIDXs
>  - pack-bitmap.c: teach `bitmap_for_commit()` about incremental MIDXs
>  - pack-bitmap.c: open and store incremental bitmap layers
>  - pack-revindex: prepare for incremental MIDX bitmaps
>  - Documentation: describe incremental MIDX bitmaps
>  - Merge branch 'tb/pseudo-merge-bitmap-fixes' into tb/incremental-midx-part-2
>  - Merge branch 'tb/incremental-midx-part-1' into tb/incremental-midx-part-2
>
>  Incrementally updating multi-pack index files.
>
>  Needs review.
>  source: <cover.1732054032.git.me@ttaylorr.com>

Sorry for not making clearer that I had changed the base to current
'master' for this topic, so these two merges should no longer be
necessary.

It at least seems to build and pass 'make test' just fine even when
applied on top of its old base (477ce5ccd6 (The fourth batch,
2024-08-14)). Sorry again.

> * tb/multi-pack-reuse-dupfix (2024-11-15) 2 commits
>   (merged to 'next' on 2024-11-16 at 32792297e5)
>  + pack-objects: only perform verbatim reuse on the preferred pack
>  + t5332-multi-pack-reuse.sh: demonstrate duplicate packing failure
>
>  Object reuse code based on multi-pack-index sent an unwanted copy
>  of object.
>
>  Will merge to 'master'.
>  source: <cover.1731591708.git.me@ttaylorr.com>

Thanks.

One topic I did not see is [1], which appeared not to be picked up in
this or the last cycle. That topic has been reviewed and should be in
good shape. I think the thread died down after agreeing on some
potentially interesting future improvements we could make, but I don't
think there were any outstanding issues with the current patches.

Thanks,
Taylor

[1]: https://lore.kernel.org/git/cover.1730833506.git.me@ttaylorr.com/

Re: What's cooking in git.git (Nov 2024, #07; Wed, 20)

[Junio C Hamano]

Taylor Blau <me@ttaylorr.com> writes:

> On Wed, Nov 20, 2024 at 05:49:34PM +0900, Junio C Hamano wrote:
>> * tb/incremental-midx-part-2 (2024-11-20) 15 commits
>>  - midx: implement writing incremental MIDX bitmaps
>>  - pack-bitmap.c: use `ewah_or_iterator` for type bitmap iterators
>>  - pack-bitmap.c: keep track of each layer's type bitmaps
>>  - ewah: implement `struct ewah_or_iterator`
>>  - pack-bitmap.c: apply pseudo-merge commits with incremental MIDXs
>>  - pack-bitmap.c: compute disk-usage with incremental MIDXs
>>  - pack-bitmap.c: teach `rev-list --test-bitmap` about incremental MIDXs
>>  - pack-bitmap.c: support bitmap pack-reuse with incremental MIDXs
>>  - pack-bitmap.c: teach `show_objects_for_type()` about incremental MIDXs
>>  - pack-bitmap.c: teach `bitmap_for_commit()` about incremental MIDXs
>>  - pack-bitmap.c: open and store incremental bitmap layers
>>  - pack-revindex: prepare for incremental MIDX bitmaps
>>  - Documentation: describe incremental MIDX bitmaps
>>  - Merge branch 'tb/pseudo-merge-bitmap-fixes' into tb/incremental-midx-part-2
>>  - Merge branch 'tb/incremental-midx-part-1' into tb/incremental-midx-part-2
>>
>>  Incrementally updating multi-pack index files.
>>
>>  Needs review.
>>  source: <cover.1732054032.git.me@ttaylorr.com>
>
> Sorry for not making clearer that I had changed the base to current
> 'master' for this topic, so these two merges should no longer be
> necessary.

Yeah, I know (see my other message on the topic). I just didn't see
a reason to rebase and keeping the same base is slighly easier to
compare the two iterations, with and without range-diff.

> One topic I did not see is [1], which appeared not to be picked up in
> this or the last cycle. That topic has been reviewed and should be in
> good shape. I think the thread died down after agreeing on some
> potentially interesting future improvements we could make, but I don't
> think there were any outstanding issues with the current patches.
> ...
> [1]: https://lore.kernel.org/git/cover.1730833506.git.me@ttaylorr.com/

Re: What's cooking in git.git (Nov 2024, #07; Wed, 20)

[Junio C Hamano]

Patrick Steinhardt <ps@pks.im> writes:

> On Wed, Nov 20, 2024 at 05:49:34PM +0900, Junio C Hamano wrote:
>> * ps/gc-stale-lock-warning (2024-11-20) 1 commit
> ...
> 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.

Either is probably fine, but when the commit describes a fix or an
update to an end-user observable behaviour, the command name would
make a better label to appear in "git shortlog".

>> * ps/send-pack-unhide-error-in-atomic-push (2024-11-15) 6 commits
> ...
> I'll review this patch series later this week.

Thanks.

>> * ps/leakfixes-part-10 (2024-11-13) 28 commits
>> ...
>>  Will merge to 'next'?
>>  source: <20241111-b4-pks-leak-fixes-pt10-v2-0-6154bf91f0b0@pks.im>
>
> Toon left another comment that I'll want to have a look at before
> merging this to "next".

I guess we now have a hopefully final reroll, which I saw and picked
up.

>> * 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@gmail.com>
>
> 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.

Yup, I didn't have a chance to carefully read what the new code does
yet, and didn't get an impression that anybody did either for v1 or
v2, but I may be mistaken.

>> * cc/promisor-remote-capability (2024-09-10) 4 commits
> ...
> 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.

Then I'll wait for Christian to speak up.

>> * sj/ref-contents-check (2024-11-15) 9 commits
>> ...
> I've already reviewed this version and expect a (probably final) reroll.

Thanks, I saw that (hopefully) final reroll and picked it up.

Thanks.

Re: What's cooking in git.git (Nov 2024, #07; Wed, 20)

[Kristoffer Haugsbakk]

Hi

On Wed, Nov 20, 2024, at 09:49, Junio C Hamano wrote:
> * kh/trailer-in-glossary (2024-11-18) 1 commit
>   (merged to 'next' on 2024-11-20 at fad433e2f4)
>  + Documentation/glossary: describe "trailer"
>
>  Doc updates.
>
>  Will merge to 'master'.
>  source:
> <ba35ba3ec212860a3151cfad582a384a50c55e6a.1731871683.git.code@khaugsbakk.name>

I’m just asking for future topics here, not that this needs to be changed. This
topic went into `next` pretty fast. So I didn’t get around to sending a new
version with Christian’s Ack.[1] I just let it sit there for that week in case
there was any more input. What should be done about what one might call a
trailer topic version for simple topics that might get included in `next` soon
after being proposed?

Thanks

🔗 1: https://lore.kernel.org/git/CAP8UFD3p3ts_7kvk_Zm2efhcPUcEFnLcLFPAqzb40d46BTVzyA@mail.gmail.com/

Re: What's cooking in git.git (Nov 2024, #07; Wed, 20)

[Junio C Hamano]

"Kristoffer Haugsbakk" <kristofferhaugsbakk@fastmail.com> writes:

> What should be done about what one might call a
> trailer topic version for simple topics that might get included in `next` soon
> after being proposed?

Sorry, but I do not understand what you are asking here.  Can you
elaborate?

Re: What's cooking in git.git (Nov 2024, #07; Wed, 20)

[Kristoffer Haugsbakk]

On Thu, Nov 21, 2024, at 13:59, Junio C Hamano wrote:
> "Kristoffer Haugsbakk" <kristofferhaugsbakk@fastmail.com> writes:
>
>> What should be done about what one might call a
>> trailer topic version for simple topics that might get included in `next` soon
>> after being proposed?
>
> Sorry, but I do not understand what you are asking here.  Can you
> elaborate?

The patch got an Ack from Christian.[1] The patch submitter is supposed to add
trailers like `Acked-by` in subsequent versions according to SubmittingPatches.
But this one went straight from proposal to `next` as far as I could see. And
you’re not supposed to create updates for topics which are in `next` already. Or
at least that’s my impression.

So the question is what to do about such topic updates for adding trailers when
the topic goes into `next` (apparently) straight away? I just let it sit there
for the week in case someone had any counter-proposals for the glossary entry.
So I didn’t post a v2 with the added trailer before the next What’s Cooking.

It’s not important whether the patch/commit might be missing one proposed
trailer. I’m just wondering what to do in cases like this on future topics.

🔗 1: https://lore.kernel.org/git/CAP8UFD3p3ts_7kvk_Zm2efhcPUcEFnLcLFPAqzb40d46BTVzyA@mail.gmail.com/

-- 
Kristoffer Haugsbakk

Re: What's cooking in git.git (Nov 2024, #07; Wed, 20)

[Junio C Hamano]

"Kristoffer Haugsbakk" <kristofferhaugsbakk@fastmail.com> writes:

> The patch got an Ack from Christian.[1] The patch submitter is supposed to add
> trailers like `Acked-by` in subsequent versions according to SubmittingPatches.
> But this one went straight from proposal to `next` as far as I could see.

Straight is a relative term.

You could have said "ah, thanks for an ack, here is a resend" before
I queued, provided if Christian sent his ack quicly enough.  Or if
Christian ack'ed before I queued the patch (and provided if I saw
it), I may have added it while queuing.  But the thing is, people
work in parallel and in different timezones, especially for a
trivially correct and good patch, things may not move sufficiently
slowly to allow that to happen.  And it obviously is a good thing to
allow trivially correct and good changes faster to 'next' with least
amount of bureaucracy ;-)

So I wouldn't worry much about missing Ack here or there, especially
for something that is simple and non-controversial.

One thing you can do to stop the train is to send a note saying "oh,
please hold and do not merge this to 'next' yet, since I have second
thoughts", before the merge happens, but you obviously have the same
problem that the world around you are also moving ;-).

Thanks.

Re: What's cooking in git.git (Nov 2024, #07; Wed, 20)

[Junio C Hamano]

Taylor Blau <me@ttaylorr.com> writes:

> One topic I did not see is [1], which appeared not to be picked up in
> this or the last cycle. That topic has been reviewed and should be in
> good shape. I think the thread died down after agreeing on some
> potentially interesting future improvements we could make, but I don't
> think there were any outstanding issues with the current patches.

I didn't get the impression that there was a general concensus that
it was a good implementation, but perhaps I am misremembering things.

These two patches touch only the test helpers, but I am wondering if
it becomes easier to implement on top of your later changes that
allows the production side to also access the unsafe variant of the
algorithm?

Thanks.