What's cooking in git.git (Mar 2024, #05; Tue, 19)

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-vcs/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']

* jh/trace2-missing-def-param-fix (2024-03-07) 3 commits
  (merged to 'next' on 2024-03-08 at a797cfea3c)
 + trace2: emit 'def_param' set with 'cmd_name' event
 + trace2: avoid emitting 'def_param' set more than once
 + t0211: demonstrate missing 'def_param' events for certain commands

 Some trace2 events that lacked def_param have learned to show it,
 enriching the output.

 Reviewed-by: Josh Steadmon <steadmon@google.com>
 cf. <ZejkVOVQBZhLVfHW@google.com>
 source: <pull.1679.v2.git.1709824949.gitgitgadget@gmail.com>

* jk/doc-remote-helpers-markup-fix (2024-03-07) 1 commit
  (merged to 'next' on 2024-03-08 at 2cded1c696)
 + doc/gitremote-helpers: fix missing single-quote

 Doc mark-up fix.
 source: <20240307084313.GA2072022@coredump.intra.peff.net>

* pw/rebase-i-ignore-cherry-pick-help-environment (2024-02-27) 1 commit
  (merged to 'next' on 2024-03-08 at e806ee9493)
 + rebase -i: stop setting GIT_CHERRY_PICK_HELP

 Code simplification by getting rid of code that sets an environment
 variable that is no longer used.
 source: <pull.1678.git.1709042783847.gitgitgadget@gmail.com>

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

* bb/sh-scripts-cleanup (2024-03-16) 22 commits
  (merged to 'next' on 2024-03-18 at 4501a04796)
 + git-quiltimport: avoid an unnecessary subshell
 + contrib/coverage-diff: avoid redundant pipelines
 + t/t9*: merge "grep | sed" pipelines
 + t/t8*: merge "grep | sed" pipelines
 + t/t5*: merge a "grep | sed" pipeline
 + t/t4*: merge a "grep | sed" pipeline
 + t/t3*: merge a "grep | awk" pipeline
 + t/t1*: merge a "grep | sed" pipeline
 + t/t9*: avoid redundant uses of cat
 + t/t8*: avoid redundant use of cat
 + t/t7*: avoid redundant use of cat
 + t/t6*: avoid redundant uses of cat
 + t/t5*: avoid redundant uses of cat
 + t/t4*: avoid redundant uses of cat
 + t/t3*: avoid redundant uses of cat
 + t/t1*: avoid redundant uses of cat
 + t/t0*: avoid redundant uses of cat
 + t/perf: avoid redundant use of cat
 + t/annotate-tests.sh: avoid redundant use of cat
 + t/lib-cvs.sh: avoid redundant use of cat
 + contrib/subtree/t: avoid redundant use of cat
 + doc: avoid redundant use of cat

 Shell scripts clean-up.

 Will merge to 'master'.
 source: <20240315194620.10713-1-dev+git@drbeat.li>

* bl/doc-config-fixes (2024-03-16) 2 commits
  (merged to 'next' on 2024-03-18 at a9038d5a9e)
 + docs: fix typo in git-config `--default`
 + docs: clarify file options in git-config `--edit`

 A few typoes in "git config --help" have been corrected.

 Will merge to 'master'.
 source: <20240316050149.1182867-2-brianmlyles@gmail.com>

* bl/doc-key-val-sep-fix (2024-03-18) 2 commits
  (merged to 'next' on 2024-03-18 at b2e1babb85)
 + docs: adjust trailer `separator` and `key_value_separator` language
 + docs: correct trailer `key_value_separator` description

 The documentation for "%(trailers[:options])" placeholder in the
 "--pretty" option of commands in the "git log" family has been
 updated.

 Will merge to 'master'.
 source: <20240316035612.752910-1-brianmlyles@gmail.com>

* ja/doc-formatting-fix (2024-03-16) 2 commits
  (merged to 'next' on 2024-03-18 at edde7a576d)
 + doc: fix some placeholders formating
 + doc: format alternatives in synopsis

 Documentation mark-up fix.

 Will merge to 'master'.
 source: <pull.1697.git.1710602501.gitgitgadget@gmail.com>

* la/hide-trailer-info (2024-03-16) 7 commits
 - trailer: retire trailer_info_get() from API
 - trailer: make trailer_info struct private
 - trailer: make parse_trailers() return trailer_info pointer
 - interpret-trailers: access trailer_info with new helpers
 - sequencer: use the trailer iterator
 - trailer: teach iterator about non-trailer lines
 - Merge branch 'la/format-trailer-info' into la/hide-trailer-info
 (this branch uses la/format-trailer-info.)

 The trailer API has been reshuffled a bit.
 source: <pull.1696.git.1710570428.gitgitgadget@gmail.com>

* pb/advice-merge-conflict (2024-03-18) 2 commits
 - builtin/am: allow disabling conflict advice
 - sequencer: allow disabling conflict advice

 Hints that suggest what to do after resolving conflicts can now be
 squelched by disabling advice.mergeConflict.

 Will merge to 'next'?
 source: <pull.1682.v3.git.1710623790.gitgitgadget@gmail.com>

* rs/t-prio-queue-fixes (2024-03-18) 2 commits
 - t-prio-queue: check result array bounds
 - t-prio-queue: shorten array index message

 Test clean-up.

 Will merge to 'next'.
 source: <9bf36cc8-ff27-44df-b2fb-9f959c781269@web.de>

* ps/pack-refs-auto (2024-03-18) 16 commits
 - builtin/gc: pack refs when using `git maintenance run --auto`
 - builtin/gc: forward git-gc(1)'s `--auto` flag when packing refs
 - t6500: extract objects with "17" prefix
 - builtin/gc: move `struct maintenance_run_opts`
 - builtin/pack-refs: introduce new "--auto" flag
 - builtin/pack-refs: release allocated memory
 - refs/reftable: expose auto compaction via new flag
 - refs: remove `PACK_REFS_ALL` flag
 - refs: move `struct pack_refs_opts` to where it's used
 - t/helper: drop pack-refs wrapper
 - refs/reftable: print errors on compaction failure
 - reftable/stack: gracefully handle failed auto-compaction due to locks
 - reftable/stack: use error codes when locking fails during compaction
 - reftable/error: discern locked/outdated errors
 - reftable/stack: fix error handling in `reftable_stack_init_addition()`
 - Merge branch 'ps/reftable-stack-tempfile' into ps/pack-refs-auto
 (this branch uses ps/reftable-stack-tempfile.)

 "git pack-refs" learned the "--auto" option, which is a useful
 addition to be triggered from "git gc --auto".

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

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

* bb/iso-strict-utc (2024-03-13) 1 commit
  (merged to 'next' on 2024-03-14 at d2ac616873)
 + date: make "iso-strict" conforming for the UTC timezone

 The output format for dates "iso-strict" has been tweaked to show
 a time in the Zulu timezone with "Z" suffix, instead of "+00:00".

 Will merge to 'master'.
 source: <20240313225423.11373-1-dev+git@drbeat.li>

* dg/user-manual-hash-example (2024-03-12) 1 commit
  (merged to 'next' on 2024-03-14 at 767800d3a7)
 + Documentation/user-manual.txt: example for generating object hashes

 User manual (the original one) update.

 Will merge to 'master'.
 source: <20240312104238.4920-2-dirk@gouders.net>

* jc/show-untracked-false (2024-03-13) 2 commits
 - status: allow --untracked=false and friends
 - status: unify parsing of --untracked= and status.showUntrackedFiles

 The status.showUntrackedFiles configuration variable had a name
 that tempts users to set a Boolean value expressed in our usual
 "false", "off", and "0", but it only took "no".  This has been
 corrected so "true" and its synonyms are taken as "normal", while
 "false" and its synonyms are taken as "no".

 Will merge to 'next'?
 source: <20240313173214.962532-1-gitster@pobox.com>

* js/bugreport-no-suffix-fix (2024-03-16) 1 commit
  (merged to 'next' on 2024-03-18 at 180db8ec38)
 + bugreport.c: fix a crash in `git bugreport` with `--no-suffix` option

 "git bugreport --no-suffix" was not supported and instead
 segfaulted, which has been corrected.

 Will merge to 'master'.
 source: <9c6f3f5203ae26c501a5711e2610573130bfd550.1710388817.git.gitgitgadget@gmail.com>

* jw/doc-show-untracked-files-fix (2024-03-13) 1 commit
  (merged to 'next' on 2024-03-14 at 091f64ad6c)
 + doc: status.showUntrackedFiles does not take "false"

 The status.showUntrackedFiles configuration variable was
 incorrectly documented to accept "false", which has been corrected.

 Will merge to 'master'.
 source: <pull.1686.git.git.1710279251901.gitgitgadget@gmail.com>

* ph/diff-src-dst-prefix-config (2024-03-18) 2 commits
 - diff.*Prefix: use camelCase in the doc and test titles
 - diff: add diff.srcPrefix and diff.dstPrefix configuration variables

 "git diff" and friends learned two extra configuration variables.

 Will merge to 'next'.
 source: <20240315010310.GA1901653@quokka>
 source: <xmqq8r2ioh19.fsf@gitster.g>

* ps/clone-with-includeif-onbranch (2024-03-12) 1 commit
 - t5601: exercise clones with "includeIf.*.onbranch"

 An additional test to demonstrate something I am not sure what.

 Waiting for a review response.
 cf. <xmqqo7bjjid9.fsf@gitster.g>
 source: <0bede59a53862585c49bc635f82e44e983144a7f.1710246859.git.ps@pks.im>

* bb/t0006-negative-tz-offset (2024-03-14) 1 commit
  (merged to 'next' on 2024-03-14 at 3f4751b6b2)
 + t0006: add more tests with a negative TZ offset

 More tests on showing time with negative TZ offset.

 Will merge to 'master'.
 source: <20240314085512.1827031-1-dev+git@drbeat.li>

* rj/restore-plug-leaks (2024-03-14) 1 commit
  (merged to 'next' on 2024-03-15 at ac10ae7892)
 + checkout: plug some leaks in git-restore

 Leaks from "git restore" have been plugged.

 Will merge to 'master'.
 source: <64c1c3cc-51d7-4168-9731-4389889e1449@gmail.com>

* bt/fuzz-config-parse (2024-03-15) 1 commit
 - fuzz: add fuzzer for config parsing

 A new fuzz target that exercises config parsing code.

 Will merge to 'next'?
 source: <pull.1692.v2.git.1710481652130.gitgitgadget@gmail.com>

* ds/doc-config-reflow (2024-03-14) 1 commit
 - config.txt: perform some minor reformatting

 Reflow a paragraph in the documentation source without any effect
 to the formatted text.

 Comments?
 source: <97bdaf075bf5a68554cca1731eca78aff2662907.1710444774.git.dsimic@manjaro.org>

* jc/index-pack-fsck-levels (2024-03-15) 1 commit
  (merged to 'next' on 2024-03-18 at 243c5f4125)
 + t5300: fix test_with_bad_commit()

 Test fix.

 Will merge to 'master'.
 source: <pull.1688.git.git.1710478646776.gitgitgadget@gmail.com>

* la/format-trailer-info (2024-03-15) 5 commits
 - trailer: finish formatting unification
 - trailer: begin formatting unification
 - format_trailer_info(): append newline for non-trailer lines
 - format_trailer_info(): drop redundant unfold_value()
 - format_trailer_info(): use trailer_item objects
 (this branch is used by la/hide-trailer-info.)

 The code to format trailers have been cleaned up.

 Comments?
 source: <pull.1694.git.1710485706.gitgitgadget@gmail.com>

* rs/config-comment (2024-03-15) 3 commits
 - config: allow tweaking whitespace between value and comment
 - config: fix --comment formatting
 - config: add --comment option to add a comment

 "git config" learned "--comment=<message>" option to leave a
 comment immediately after the "variable = value" on the same line
 in the configuration file.

 Waiting for review response.
 cf. <xmqq8r2jp2eq.fsf@gitster.g>
 source: <pull.1681.v2.git.1709824540636.gitgitgadget@gmail.com>

* jc/safe-implicit-bare (2024-03-11) 1 commit
  (merged to 'next' on 2024-03-14 at e8bdbed1a4)
 + setup: notice more types of implicit bare repositories

 Users with safe.bareRepository=explicit can still work from within
 $GIT_DIR of a seconary worktree (which resides at .git/worktrees/$name/)
 of the primary worktree without explicitly specifying the $GIT_DIR
 environment variable or the --git-dir=<path> option.

 Will merge to 'master'.
 source: <xmqq5xxv0ywi.fsf_-_@gitster.g>

* pw/checkout-conflict-errorfix (2024-03-14) 5 commits
 - checkout: fix interaction between --conflict and --merge
 - checkout: cleanup --conflict=<style> parsing
 - merge options: add a conflict style member
 - merge-ll: introduce LL_MERGE_OPTIONS_INIT
 - xdiff-interface: refactor parsing of merge.conflictstyle

 "git checkout --conflict=bad" reported a bad conflictStyle as if it
 were given to a configuration variable; it has been corrected to
 report that the command line option is bad.

 Will merge to 'next'?
 source: <pull.1684.v2.git.1710435907.gitgitgadget@gmail.com>

* bl/cherry-pick-empty (2024-03-11) 7 commits
 - cherry-pick: add `--empty` for more robust redundant commit handling
 - cherry-pick: enforce `--keep-redundant-commits` incompatibility
 - sequencer: do not require `allow_empty` for redundant commit options
 - sequencer: treat error reading HEAD as unborn branch
 - rebase: update `--empty=ask` to `--empty=stop`
 - docs: clean up `--empty` formatting in git-rebase(1) and git-am (1)
 - docs: address inaccurate `--empty` default with `--exec`

 "cherry-pick" told to keep redundant commits needs to be allowed to
 create empty commits to do its job, but it required the user to
 give the --allow-empty option, which was unnecessary.  Its UI has
 also been tweaked a bit.

 Comments?
 source: <20240119060721.3734775-2-brianmlyles@gmail.com>

* ie/config-includeif-hostname (2024-03-10) 1 commit
 - config: learn the "hostname:" includeIf condition

 The conditional inclusion mechanism for configuration files learned
 to switch on the hostname.

 Expecting a reroll.
 cf. <fda3e8f4-fd9e-4a43-a307-c6607d982436@iencinas.com>
 source: <20240309181828.45496-2-ignacio@iencinas.com>

* ja/doc-markup-fixes (2024-03-11) 6 commits
  (merged to 'next' on 2024-03-14 at 4d1c26143f)
 + doc: git-clone: format placeholders
 + doc: git-clone: format verbatim words
 + doc: git-init: rework config item init.templateDir
 + doc: git-init: rework definition lists
 + doc: git-init: format placeholders
 + doc: git-init: format verbatim parts

 Mark-ups used in the documentation has been improved for
 consistency.

 Will merge to 'master'.
 source: <pull.1687.git.1710097830.gitgitgadget@gmail.com>

* jk/doc-remote-helper-object-format-option (2024-03-10) 2 commits
 - doc/gitremote-helpers: match object-format option docs to code
 - t5801: fix object-format handling in git-remote-testgit

 The implementation and documentation of "object-format" option
 exchange between the Git itself and its remote helpers did not
 quite match.

 Expecting a reroll.
 cf. <20240318085208.GA604917@coredump.intra.peff.net>
 source: <20240307084735.GA2072130@coredump.intra.peff.net>

* pb/ci-win-artifact-names-fix (2024-03-11) 1 commit
  (merged to 'next' on 2024-03-14 at 5076389536)
 + ci(github): make Windows test artifacts name unique

 CI update.

 Will merge to 'master'.
 source: <pull.1688.git.1710101097072.gitgitgadget@gmail.com>

* fs/find-end-of-log-message-fix (2024-03-07) 1 commit
  (merged to 'next' on 2024-03-13 at 2bed63caaf)
 + wt-status: don't find scissors line beyond buf len

 The code to find the effective end of log message can fall into an
 endless loop, which has been corrected.

 Will merge to 'master'.
 cf. <08b9b37d-f0f8-4c1a-b72e-194202ff3d9f@nutanix.com>
 source: <20240307183743.219951-1-flosch@nutanix.com>

* jk/core-comment-string (2024-03-12) 16 commits
 - config: allow multi-byte core.commentChar
 - environment: drop comment_line_char compatibility macro
 - wt-status: drop custom comment-char stringification
 - sequencer: handle multi-byte comment characters when writing todo list
 - find multi-byte comment chars in unterminated buffers
 - find multi-byte comment chars in NUL-terminated strings
 - prefer comment_line_str to comment_line_char for printing
 - strbuf: accept a comment string for strbuf_add_commented_lines()
 - strbuf: accept a comment string for strbuf_commented_addf()
 - strbuf: accept a comment string for strbuf_stripspace()
 - environment: store comment_line_char as a string
 - strbuf: avoid shadowing global comment_line_char name
 - commit: refactor base-case of adjust_comment_line_char()
 - strbuf: avoid static variables in strbuf_add_commented_lines()
 - strbuf: simplify comment-handling in add_lines() helper
 - config: forbid newline as core.commentChar

 core.commentChar used to be limited to a single byte, but has been
 updated to allow an arbitrary multi-byte sequence.

 Waiting for the discussion to settle.
 cf. <20240315081041.GA1753560@coredump.intra.peff.net>
 source: <20240312091013.GA95442@coredump.intra.peff.net>

* js/build-fuzz-more-often (2024-03-05) 3 commits
 - SQUASH???
 - fuzz: link fuzz programs with `make all` on Linux
 - ci: also define CXX environment variable

 In addition to building the objects needed, try to link the objects
 that are used in fuzzer tests, to make sure at least they build
 without bitrot, in Linux CI runs.

 Comments?
 source: <cover.1709673020.git.steadmon@google.com>

* ps/reftable-block-search-fix (2024-03-07) 2 commits
  (merged to 'next' on 2024-03-13 at 34938e24ab)
 + reftable/block: fix binary search over restart counter
 + reftable/record: fix memory leak when decoding object records

 The reftable code has its own custom binary search function whose
 comparison callback has an unusual interface, which caused the
 binary search to degenerate into a linear search, which has been
 corrected.

 Will merge to 'master'.
 source: <cover.1709843663.git.ps@pks.im>

* ps/reftable-reflog-iteration-perf (2024-03-05) 8 commits
  (merged to 'next' on 2024-03-14 at 72465c29be)
 + refs/reftable: track last log record name via strbuf
 + reftable/record: use scratch buffer when decoding records
 + reftable/record: reuse message when decoding log records
 + reftable/record: reuse refnames when decoding log records
 + reftable/record: avoid copying author info
 + reftable/record: convert old and new object IDs to arrays
 + refs/reftable: reload correct stack when creating reflog iter
 + Merge branch 'ps/reftable-iteration-perf-part2' into ps/reftable-reflog-iteration-perf

 The code to iterate over reflogs in the reftable has been optimized
 to reduce memory allocation and deallocation.

 Reviewed-by: Josh Steadmon <steadmon@google.com>
 cf. <Ze9eX-aaWoVaqsPP@google.com>

 Will merge to 'master'.
 source: <cover.1709640322.git.ps@pks.im>

* sj/userdiff-c-sharp (2024-03-06) 1 commit
 - userdiff: better method/property matching for C#

 The userdiff patterns for C# has been updated.

 Needs review.
 source: <pull.1682.v2.git.git.1709756493673.gitgitgadget@gmail.com>

* ps/reftable-stack-tempfile (2024-03-07) 4 commits
  (merged to 'next' on 2024-03-13 at dcfb0cde8c)
 + reftable/stack: register compacted tables as tempfiles
 + reftable/stack: register lockfiles during compaction
 + reftable/stack: register new tables as tempfiles
 + lockfile: report when rollback fails
 (this branch is used by ps/pack-refs-auto.)

 The code in reftable backend that creates new table files works
 better with the tempfile framework to avoid leaving cruft after a
 failure.

 Will merge to 'master'.
 source: <cover.1709816483.git.ps@pks.im>

* rs/opt-parse-long-fixups (2024-03-03) 6 commits
  (merged to 'next' on 2024-03-13 at 3755b50794)
 + parse-options: rearrange long_name matching code
 + parse-options: normalize arg and long_name before comparison
 + parse-options: detect ambiguous self-negation
 + parse-options: factor out register_abbrev() and struct parsed_option
 + parse-options: set arg of abbreviated option lazily
 + parse-options: recognize abbreviated negated option with arg

 The parse-options code that deals with abbreviated long option
 names have been cleaned up.

 Reviewed-by: Josh Steadmon <steadmon@google.com>
 cf. <ZfDM5Or3EKw7Q9SA@google.com>

 Will merge to 'master'.
 source: <20240303121944.20627-1-l.s.r@web.de>

* cw/git-std-lib (2024-02-28) 4 commits
 - SQUASH??? get rid of apparent debugging crufts
 - test-stdlib: show that git-std-lib is independent
 - git-std-lib: introduce Git Standard Library
 - pager: include stdint.h because uintmax_t is used

 Split libgit.a out to a separate git-std-lib tor easier reuse.

 Expecting a reroll.
 source: <cover.1696021277.git.jonathantanmy@google.com>

* js/cmake-with-test-tool (2024-02-23) 2 commits
 - cmake: let `test-tool` run the unit tests, too
 - Merge branch 'js/unit-test-suite-runner' into js/cmake-with-test-tool
 (this branch uses js/unit-test-suite-runner.)

 "test-tool" is now built in CMake build to also run the unit tests.

 May want to roll it into the base topic.
 source: <pull.1666.git.1708038924522.gitgitgadget@gmail.com>

* js/unit-test-suite-runner (2024-02-23) 8 commits
 - ci: use test-tool as unit test runner on Windows
 - t/Makefile: run unit tests alongside shell tests
 - unit tests: add rule for running with test-tool
 - test-tool run-command testsuite: support unit tests
 - test-tool run-command testsuite: remove hardcoded filter
 - test-tool run-command testsuite: get shell from env
 - t0080: turn t-basic unit test into a helper
 - Merge branch 'jk/unit-tests-buildfix' into js/unit-test-suite-runner
 (this branch is used by js/cmake-with-test-tool.)

 The "test-tool" has been taught to run testsuite tests in parallel,
 bypassing the need to use the "prove" tool.

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

* bk/complete-dirname-for-am-and-format-patch (2024-01-12) 1 commit
 - completion: dir-type optargs for am, format-patch

 Command line completion support (in contrib/) has been
 updated for a few commands to complete directory names where a
 directory name is expected.

 Expecting a reroll.
 cf. <40c3a824-a961-490b-94d4-4eb23c8f713d@gmail.com>
 cf. <6683f24e-7e56-489d-be2d-8afe1fc38d2b@gmail.com>
 source: <d37781c3-6af2-409b-95a8-660a9b92d20b@smtp-relay.sendinblue.com>

* bk/complete-send-email (2024-01-12) 1 commit
 - completion: don't complete revs when --no-format-patch

 Command line completion support (in contrib/) has been taught to
 avoid offering revision names as candidates to "git send-email" when
 the command is used to send pre-generated files.

 Expecting a reroll.
 cf. <CAC4O8c88Z3ZqxH2VVaNPpEGB3moL5dJcg3cOWuLWwQ_hLrJMtA@mail.gmail.com>
 source: <a718b5ee-afb0-44bd-a299-3208fac43506@smtp-relay.sendinblue.com>

* tb/path-filter-fix (2024-01-31) 16 commits
 - bloom: introduce `deinit_bloom_filters()`
 - commit-graph: reuse existing Bloom filters where possible
 - object.h: fix mis-aligned flag bits table
 - commit-graph: new Bloom filter version that fixes murmur3
 - commit-graph: unconditionally load Bloom filters
 - bloom: prepare to discard incompatible Bloom filters
 - bloom: annotate filters with hash version
 - repo-settings: introduce commitgraph.changedPathsVersion
 - t4216: test changed path filters with high bit paths
 - t/helper/test-read-graph: implement `bloom-filters` mode
 - bloom.h: make `load_bloom_filter_from_graph()` public
 - t/helper/test-read-graph.c: extract `dump_graph_info()`
 - gitformat-commit-graph: describe version 2 of BDAT
 - commit-graph: ensure Bloom filters are read with consistent settings
 - revision.c: consult Bloom filters for root commits
 - t/t4216-log-bloom.sh: harden `test_bloom_filters_not_used()`

 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.

 Waiting for a final ack?
 cf. <ZcFjkfbsBfk7JQIH@nand.local>
 source: <cover.1706741516.git.me@ttaylorr.com>

* eb/hash-transition (2023-10-02) 30 commits
  (merged to 'next' on 2024-03-11 at 9cff2e4ab7)
 + t1016-compatObjectFormat: add tests to verify the conversion between objects
 + t1006: test oid compatibility with cat-file
 + t1006: rename sha1 to oid
 + test-lib: compute the compatibility hash so tests may use it
 + builtin/ls-tree: let the oid determine the output algorithm
 + object-file: handle compat objects in check_object_signature
 + tree-walk: init_tree_desc take an oid to get the hash algorithm
 + builtin/cat-file: let the oid determine the output algorithm
 + rev-parse: add an --output-object-format parameter
 + repository: implement extensions.compatObjectFormat
 + object-file: update object_info_extended to reencode objects
 + object-file-convert: convert commits that embed signed tags
 + object-file-convert: convert commit objects when writing
 + object-file-convert: don't leak when converting tag objects
 + object-file-convert: convert tag objects when writing
 + object-file-convert: add a function to convert trees between algorithms
 + object: factor out parse_mode out of fast-import and tree-walk into in object.h
 + cache: add a function to read an OID of a specific algorithm
 + tag: sign both hashes
 + commit: export add_header_signature to support handling signatures on tags
 + commit: convert mergetag before computing the signature of a commit
 + commit: write commits for both hashes
 + object-file: add a compat_oid_in parameter to write_object_file_flags
 + object-file: update the loose object map when writing loose objects
 + loose: compatibilty short name support
 + loose: add a mapping between SHA-1 and SHA-256 for loose objects
 + repository: add a compatibility hash algorithm
 + object-names: support input of oids in any supported hash
 + oid-array: teach oid-array to handle multiple kinds of oids
 + object-file-convert: stubs for converting from one object format to another

 Teach a repository to work with both SHA-1 and SHA-256 hash algorithms.

 Will cook in 'next'.
 cf. <xmqqv86z5359.fsf@gitster.g>
 source: <878r8l929e.fsf@gmail.froward.int.ebiederm.org>

* jc/rerere-cleanup (2023-08-25) 4 commits
 - rerere: modernize use of empty strbuf
 - rerere: try_merge() should use LL_MERGE_ERROR when it means an error
 - rerere: fix comment on handle_file() helper
 - rerere: simplify check_one_conflict() helper function

 Code clean-up.

 Not ready to be reviewed yet.
 source: <20230824205456.1231371-1-gitster@pobox.com>

Hi Junio

Note that the description here is a little out-of-date; we're no longer changing the relationship between --allow-empty and --keep-redundant-commits (and the user didn't have to manually supply --allow-empty previously). I'd summarize this as:

	Allow git-cherry-pick(1) to automatically drop redundant commits via
	a new `--empty` option, similar to the `--empty` options for
	git-rebase(1) and git-am(1). Includes a soft deprecation of
	`--keep-redundant-commits` as well as some related docs changes and
	sequencer code cleanup.

You can expect a v4 reroll tonight to address a few remaining comments. The only thing I haven't heard back on is this change [1] to the docs for the new `--empty` option, but I'm confident enough in my proposed alternative there that I'm comfortable rerolling even if I don't hear back today.

[1]: https://lore.kernel.org/git/CAHPHrSfiMbU55K2=8+hJZy1cMSRbYM77pCK8BdcAPHLvapHO_A@mail.gmail.com/

"Brian Lyles" <brianmlyles@gmail.com> writes:

Very much appreciated. I wonder if we can have a better workflow to do this, like perhaps contributors write a paragraph in the cover letter with the expectation that it will be used in the What's cooking report (which will become an entry in the Release Notes when the topic gets included in a release)?

I added a few folks who were in the review discussion to Cc: of this message.

Thanks.

On Wed, Mar 20, 2024 at 11:11 AM Junio C Hamano <gitster@pobox.com> wrote:

I think some more official process could be beneficial. As it is, I'm wholly unaware of the current process for creating release notes for git. Do the maintainers simply review merged changes and write release notes as part of cutting a release?

A strategy that I have seen work well is for any commit making a notable change (one that should appear in the release notes) to include an entry in a CHANGELOG.NEXT.md file. When cutting a release, the maintainers would move the contents of that CHANGELOG.NEXT.md file into a new section in the standard CHANGELOG.md for the release. This way, the contributor of a series is responsible for creating the changelog entry (or entries) rather than the maintainer, which can help avoid inaccuracies from a maintainer with less familiarity trying to summarize.

This has the benefit of anyone being able to easily see notable upcoming changes at any point in a release by simply looking to that CHANGELOG.NEXT.md file, rather than needing to review all of the commits added since the previous release.

Of course it does not need to be markdown, that's simply the template [1] that I"m familiar with.

[1]: https://keepachangelog.com/en/1.1.0/

Using my own series as an example, that CHANGELOG.NEXT.md might look like:

    # Unreleased changelog entries
    
    This file contains changelog entries for the next release. Maintainers will move
    these entries to CHANGELOG.md as part of cutting each release.
    
    ## Added
	- git-rebase now supports a `--empty=stop` option for consistency with
	  git-am's similar `--empty` option.
	- git-cherry-pick now supports a `--empty` option to allow more robust
	  control over what happens to redundant commits.
    
    ## Changed
	- git-cherry-pick will now error out if `--keep-redundant-commits`
	  is specified alongside `--continue`, `--skip`, `--abort`, or
	  `--quit`.
    
    ## Deprecated
	- git-rebase's `--empty=ask` has been deprecated in favor of
	  `--empty=stop`, which has the exact same behavior.
	- git-cherry-pick's `--keep-redundant-commits` has been deprecated in
	  favor of `--empty=keep`, which has the exact same behavior.
    
    ## Removed
    
    ## Fixed
	- Documentation for git-rebase's `--empty` now correctly indicates
	  the default behavior when `--exec` or `--interactive` are
	  specified.
	- git-cherry-pick will no longer error out if `--allow-empty` is used
	  while on an unborn branch.
    
    ## Security

We would of course have to decide how detailed these ought to be and what changes do and do not warrant an entry, but presumably we already have to do that as part of the current process for creating each release' notes. So long as we document those expectations, it seems like a reasonable thing to ask of contributors.

An additional benefit here is that the release notes themselves are reviewed as part of the normal patch review process, allowing reviewers to suggest edits to them alongside their code review.

The one minor headache with this process that I am aware of is that applying multiple patches that all touch that one file does lead to some conflicts. For example:

    # Added
	- Some cool new feature!
	<<<<<<< HEAD
	- A different cool new feature!
	=======
	- A third new feature!
	>>>>>>> 9b423104cd (Introduce an awesome feature)

    # Changed

In practice, the rigid structure of adding entries to the end of the list and the blank lines between sections seems to result in these usually (always?) being trivially resolved by simply accepting both sides of the conflict. That said, in the context in which I've seen this, it's been in a forge where each contributor must address this before their pull request is accepted. It may cause more annoyance for your process of accepting changes into your tree -- I'm not sure.

This is simply one idea, of course. I realize that it may not be feasible for this project, but if not then perhaps it may inspire someone else to come up with a better approach.

What are your thoughts?

"Brian Lyles" <brianmlyles@gmail.com> writes:

A few things. There is only one maintainer. There are development community members, who act as contributors and as reviewers. The maintainer manages how the 'master' branch and other integration branches advance, and a part of it is to update the release notes.

Documentation/howto/maintain-git.txt outlines the workflow the current maintainer has adopted, and it has a brief mention on the "What's cooking" report. These days, entries in the the release notes for each topic merged are mostly copied from "What's cooking" but currently, as the "howto/maintain-git" document describes, summarizing and maintaining these topic descriptions is done by the maintainer.

In the message you responded to, I was wondering if we can distribute the load even further to have original author of each topic write the initial draft of the one-paragraph description of the topic that will go in "What's cooking". Two obvious downsides are that having people write about their own work would may make the result harder to read, as they inevitably are biased by the importance of their own work ;-), and having many people write different entries may lose the consistent voice across topics being described, but the distribution of burden is certainly attractive.

It however cuts both ways.

Trying to coming up with a summary from what I can read from the discussion and the log messages is a good opportunity to find what is still unclear in the log messages of the commits in the topic. Not all contributors can write a good summary of their own work in a way that are suitable for the audience of the release notes. Also you would want to encourage the maintainer to familiarize with the topics to be able to summarize them, instead of keeping them in the dark by doing the release notes entries yourself.

On Wed, Mar 20, 2024 at 8:36 PM Junio C Hamano <gitster@pobox.com> wrote:

Got it -- that certainly provides some good context.

From looking at the history of "master", it looks like you take batches
of merges and update the patch notes as part of merging each batch in.
Also good to understand.
 

So presumably, a contributor that wanted to see the "final form" of the release notes for their patch would need to keep an eye on "What's cooking" and/or 'next' and raise any concerns to the list at that point?

I definitely think that it makes sense for the original author to write *something*.

Yes, this is certainly a possibility. That said, one big advantage of incorporating this as part of the patch submission (one way or another) might be that more people will see and have a chance to review the release notes as part of their normal review of the patch.

It seems that this is not much different from maintaining a consistent voice across commit messages. Those expectations are well documented, and commit messages are reviewed thoroughly as part of patch review. I expect that we could see similar success for the release notes.

I do see the benefit here, and if the maintainer wants to continue accepting that burden, power to them ;). I certainly would not want contributor-authored release notes to replace the maintainer being familiar with ongoing changes.

That said, it would seem that we could have our cake and eat it too -- the maintainer may still choose to familiarize themself with the topics however they wish, and simply validate the release notes instead of needing to write them from scratch. Though perhaps in practice, it is difficult to do so without some additional bias as well.

In any case, for what it's worth: as a contributor, I would certainly be willing to take on some additional burden as part of submitting a patch to ensure that my patch is well represented in the release notes. If it happens to reduce the burden on the maintainer as well, even better!

"Brian Lyles" <brianmlyles@gmail.com> writes:

While I very much like the idea of distributing the burden of coming up with an initial draft for an entry in the final release notes, I am not convinced that the approach to use a single in-tree file would work well in our distributed development style where the history is merge-heavy with many topics in flight in parallel.

I can imagine how well the approach for each contributor to give such a draft entry in the cover letter of their topic would work; it would be with much less friction compared to a single in-tree file that will be the source of merge conflicts.

Hi Junio

On Thu, Mar 21, 2024 at 8:02 AM Junio C Hamano <gitster@pobox.com> wrote:

Yes, I suspect you are right. I think the cover letter would be a good start at the very least. Would you welcome a patch to 'Documentation/SubmittingPatches' that adds a new expectation for this, or do you think this would be best handled yourself? I am interested in contributing but, as I'm sure you've noticed, I'm also quite new to the project =)

"Brian Lyles" <brianmlyles@gmail.com> writes:

I'd prefer to start with a much less official "experimental" launch of such a new workflow, instead of adding an unproven idea as if it is a new hard requirement to the SubmittingPatches document. If it works well, we can write it down later.

But even a soft launch needs some way to advertise it to the target audience, and the SubmittingPatches document is the only sensible place to do so. So, perhaps do something like this? I dunno.

------- >8 ------------- >8 ------------- >8 -------
Subject: SubmittingPatches: release-notes entry experiment

It has been the maintainer's task to prepare the description of each topic listed in the "What's cooking" report. The description is automatically picked up from the "What's cooking" report and used in the commit log message of the merge commit when the topic is merged into integration branches. These commit log messges of the merge commits are then propagated to the release notes.

The original author of a topic may be in the best position to write the initial description of a topic, but we so far lacked a formal channel for the author to tell what description to use. The usual procedure has been to see the topic described in "What's cooking" report, and then either complain about inaccurate explanation and/or offer a rewrite.

Let's try an experiment to optionally let the author propose the one paragraph description when the topic is submitted. Pick the cover letter as the logical place to do so, and describe an experimental workflow in the SubmittingPatches document.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 [for what's cooking]
 * An experimental procedure for a topic author to propose the topic
   description to be used in "What's cooking" report and in the
   release notes have been added to the SubmittingPatches document.

 Documentation/SubmittingPatches | 11 +++++++++++
 1 file changed, 11 insertions(+)

Hi Junio

On Thu, Mar 21, 2024 at 8:59 PM Junio C Hamano <gitster@pobox.com> wrote:

I would agree that it would be hard to advertise without some change there. I think that documenting an optional opportunity for now before considering if it should be a requirement later makes sense.

Would it be beneficial to request some specific heading, phrase, or other structured text such that this summary is obvious, or even easily extracted with some sort of script? Or is that perhaps overkill for now? I could see relying on any sort of automatic extraction being unreliable even with such a recommendation so perhaps it's not worth pursuing for that reason, but I could imagine it may be useful to have a standardized way to separate this release notes/what's cooking summary from the rest of the cover letter (which also acts as a summary of the series).

But in general, I think this looks like a good proposal. Thanks!

On 2024-03-22 03:47, Brian Lyles wrote:

IMHO, making it a strict requirement would only raise the bar for contributors even higher, and increase the "do this, do that" kind of traffic on the mailing list. In other words, I think it's the best to start slowly and see how many new patches will include the additional summary.

Of course, it would be nice to have a strict format in place, to allow automated parsing and extraction, but I'm not sure how many patches would actually adhere to that requirement.

On Fri, Mar 22, 2024 at 06:14:37AM +0100, Dragan Simic wrote:

While not every patch would use the format, proposing one might be a good idea nevertheless, because "clearly marked as such" is not necessarily clear for everyone. At least that way if you don't have any idea you can use the format. For instance (inspired from the k8s project):

```RELNOTE Your release note here ```

On 2024-03-22 13:39, Max Gautier wrote:

Makes sense, providing some kind of example as part of this addition to the documentation would be beneficial.

"Brian Lyles" <brianmlyles@gmail.com> writes:

We do not even know if it is a good idea, so let's start with a lightweight process that does not burden participants with too much red tape. For a series with a cover letter, the rule might end up to be as simple as "When the first paragraph of the message looks like an entry in the Release Notes, it is used as such". The " a paragraph that is 2-5 lines long, indented by three SPs, whose first line has SP-asterisk-SP instead" may be a distinct enough style that it may not require any further marking.

On 2024-03-22 02:59, Junio C Hamano wrote:

Looking good to me.