{"thread":{"id":"61152","subject":"What's cooking in git.git (Mar 2024, #05; Tue, 19)","startedAt":"2024-03-19T16:53:11Z","lastAt":"2024-03-22T14:46:09Z","messageCount":15,"participants":["Junio C Hamano","Brian Lyles","Dragan Simic","Max Gautier"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"490935","messageId":"xmqqil1iqi37.fsf@gitster.g","threadId":"61152","inReplyTo":null,"subject":"What's cooking in git.git (Mar 2024, #05; Tue, 19)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-03-19T16:53:00Z","receivedAt":"2024-03-19T16:53:11Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Here are the topics that have been cooking in my tree.  Commits\nprefixed with '+' are in 'next' (being in 'next' is a sign that a\ntopic is stable enough to be used and are candidate to be in a\nfuture release).  Commits prefixed with '-' are only in 'seen', and\naren't considered \"accepted\" at all and may be annotated with an URL\nto a message that raises issues but they are no means exhaustive.  A\ntopic without enough support may be discarded after a long period of\nno activity (of course they can be resubmit when new interests\narise).\n\nCopies of the source code to Git live in many repositories, and the\nfollowing is a list of the ones I push into or their mirrors.  Some\nrepositories have only a subset of branches.\n\nWith maint, master, next, seen, todo:\n\n\tgit://git.kernel.org/pub/scm/git/git.git/\n\tgit://repo.or.cz/alt-git.git/\n\thttps://kernel.googlesource.com/pub/scm/git/git/\n\thttps://github.com/git/git/\n\thttps://gitlab.com/git-vcs/git/\n\nWith all the integration branches and topics broken out:\n\n\thttps://github.com/gitster/git/\n\nEven though the preformatted documentation in HTML and man format\nare not sources, they are published in these repositories for\nconvenience (replace \"htmldocs\" with \"manpages\" for the manual\npages):\n\n\tgit://git.kernel.org/pub/scm/git/git-htmldocs.git/\n\thttps://github.com/gitster/git-htmldocs.git/\n\nRelease tarballs are available at:\n\n\thttps://www.kernel.org/pub/software/scm/git/\n\n--------------------------------------------------\n[Graduated to 'master']\n\n* jh/trace2-missing-def-param-fix (2024-03-07) 3 commits\n  (merged to 'next' on 2024-03-08 at a797cfea3c)\n + trace2: emit 'def_param' set with 'cmd_name' event\n + trace2: avoid emitting 'def_param' set more than once\n + t0211: demonstrate missing 'def_param' events for certain commands\n\n Some trace2 events that lacked def_param have learned to show it,\n enriching the output.\n\n Reviewed-by: Josh Steadmon <steadmon@google.com>\n cf. <ZejkVOVQBZhLVfHW@google.com>\n source: <pull.1679.v2.git.1709824949.gitgitgadget@gmail.com>\n\n\n* jk/doc-remote-helpers-markup-fix (2024-03-07) 1 commit\n  (merged to 'next' on 2024-03-08 at 2cded1c696)\n + doc/gitremote-helpers: fix missing single-quote\n\n Doc mark-up fix.\n source: <20240307084313.GA2072022@coredump.intra.peff.net>\n\n\n* pw/rebase-i-ignore-cherry-pick-help-environment (2024-02-27) 1 commit\n  (merged to 'next' on 2024-03-08 at e806ee9493)\n + rebase -i: stop setting GIT_CHERRY_PICK_HELP\n\n Code simplification by getting rid of code that sets an environment\n variable that is no longer used.\n source: <pull.1678.git.1709042783847.gitgitgadget@gmail.com>\n\n--------------------------------------------------\n[New Topics]\n\n* bb/sh-scripts-cleanup (2024-03-16) 22 commits\n  (merged to 'next' on 2024-03-18 at 4501a04796)\n + git-quiltimport: avoid an unnecessary subshell\n + contrib/coverage-diff: avoid redundant pipelines\n + t/t9*: merge \"grep | sed\" pipelines\n + t/t8*: merge \"grep | sed\" pipelines\n + t/t5*: merge a \"grep | sed\" pipeline\n + t/t4*: merge a \"grep | sed\" pipeline\n + t/t3*: merge a \"grep | awk\" pipeline\n + t/t1*: merge a \"grep | sed\" pipeline\n + t/t9*: avoid redundant uses of cat\n + t/t8*: avoid redundant use of cat\n + t/t7*: avoid redundant use of cat\n + t/t6*: avoid redundant uses of cat\n + t/t5*: avoid redundant uses of cat\n + t/t4*: avoid redundant uses of cat\n + t/t3*: avoid redundant uses of cat\n + t/t1*: avoid redundant uses of cat\n + t/t0*: avoid redundant uses of cat\n + t/perf: avoid redundant use of cat\n + t/annotate-tests.sh: avoid redundant use of cat\n + t/lib-cvs.sh: avoid redundant use of cat\n + contrib/subtree/t: avoid redundant use of cat\n + doc: avoid redundant use of cat\n\n Shell scripts clean-up.\n\n Will merge to 'master'.\n source: <20240315194620.10713-1-dev+git@drbeat.li>\n\n\n* bl/doc-config-fixes (2024-03-16) 2 commits\n  (merged to 'next' on 2024-03-18 at a9038d5a9e)\n + docs: fix typo in git-config `--default`\n + docs: clarify file options in git-config `--edit`\n\n A few typoes in \"git config --help\" have been corrected.\n\n Will merge to 'master'.\n source: <20240316050149.1182867-2-brianmlyles@gmail.com>\n\n\n* bl/doc-key-val-sep-fix (2024-03-18) 2 commits\n  (merged to 'next' on 2024-03-18 at b2e1babb85)\n + docs: adjust trailer `separator` and `key_value_separator` language\n + docs: correct trailer `key_value_separator` description\n\n The documentation for \"%(trailers[:options])\" placeholder in the\n \"--pretty\" option of commands in the \"git log\" family has been\n updated.\n\n Will merge to 'master'.\n source: <20240316035612.752910-1-brianmlyles@gmail.com>\n\n\n* ja/doc-formatting-fix (2024-03-16) 2 commits\n  (merged to 'next' on 2024-03-18 at edde7a576d)\n + doc: fix some placeholders formating\n + doc: format alternatives in synopsis\n\n Documentation mark-up fix.\n\n Will merge to 'master'.\n source: <pull.1697.git.1710602501.gitgitgadget@gmail.com>\n\n\n* la/hide-trailer-info (2024-03-16) 7 commits\n - trailer: retire trailer_info_get() from API\n - trailer: make trailer_info struct private\n - trailer: make parse_trailers() return trailer_info pointer\n - interpret-trailers: access trailer_info with new helpers\n - sequencer: use the trailer iterator\n - trailer: teach iterator about non-trailer lines\n - Merge branch 'la/format-trailer-info' into la/hide-trailer-info\n (this branch uses la/format-trailer-info.)\n\n The trailer API has been reshuffled a bit.\n source: <pull.1696.git.1710570428.gitgitgadget@gmail.com>\n\n\n* pb/advice-merge-conflict (2024-03-18) 2 commits\n - builtin/am: allow disabling conflict advice\n - sequencer: allow disabling conflict advice\n\n Hints that suggest what to do after resolving conflicts can now be\n squelched by disabling advice.mergeConflict.\n\n Will merge to 'next'?\n source: <pull.1682.v3.git.1710623790.gitgitgadget@gmail.com>\n\n\n* rs/t-prio-queue-fixes (2024-03-18) 2 commits\n - t-prio-queue: check result array bounds\n - t-prio-queue: shorten array index message\n\n Test clean-up.\n\n Will merge to 'next'.\n source: <9bf36cc8-ff27-44df-b2fb-9f959c781269@web.de>\n\n\n* ps/pack-refs-auto (2024-03-18) 16 commits\n - builtin/gc: pack refs when using `git maintenance run --auto`\n - builtin/gc: forward git-gc(1)'s `--auto` flag when packing refs\n - t6500: extract objects with \"17\" prefix\n - builtin/gc: move `struct maintenance_run_opts`\n - builtin/pack-refs: introduce new \"--auto\" flag\n - builtin/pack-refs: release allocated memory\n - refs/reftable: expose auto compaction via new flag\n - refs: remove `PACK_REFS_ALL` flag\n - refs: move `struct pack_refs_opts` to where it's used\n - t/helper: drop pack-refs wrapper\n - refs/reftable: print errors on compaction failure\n - reftable/stack: gracefully handle failed auto-compaction due to locks\n - reftable/stack: use error codes when locking fails during compaction\n - reftable/error: discern locked/outdated errors\n - reftable/stack: fix error handling in `reftable_stack_init_addition()`\n - Merge branch 'ps/reftable-stack-tempfile' into ps/pack-refs-auto\n (this branch uses ps/reftable-stack-tempfile.)\n\n \"git pack-refs\" learned the \"--auto\" option, which is a useful\n addition to be triggered from \"git gc --auto\".\n\n Needs review.\n source: <cover.1710706118.git.ps@pks.im>\n\n--------------------------------------------------\n[Cooking]\n\n* bb/iso-strict-utc (2024-03-13) 1 commit\n  (merged to 'next' on 2024-03-14 at d2ac616873)\n + date: make \"iso-strict\" conforming for the UTC timezone\n\n The output format for dates \"iso-strict\" has been tweaked to show\n a time in the Zulu timezone with \"Z\" suffix, instead of \"+00:00\".\n\n Will merge to 'master'.\n source: <20240313225423.11373-1-dev+git@drbeat.li>\n\n\n* dg/user-manual-hash-example (2024-03-12) 1 commit\n  (merged to 'next' on 2024-03-14 at 767800d3a7)\n + Documentation/user-manual.txt: example for generating object hashes\n\n User manual (the original one) update.\n\n Will merge to 'master'.\n source: <20240312104238.4920-2-dirk@gouders.net>\n\n\n* jc/show-untracked-false (2024-03-13) 2 commits\n - status: allow --untracked=false and friends\n - status: unify parsing of --untracked= and status.showUntrackedFiles\n\n The status.showUntrackedFiles configuration variable had a name\n that tempts users to set a Boolean value expressed in our usual\n \"false\", \"off\", and \"0\", but it only took \"no\".  This has been\n corrected so \"true\" and its synonyms are taken as \"normal\", while\n \"false\" and its synonyms are taken as \"no\".\n\n Will merge to 'next'?\n source: <20240313173214.962532-1-gitster@pobox.com>\n\n\n* js/bugreport-no-suffix-fix (2024-03-16) 1 commit\n  (merged to 'next' on 2024-03-18 at 180db8ec38)\n + bugreport.c: fix a crash in `git bugreport` with `--no-suffix` option\n\n \"git bugreport --no-suffix\" was not supported and instead\n segfaulted, which has been corrected.\n\n Will merge to 'master'.\n source: <9c6f3f5203ae26c501a5711e2610573130bfd550.1710388817.git.gitgitgadget@gmail.com>\n\n\n* jw/doc-show-untracked-files-fix (2024-03-13) 1 commit\n  (merged to 'next' on 2024-03-14 at 091f64ad6c)\n + doc: status.showUntrackedFiles does not take \"false\"\n\n The status.showUntrackedFiles configuration variable was\n incorrectly documented to accept \"false\", which has been corrected.\n\n Will merge to 'master'.\n source: <pull.1686.git.git.1710279251901.gitgitgadget@gmail.com>\n\n\n* ph/diff-src-dst-prefix-config (2024-03-18) 2 commits\n - diff.*Prefix: use camelCase in the doc and test titles\n - diff: add diff.srcPrefix and diff.dstPrefix configuration variables\n\n \"git diff\" and friends learned two extra configuration variables.\n\n Will merge to 'next'.\n source: <20240315010310.GA1901653@quokka>\n source: <xmqq8r2ioh19.fsf@gitster.g>\n\n\n* ps/clone-with-includeif-onbranch (2024-03-12) 1 commit\n - t5601: exercise clones with \"includeIf.*.onbranch\"\n\n An additional test to demonstrate something I am not sure what.\n\n Waiting for a review response.\n cf. <xmqqo7bjjid9.fsf@gitster.g>\n source: <0bede59a53862585c49bc635f82e44e983144a7f.1710246859.git.ps@pks.im>\n\n\n* bb/t0006-negative-tz-offset (2024-03-14) 1 commit\n  (merged to 'next' on 2024-03-14 at 3f4751b6b2)\n + t0006: add more tests with a negative TZ offset\n\n More tests on showing time with negative TZ offset.\n\n Will merge to 'master'.\n source: <20240314085512.1827031-1-dev+git@drbeat.li>\n\n\n* rj/restore-plug-leaks (2024-03-14) 1 commit\n  (merged to 'next' on 2024-03-15 at ac10ae7892)\n + checkout: plug some leaks in git-restore\n\n Leaks from \"git restore\" have been plugged.\n\n Will merge to 'master'.\n source: <64c1c3cc-51d7-4168-9731-4389889e1449@gmail.com>\n\n\n* bt/fuzz-config-parse (2024-03-15) 1 commit\n - fuzz: add fuzzer for config parsing\n\n A new fuzz target that exercises config parsing code.\n\n Will merge to 'next'?\n source: <pull.1692.v2.git.1710481652130.gitgitgadget@gmail.com>\n\n\n* ds/doc-config-reflow (2024-03-14) 1 commit\n - config.txt: perform some minor reformatting\n\n Reflow a paragraph in the documentation source without any effect\n to the formatted text.\n\n Comments?\n source: <97bdaf075bf5a68554cca1731eca78aff2662907.1710444774.git.dsimic@manjaro.org>\n\n\n* jc/index-pack-fsck-levels (2024-03-15) 1 commit\n  (merged to 'next' on 2024-03-18 at 243c5f4125)\n + t5300: fix test_with_bad_commit()\n\n Test fix.\n\n Will merge to 'master'.\n source: <pull.1688.git.git.1710478646776.gitgitgadget@gmail.com>\n\n\n* la/format-trailer-info (2024-03-15) 5 commits\n - trailer: finish formatting unification\n - trailer: begin formatting unification\n - format_trailer_info(): append newline for non-trailer lines\n - format_trailer_info(): drop redundant unfold_value()\n - format_trailer_info(): use trailer_item objects\n (this branch is used by la/hide-trailer-info.)\n\n The code to format trailers have been cleaned up.\n\n Comments?\n source: <pull.1694.git.1710485706.gitgitgadget@gmail.com>\n\n\n* rs/config-comment (2024-03-15) 3 commits\n - config: allow tweaking whitespace between value and comment\n - config: fix --comment formatting\n - config: add --comment option to add a comment\n\n \"git config\" learned \"--comment=<message>\" option to leave a\n comment immediately after the \"variable = value\" on the same line\n in the configuration file.\n\n Waiting for review response.\n cf. <xmqq8r2jp2eq.fsf@gitster.g>\n source: <pull.1681.v2.git.1709824540636.gitgitgadget@gmail.com>\n\n\n* jc/safe-implicit-bare (2024-03-11) 1 commit\n  (merged to 'next' on 2024-03-14 at e8bdbed1a4)\n + setup: notice more types of implicit bare repositories\n\n Users with safe.bareRepository=explicit can still work from within\n $GIT_DIR of a seconary worktree (which resides at .git/worktrees/$name/)\n of the primary worktree without explicitly specifying the $GIT_DIR\n environment variable or the --git-dir=<path> option.\n\n Will merge to 'master'.\n source: <xmqq5xxv0ywi.fsf_-_@gitster.g>\n\n\n* pw/checkout-conflict-errorfix (2024-03-14) 5 commits\n - checkout: fix interaction between --conflict and --merge\n - checkout: cleanup --conflict=<style> parsing\n - merge options: add a conflict style member\n - merge-ll: introduce LL_MERGE_OPTIONS_INIT\n - xdiff-interface: refactor parsing of merge.conflictstyle\n\n \"git checkout --conflict=bad\" reported a bad conflictStyle as if it\n were given to a configuration variable; it has been corrected to\n report that the command line option is bad.\n\n Will merge to 'next'?\n source: <pull.1684.v2.git.1710435907.gitgitgadget@gmail.com>\n\n\n* bl/cherry-pick-empty (2024-03-11) 7 commits\n - cherry-pick: add `--empty` for more robust redundant commit handling\n - cherry-pick: enforce `--keep-redundant-commits` incompatibility\n - sequencer: do not require `allow_empty` for redundant commit options\n - sequencer: treat error reading HEAD as unborn branch\n - rebase: update `--empty=ask` to `--empty=stop`\n - docs: clean up `--empty` formatting in git-rebase(1) and git-am (1)\n - docs: address inaccurate `--empty` default with `--exec`\n\n \"cherry-pick\" told to keep redundant commits needs to be allowed to\n create empty commits to do its job, but it required the user to\n give the --allow-empty option, which was unnecessary.  Its UI has\n also been tweaked a bit.\n\n Comments?\n source: <20240119060721.3734775-2-brianmlyles@gmail.com>\n\n\n* ie/config-includeif-hostname (2024-03-10) 1 commit\n - config: learn the \"hostname:\" includeIf condition\n\n The conditional inclusion mechanism for configuration files learned\n to switch on the hostname.\n\n Expecting a reroll.\n cf. <fda3e8f4-fd9e-4a43-a307-c6607d982436@iencinas.com>\n source: <20240309181828.45496-2-ignacio@iencinas.com>\n\n\n* ja/doc-markup-fixes (2024-03-11) 6 commits\n  (merged to 'next' on 2024-03-14 at 4d1c26143f)\n + doc: git-clone: format placeholders\n + doc: git-clone: format verbatim words\n + doc: git-init: rework config item init.templateDir\n + doc: git-init: rework definition lists\n + doc: git-init: format placeholders\n + doc: git-init: format verbatim parts\n\n Mark-ups used in the documentation has been improved for\n consistency.\n\n Will merge to 'master'.\n source: <pull.1687.git.1710097830.gitgitgadget@gmail.com>\n\n\n* jk/doc-remote-helper-object-format-option (2024-03-10) 2 commits\n - doc/gitremote-helpers: match object-format option docs to code\n - t5801: fix object-format handling in git-remote-testgit\n\n The implementation and documentation of \"object-format\" option\n exchange between the Git itself and its remote helpers did not\n quite match.\n\n Expecting a reroll.\n cf. <20240318085208.GA604917@coredump.intra.peff.net>\n source: <20240307084735.GA2072130@coredump.intra.peff.net>\n\n\n* pb/ci-win-artifact-names-fix (2024-03-11) 1 commit\n  (merged to 'next' on 2024-03-14 at 5076389536)\n + ci(github): make Windows test artifacts name unique\n\n CI update.\n\n Will merge to 'master'.\n source: <pull.1688.git.1710101097072.gitgitgadget@gmail.com>\n\n\n* fs/find-end-of-log-message-fix (2024-03-07) 1 commit\n  (merged to 'next' on 2024-03-13 at 2bed63caaf)\n + wt-status: don't find scissors line beyond buf len\n\n The code to find the effective end of log message can fall into an\n endless loop, which has been corrected.\n\n Will merge to 'master'.\n cf. <08b9b37d-f0f8-4c1a-b72e-194202ff3d9f@nutanix.com>\n source: <20240307183743.219951-1-flosch@nutanix.com>\n\n\n* jk/core-comment-string (2024-03-12) 16 commits\n - config: allow multi-byte core.commentChar\n - environment: drop comment_line_char compatibility macro\n - wt-status: drop custom comment-char stringification\n - sequencer: handle multi-byte comment characters when writing todo list\n - find multi-byte comment chars in unterminated buffers\n - find multi-byte comment chars in NUL-terminated strings\n - prefer comment_line_str to comment_line_char for printing\n - strbuf: accept a comment string for strbuf_add_commented_lines()\n - strbuf: accept a comment string for strbuf_commented_addf()\n - strbuf: accept a comment string for strbuf_stripspace()\n - environment: store comment_line_char as a string\n - strbuf: avoid shadowing global comment_line_char name\n - commit: refactor base-case of adjust_comment_line_char()\n - strbuf: avoid static variables in strbuf_add_commented_lines()\n - strbuf: simplify comment-handling in add_lines() helper\n - config: forbid newline as core.commentChar\n\n core.commentChar used to be limited to a single byte, but has been\n updated to allow an arbitrary multi-byte sequence.\n\n Waiting for the discussion to settle.\n cf. <20240315081041.GA1753560@coredump.intra.peff.net>\n source: <20240312091013.GA95442@coredump.intra.peff.net>\n\n\n* js/build-fuzz-more-often (2024-03-05) 3 commits\n - SQUASH???\n - fuzz: link fuzz programs with `make all` on Linux\n - ci: also define CXX environment variable\n\n In addition to building the objects needed, try to link the objects\n that are used in fuzzer tests, to make sure at least they build\n without bitrot, in Linux CI runs.\n\n Comments?\n source: <cover.1709673020.git.steadmon@google.com>\n\n\n* ps/reftable-block-search-fix (2024-03-07) 2 commits\n  (merged to 'next' on 2024-03-13 at 34938e24ab)\n + reftable/block: fix binary search over restart counter\n + reftable/record: fix memory leak when decoding object records\n\n The reftable code has its own custom binary search function whose\n comparison callback has an unusual interface, which caused the\n binary search to degenerate into a linear search, which has been\n corrected.\n\n Will merge to 'master'.\n source: <cover.1709843663.git.ps@pks.im>\n\n\n* ps/reftable-reflog-iteration-perf (2024-03-05) 8 commits\n  (merged to 'next' on 2024-03-14 at 72465c29be)\n + refs/reftable: track last log record name via strbuf\n + reftable/record: use scratch buffer when decoding records\n + reftable/record: reuse message when decoding log records\n + reftable/record: reuse refnames when decoding log records\n + reftable/record: avoid copying author info\n + reftable/record: convert old and new object IDs to arrays\n + refs/reftable: reload correct stack when creating reflog iter\n + Merge branch 'ps/reftable-iteration-perf-part2' into ps/reftable-reflog-iteration-perf\n\n The code to iterate over reflogs in the reftable has been optimized\n to reduce memory allocation and deallocation.\n\n Reviewed-by: Josh Steadmon <steadmon@google.com>\n cf. <Ze9eX-aaWoVaqsPP@google.com>\n\n Will merge to 'master'.\n source: <cover.1709640322.git.ps@pks.im>\n\n\n* sj/userdiff-c-sharp (2024-03-06) 1 commit\n - userdiff: better method/property matching for C#\n\n The userdiff patterns for C# has been updated.\n\n Needs review.\n source: <pull.1682.v2.git.git.1709756493673.gitgitgadget@gmail.com>\n\n\n* ps/reftable-stack-tempfile (2024-03-07) 4 commits\n  (merged to 'next' on 2024-03-13 at dcfb0cde8c)\n + reftable/stack: register compacted tables as tempfiles\n + reftable/stack: register lockfiles during compaction\n + reftable/stack: register new tables as tempfiles\n + lockfile: report when rollback fails\n (this branch is used by ps/pack-refs-auto.)\n\n The code in reftable backend that creates new table files works\n better with the tempfile framework to avoid leaving cruft after a\n failure.\n\n Will merge to 'master'.\n source: <cover.1709816483.git.ps@pks.im>\n\n\n* rs/opt-parse-long-fixups (2024-03-03) 6 commits\n  (merged to 'next' on 2024-03-13 at 3755b50794)\n + parse-options: rearrange long_name matching code\n + parse-options: normalize arg and long_name before comparison\n + parse-options: detect ambiguous self-negation\n + parse-options: factor out register_abbrev() and struct parsed_option\n + parse-options: set arg of abbreviated option lazily\n + parse-options: recognize abbreviated negated option with arg\n\n The parse-options code that deals with abbreviated long option\n names have been cleaned up.\n\n Reviewed-by: Josh Steadmon <steadmon@google.com>\n cf. <ZfDM5Or3EKw7Q9SA@google.com>\n\n Will merge to 'master'.\n source: <20240303121944.20627-1-l.s.r@web.de>\n\n\n* cw/git-std-lib (2024-02-28) 4 commits\n - SQUASH??? get rid of apparent debugging crufts\n - test-stdlib: show that git-std-lib is independent\n - git-std-lib: introduce Git Standard Library\n - pager: include stdint.h because uintmax_t is used\n\n Split libgit.a out to a separate git-std-lib tor easier reuse.\n\n Expecting a reroll.\n source: <cover.1696021277.git.jonathantanmy@google.com>\n\n\n* js/cmake-with-test-tool (2024-02-23) 2 commits\n - cmake: let `test-tool` run the unit tests, too\n - Merge branch 'js/unit-test-suite-runner' into js/cmake-with-test-tool\n (this branch uses js/unit-test-suite-runner.)\n\n \"test-tool\" is now built in CMake build to also run the unit tests.\n\n May want to roll it into the base topic.\n source: <pull.1666.git.1708038924522.gitgitgadget@gmail.com>\n\n\n* js/unit-test-suite-runner (2024-02-23) 8 commits\n - ci: use test-tool as unit test runner on Windows\n - t/Makefile: run unit tests alongside shell tests\n - unit tests: add rule for running with test-tool\n - test-tool run-command testsuite: support unit tests\n - test-tool run-command testsuite: remove hardcoded filter\n - test-tool run-command testsuite: get shell from env\n - t0080: turn t-basic unit test into a helper\n - Merge branch 'jk/unit-tests-buildfix' into js/unit-test-suite-runner\n (this branch is used by js/cmake-with-test-tool.)\n\n The \"test-tool\" has been taught to run testsuite tests in parallel,\n bypassing the need to use the \"prove\" tool.\n\n Needs review.\n source: <cover.1708728717.git.steadmon@google.com>\n\n\n* bk/complete-dirname-for-am-and-format-patch (2024-01-12) 1 commit\n - completion: dir-type optargs for am, format-patch\n\n Command line completion support (in contrib/) has been\n updated for a few commands to complete directory names where a\n directory name is expected.\n\n Expecting a reroll.\n cf. <40c3a824-a961-490b-94d4-4eb23c8f713d@gmail.com>\n cf. <6683f24e-7e56-489d-be2d-8afe1fc38d2b@gmail.com>\n source: <d37781c3-6af2-409b-95a8-660a9b92d20b@smtp-relay.sendinblue.com>\n\n\n* bk/complete-send-email (2024-01-12) 1 commit\n - completion: don't complete revs when --no-format-patch\n\n Command line completion support (in contrib/) has been taught to\n avoid offering revision names as candidates to \"git send-email\" when\n the command is used to send pre-generated files.\n\n Expecting a reroll.\n cf. <CAC4O8c88Z3ZqxH2VVaNPpEGB3moL5dJcg3cOWuLWwQ_hLrJMtA@mail.gmail.com>\n source: <a718b5ee-afb0-44bd-a299-3208fac43506@smtp-relay.sendinblue.com>\n\n\n* tb/path-filter-fix (2024-01-31) 16 commits\n - bloom: introduce `deinit_bloom_filters()`\n - commit-graph: reuse existing Bloom filters where possible\n - object.h: fix mis-aligned flag bits table\n - commit-graph: new Bloom filter version that fixes murmur3\n - commit-graph: unconditionally load Bloom filters\n - bloom: prepare to discard incompatible Bloom filters\n - bloom: annotate filters with hash version\n - repo-settings: introduce commitgraph.changedPathsVersion\n - t4216: test changed path filters with high bit paths\n - t/helper/test-read-graph: implement `bloom-filters` mode\n - bloom.h: make `load_bloom_filter_from_graph()` public\n - t/helper/test-read-graph.c: extract `dump_graph_info()`\n - gitformat-commit-graph: describe version 2 of BDAT\n - commit-graph: ensure Bloom filters are read with consistent settings\n - revision.c: consult Bloom filters for root commits\n - t/t4216-log-bloom.sh: harden `test_bloom_filters_not_used()`\n\n The Bloom filter used for path limited history traversal was broken\n on systems whose \"char\" is unsigned; update the implementation and\n bump the format version to 2.\n\n Waiting for a final ack?\n cf. <ZcFjkfbsBfk7JQIH@nand.local>\n source: <cover.1706741516.git.me@ttaylorr.com>\n\n\n* eb/hash-transition (2023-10-02) 30 commits\n  (merged to 'next' on 2024-03-11 at 9cff2e4ab7)\n + t1016-compatObjectFormat: add tests to verify the conversion between objects\n + t1006: test oid compatibility with cat-file\n + t1006: rename sha1 to oid\n + test-lib: compute the compatibility hash so tests may use it\n + builtin/ls-tree: let the oid determine the output algorithm\n + object-file: handle compat objects in check_object_signature\n + tree-walk: init_tree_desc take an oid to get the hash algorithm\n + builtin/cat-file: let the oid determine the output algorithm\n + rev-parse: add an --output-object-format parameter\n + repository: implement extensions.compatObjectFormat\n + object-file: update object_info_extended to reencode objects\n + object-file-convert: convert commits that embed signed tags\n + object-file-convert: convert commit objects when writing\n + object-file-convert: don't leak when converting tag objects\n + object-file-convert: convert tag objects when writing\n + object-file-convert: add a function to convert trees between algorithms\n + object: factor out parse_mode out of fast-import and tree-walk into in object.h\n + cache: add a function to read an OID of a specific algorithm\n + tag: sign both hashes\n + commit: export add_header_signature to support handling signatures on tags\n + commit: convert mergetag before computing the signature of a commit\n + commit: write commits for both hashes\n + object-file: add a compat_oid_in parameter to write_object_file_flags\n + object-file: update the loose object map when writing loose objects\n + loose: compatibilty short name support\n + loose: add a mapping between SHA-1 and SHA-256 for loose objects\n + repository: add a compatibility hash algorithm\n + object-names: support input of oids in any supported hash\n + oid-array: teach oid-array to handle multiple kinds of oids\n + object-file-convert: stubs for converting from one object format to another\n\n Teach a repository to work with both SHA-1 and SHA-256 hash algorithms.\n\n Will cook in 'next'.\n cf. <xmqqv86z5359.fsf@gitster.g>\n source: <878r8l929e.fsf@gmail.froward.int.ebiederm.org>\n\n\n* jc/rerere-cleanup (2023-08-25) 4 commits\n - rerere: modernize use of empty strbuf\n - rerere: try_merge() should use LL_MERGE_ERROR when it means an error\n - rerere: fix comment on handle_file() helper\n - rerere: simplify check_one_conflict() helper function\n\n Code clean-up.\n\n Not ready to be reviewed yet.\n source: <20230824205456.1231371-1-gitster@pobox.com>\n"},{"id":"491017","messageId":"17be81eb83ff314d.70b1dd9aae081c6e.203dcd72f6563036@zivdesk","threadId":"61152","inReplyTo":"xmqqil1iqi37.fsf@gitster.g","subject":"Re: What's cooking in git.git (Mar 2024, #05; Tue, 19)","fromName":"Brian Lyles","fromEmail":"brianmlyles@gmail.com","sentAt":"2024-03-20T15:15:56Z","receivedAt":"2024-03-20T15:15:58Z","isPatch":false,"sender":{"key":"brianmlyles@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1123282?v=4"},"body":"Hi Junio\n\n> * bl/cherry-pick-empty (2024-03-11) 7 commits\n>  - cherry-pick: add `--empty` for more robust redundant commit handling\n>  - cherry-pick: enforce `--keep-redundant-commits` incompatibility\n>  - sequencer: do not require `allow_empty` for redundant commit options\n>  - sequencer: treat error reading HEAD as unborn branch\n>  - rebase: update `--empty=ask` to `--empty=stop`\n>  - docs: clean up `--empty` formatting in git-rebase(1) and git-am (1)\n>  - docs: address inaccurate `--empty` default with `--exec`\n> \n>  \"cherry-pick\" told to keep redundant commits needs to be allowed to\n>  create empty commits to do its job, but it required the user to\n>  give the --allow-empty option, which was unnecessary.  Its UI has\n>  also been tweaked a bit.\n\nNote that the description here is a little out-of-date; we're no longer\nchanging the relationship between --allow-empty and\n--keep-redundant-commits (and the user didn't have to manually supply\n--allow-empty previously). I'd summarize this as:\n\n\tAllow git-cherry-pick(1) to automatically drop redundant commits via\n\ta new `--empty` option, similar to the `--empty` options for\n\tgit-rebase(1) and git-am(1). Includes a soft deprecation of\n\t`--keep-redundant-commits` as well as some related docs changes and\n\tsequencer code cleanup.\n\n>  Comments?\n>  source: <20240119060721.3734775-2-brianmlyles@gmail.com>\n\nYou can expect a v4 reroll tonight to address a few remaining comments.\nThe only thing I haven't heard back on is this change [1] to the docs\nfor the new `--empty` option, but I'm confident enough in my proposed\nalternative there that I'm comfortable rerolling even if I don't hear\nback today.\n\n[1]: https://lore.kernel.org/git/CAHPHrSfiMbU55K2=8+hJZy1cMSRbYM77pCK8BdcAPHLvapHO_A@mail.gmail.com/\n\n-- \nThank you,\nBrian Lyles\n"},{"id":"491019","messageId":"xmqqmsqshoiw.fsf@gitster.g","threadId":"61152","inReplyTo":"17be81eb83ff314d.70b1dd9aae081c6e.203dcd72f6563036@zivdesk","subject":"Re: What's cooking in git.git (Mar 2024, #05; Tue, 19)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-03-20T16:11:03Z","receivedAt":"2024-03-20T16:11:08Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Brian Lyles\" <brianmlyles@gmail.com> writes:\n\n>>  \"cherry-pick\" told to keep redundant commits needs to be allowed to\n>>  create empty commits to do its job, but it required the user to\n>>  give the --allow-empty option, which was unnecessary.  Its UI has\n>>  also been tweaked a bit.\n>\n> Note that the description here is a little out-of-date; we're no longer\n> changing the relationship between --allow-empty and\n> --keep-redundant-commits (and the user didn't have to manually supply\n> --allow-empty previously). I'd summarize this as:\n>\n> \tAllow git-cherry-pick(1) to automatically drop redundant commits via\n> \ta new `--empty` option, similar to the `--empty` options for\n> \tgit-rebase(1) and git-am(1). Includes a soft deprecation of\n> \t`--keep-redundant-commits` as well as some related docs changes and\n> \tsequencer code cleanup.\n\nVery much appreciated.  I wonder if we can have a better workflow to\ndo this, like perhaps contributors write a paragraph in the cover\nletter with the expectation that it will be used in the What's\ncooking report (which will become an entry in the Release Notes when\nthe topic gets included in a release)?\n\n> You can expect a v4 reroll tonight to address a few remaining comments.\n> The only thing I haven't heard back on is this change [1] to the docs\n> for the new `--empty` option, but I'm confident enough in my proposed\n> alternative there that I'm comfortable rerolling even if I don't hear\n> back today.\n>\n> [1]: https://lore.kernel.org/git/CAHPHrSfiMbU55K2=8+hJZy1cMSRbYM77pCK8BdcAPHLvapHO_A@mail.gmail.com/\n\nI added a few folks who were in the review discussion to Cc: of this\nmessage.\n\nThanks.\n"},{"id":"491087","messageId":"17bea28cf691d3eb.70b1dd9aae081c6e.203dcd72f6563036@zivdesk","threadId":"61152","inReplyTo":"xmqqmsqshoiw.fsf@gitster.g","subject":"Re: What's cooking in git.git (Mar 2024, #05; Tue, 19)","fromName":"Brian Lyles","fromEmail":"brianmlyles@gmail.com","sentAt":"2024-03-21T01:13:54Z","receivedAt":"2024-03-21T01:13:57Z","isPatch":false,"sender":{"key":"brianmlyles@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1123282?v=4"},"body":"On Wed, Mar 20, 2024 at 11:11 AM Junio C Hamano <gitster@pobox.com> wrote:\n\n> Very much appreciated.  I wonder if we can have a better workflow to\n> do this, like perhaps contributors write a paragraph in the cover\n> letter with the expectation that it will be used in the What's\n> cooking report (which will become an entry in the Release Notes when\n> the topic gets included in a release)?\n\nI think some more official process could be beneficial. As it is, I'm\nwholly unaware of the current process for creating release notes for\ngit. Do the maintainers simply review merged changes and write release\nnotes as part of cutting a release?\n\nA strategy that I have seen work well is for any commit making a notable\nchange (one that should appear in the release notes) to include an entry\nin a CHANGELOG.NEXT.md file. When cutting a release, the maintainers\nwould move the contents of that CHANGELOG.NEXT.md file into a new\nsection in the standard CHANGELOG.md for the release. This way, the\ncontributor of a series is responsible for creating the changelog entry\n(or entries) rather than the maintainer, which can help avoid\ninaccuracies from a maintainer with less familiarity trying to\nsummarize.\n\nThis has the benefit of anyone being able to easily see notable upcoming\nchanges at any point in a release by simply looking to that\nCHANGELOG.NEXT.md file, rather than needing to review all of the commits\nadded since the previous release.\n\nOf course it does not need to be markdown, that's simply the template\n[1] that I\"m familiar with.\n\n[1]: https://keepachangelog.com/en/1.1.0/\n\nUsing my own series as an example, that CHANGELOG.NEXT.md might look\nlike:\n\n    # Unreleased changelog entries\n    \n    This file contains changelog entries for the next release. Maintainers will move\n    these entries to CHANGELOG.md as part of cutting each release.\n    \n    ## Added\n\t- git-rebase now supports a `--empty=stop` option for consistency with\n\t  git-am's similar `--empty` option.\n\t- git-cherry-pick now supports a `--empty` option to allow more robust\n\t  control over what happens to redundant commits.\n    \n    ## Changed\n\t- git-cherry-pick will now error out if `--keep-redundant-commits`\n\t  is specified alongside `--continue`, `--skip`, `--abort`, or\n\t  `--quit`.\n    \n    ## Deprecated\n\t- git-rebase's `--empty=ask` has been deprecated in favor of\n\t  `--empty=stop`, which has the exact same behavior.\n\t- git-cherry-pick's `--keep-redundant-commits` has been deprecated in\n\t  favor of `--empty=keep`, which has the exact same behavior.\n    \n    ## Removed\n    \n    ## Fixed\n\t- Documentation for git-rebase's `--empty` now correctly indicates\n\t  the default behavior when `--exec` or `--interactive` are\n\t  specified.\n\t- git-cherry-pick will no longer error out if `--allow-empty` is used\n\t  while on an unborn branch.\n    \n    ## Security\n\nWe would of course have to decide how detailed these ought to be and\nwhat changes do and do not warrant an entry, but presumably we already\nhave to do that as part of the current process for creating each\nrelease' notes. So long as we document those expectations, it seems like\na reasonable thing to ask of contributors.\n\nAn additional benefit here is that the release notes themselves are\nreviewed as part of the normal patch review process, allowing reviewers\nto suggest edits to them alongside their code review.\n\nThe one minor headache with this process that I am aware of is that\napplying multiple patches that all touch that one file does lead to some\nconflicts. For example:\n\n    # Added\n\t- Some cool new feature!\n\t<<<<<<< HEAD\n\t- A different cool new feature!\n\t=======\n\t- A third new feature!\n\t>>>>>>> 9b423104cd (Introduce an awesome feature)\n\n    # Changed\n\nIn practice, the rigid structure of adding entries to the end of the\nlist and the blank lines between sections seems to result in these\nusually (always?) being trivially resolved by simply accepting both\nsides of the conflict. That said, in the context in which I've seen\nthis, it's been in a forge where each contributor must address this\nbefore their pull request is accepted. It may cause more annoyance for\nyour process of accepting changes into your tree -- I'm not sure.\n\nThis is simply one idea, of course. I realize that it may not be\nfeasible for this project, but if not then perhaps it may inspire\nsomeone else to come up with a better approach.\n\nWhat are your thoughts?\n\n-- \nThank you,\nBrian Lyles\n"},{"id":"491088","messageId":"xmqqfrwke57g.fsf@gitster.g","threadId":"61152","inReplyTo":"17bea28cf691d3eb.70b1dd9aae081c6e.203dcd72f6563036@zivdesk","subject":"Re: What's cooking in git.git (Mar 2024, #05; Tue, 19)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-03-21T01:36:35Z","receivedAt":"2024-03-21T01:36:43Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Brian Lyles\" <brianmlyles@gmail.com> writes:\n\n> On Wed, Mar 20, 2024 at 11:11 AM Junio C Hamano <gitster@pobox.com> wrote:\n>\n>> Very much appreciated.  I wonder if we can have a better workflow to\n>> do this, like perhaps contributors write a paragraph in the cover\n>> letter with the expectation that it will be used in the What's\n>> cooking report (which will become an entry in the Release Notes when\n>> the topic gets included in a release)?\n>\n> I think some more official process could be beneficial. As it is, I'm\n> wholly unaware of the current process for creating release notes for\n> git. Do the maintainers simply review merged changes and write release\n> notes as part of cutting a release?\n\nA few things.  There is only one maintainer.  There are development\ncommunity members, who act as contributors and as reviewers.  The\nmaintainer manages how the 'master' branch and other integration\nbranches advance, and a part of it is to update the release notes.\n\nDocumentation/howto/maintain-git.txt outlines the workflow the\ncurrent maintainer has adopted, and it has a brief mention on the\n\"What's cooking\" report.  These days, entries in the the release\nnotes for each topic merged are mostly copied from \"What's cooking\"\nbut currently, as the \"howto/maintain-git\" document describes,\nsummarizing and maintaining these topic descriptions is done by the\nmaintainer.\n\nIn the message you responded to, I was wondering if we can\ndistribute the load even further to have original author of each\ntopic write the initial draft of the one-paragraph description of\nthe topic that will go in \"What's cooking\".  Two obvious downsides\nare that having people write about their own work would may make the\nresult harder to read, as they inevitably are biased by the\nimportance of their own work ;-), and having many people write\ndifferent entries may lose the consistent voice across topics being\ndescribed, but the distribution of burden is certainly attractive.\n\n> This way, the\n> contributor of a series is responsible for creating the changelog entry\n> (or entries) rather than the maintainer, which can help avoid\n> inaccuracies from a maintainer with less familiarity trying to\n> summarize.\n\nIt however cuts both ways.\n\nTrying to coming up with a summary from what I can read from the\ndiscussion and the log messages is a good opportunity to find what\nis still unclear in the log messages of the commits in the topic.\nNot all contributors can write a good summary of their own work in a\nway that are suitable for the audience of the release notes.  Also\nyou would want to encourage the maintainer to familiarize with the\ntopics to be able to summarize them, instead of keeping them in the\ndark by doing the release notes entries yourself.\n\n"},{"id":"491090","messageId":"17bea552bb182325.70b1dd9aae081c6e.203dcd72f6563036@zivdesk","threadId":"61152","inReplyTo":"xmqqfrwke57g.fsf@gitster.g","subject":"Re: What's cooking in git.git (Mar 2024, #05; Tue, 19)","fromName":"Brian Lyles","fromEmail":"brianmlyles@gmail.com","sentAt":"2024-03-21T02:04:43Z","receivedAt":"2024-03-21T02:04:45Z","isPatch":false,"sender":{"key":"brianmlyles@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1123282?v=4"},"body":"On Wed, Mar 20, 2024 at 8:36 PM Junio C Hamano <gitster@pobox.com> wrote:\n\n> \"Brian Lyles\" <brianmlyles@gmail.com> writes:\n> \n>> I think some more official process could be beneficial. As it is, I'm\n>> wholly unaware of the current process for creating release notes for\n>> git. Do the maintainers simply review merged changes and write release\n>> notes as part of cutting a release?\n> \n> A few things.  There is only one maintainer.\n\nGot it -- that certainly provides some good context.\n\n> [...] There are development\n> community members, who act as contributors and as reviewers.  The\n> maintainer manages how the 'master' branch and other integration\n> branches advance, and a part of it is to update the release notes.\n\nFrom looking at the history of \"master\", it looks like you take batches\nof merges and update the patch notes as part of merging each batch in.\nAlso good to understand.\n \n> Documentation/howto/maintain-git.txt outlines the workflow the\n> current maintainer has adopted, and it has a brief mention on the\n> \"What's cooking\" report.  These days, entries in the the release\n> notes for each topic merged are mostly copied from \"What's cooking\"\n> but currently, as the \"howto/maintain-git\" document describes,\n> summarizing and maintaining these topic descriptions is done by the\n> maintainer.\n\nSo presumably, a contributor that wanted to see the \"final form\" of the\nrelease notes for their patch would need to keep an eye on \"What's\ncooking\" and/or 'next' and raise any concerns to the list at that point? \n\n> In the message you responded to, I was wondering if we can\n> distribute the load even further to have original author of each\n> topic write the initial draft of the one-paragraph description of\n> the topic that will go in \"What's cooking\".\n\nI definitely think that it makes sense for the original author to write\n*something*.\n\n> [...] Two obvious downsides\n> are that having people write about their own work would may make the\n> result harder to read, as they inevitably are biased by the\n> importance of their own work ;-)\n\nYes, this is certainly a possibility. That said, one big advantage of\nincorporating this as part of the patch submission (one way or another)\nmight be that more people will see and have a chance to review the\nrelease notes as part of their normal review of the patch.\n\n> [...] and having many people write\n> different entries may lose the consistent voice across topics being\n> described, but the distribution of burden is certainly attractive.\n\nIt seems that this is not much different from maintaining a consistent\nvoice across commit messages. Those expectations are well documented,\nand commit messages are reviewed thoroughly as part of patch review. I\nexpect that we could see similar success for the release notes.\n\n>> This way, the\n>> contributor of a series is responsible for creating the changelog entry\n>> (or entries) rather than the maintainer, which can help avoid\n>> inaccuracies from a maintainer with less familiarity trying to\n>> summarize.\n> \n> It however cuts both ways.\n> \n> Trying to coming up with a summary from what I can read from the\n> discussion and the log messages is a good opportunity to find what\n> is still unclear in the log messages of the commits in the topic.\n> Not all contributors can write a good summary of their own work in a\n> way that are suitable for the audience of the release notes.  Also\n> you would want to encourage the maintainer to familiarize with the\n> topics to be able to summarize them, instead of keeping them in the\n> dark by doing the release notes entries yourself.\n\nI do see the benefit here, and if the maintainer wants to continue\naccepting that burden, power to them ;). I certainly would not want\ncontributor-authored release notes to replace the maintainer being\nfamiliar with ongoing changes.\n\nThat said, it would seem that we could have our cake and eat it too --\nthe maintainer may still choose to familiarize themself with the topics\nhowever they wish, and simply validate the release notes instead of\nneeding to write them from scratch. Though perhaps in practice, it is\ndifficult to do so without some additional bias as well.\n\nIn any case, for what it's worth: as a contributor, I would certainly be\nwilling to take on some additional burden as part of submitting a patch\nto ensure that my patch is well represented in the release notes. If it\nhappens to reduce the burden on the maintainer as well, even better!\n\n-- \nThank you,\nBrian Lyles\n"},{"id":"491129","messageId":"xmqq34sjd9h0.fsf@gitster.g","threadId":"61152","inReplyTo":"17bea28cf691d3eb.70b1dd9aae081c6e.203dcd72f6563036@zivdesk","subject":"Re: What's cooking in git.git (Mar 2024, #05; Tue, 19)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-03-21T13:02:03Z","receivedAt":"2024-03-21T13:02:11Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Brian Lyles\" <brianmlyles@gmail.com> writes:\n\n> A strategy that I have seen work well is for any commit making a notable\n> change (one that should appear in the release notes) to include an entry\n> in a CHANGELOG.NEXT.md file.\n\nWhile I very much like the idea of distributing the burden of coming\nup with an initial draft for an entry in the final release notes, I\nam not convinced that the approach to use a single in-tree file\nwould work well in our distributed development style where the\nhistory is merge-heavy with many topics in flight in parallel.\n\nI can imagine how well the approach for each contributor to give\nsuch a draft entry in the cover letter of their topic would work;\nit would be with much less friction compared to a single in-tree\nfile that will be the source of merge conflicts.\n\n\n"},{"id":"491198","messageId":"17bef197ac874ae6.70b1dd9aae081c6e.203dcd72f6563036@zivdesk","threadId":"61152","inReplyTo":"xmqq34sjd9h0.fsf@gitster.g","subject":"Re: What's cooking in git.git (Mar 2024, #05; Tue, 19)","fromName":"Brian Lyles","fromEmail":"brianmlyles@gmail.com","sentAt":"2024-03-22T01:22:22Z","receivedAt":"2024-03-22T01:22:23Z","isPatch":false,"sender":{"key":"brianmlyles@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1123282?v=4"},"body":"Hi Junio\n\nOn Thu, Mar 21, 2024 at 8:02 AM Junio C Hamano <gitster@pobox.com> wrote:\n\n> \"Brian Lyles\" <brianmlyles@gmail.com> writes:\n> \n>> A strategy that I have seen work well is for any commit making a notable\n>> change (one that should appear in the release notes) to include an entry\n>> in a CHANGELOG.NEXT.md file.\n> \n> While I very much like the idea of distributing the burden of coming\n> up with an initial draft for an entry in the final release notes, I\n> am not convinced that the approach to use a single in-tree file\n> would work well in our distributed development style where the\n> history is merge-heavy with many topics in flight in parallel.\n> \n> I can imagine how well the approach for each contributor to give\n> such a draft entry in the cover letter of their topic would work;\n> it would be with much less friction compared to a single in-tree\n> file that will be the source of merge conflicts.\n\nYes, I suspect you are right. I think the cover letter would be a good\nstart at the very least. Would you welcome a patch to\n'Documentation/SubmittingPatches' that adds a new expectation for this,\nor do you think this would be best handled yourself? I am interested in\ncontributing but, as I'm sure you've noticed, I'm also quite new to the\nproject =)\n\n-- \nThank you,\nBrian Lyles\n"},{"id":"491202","messageId":"xmqqcyrn58mf.fsf@gitster.g","threadId":"61152","inReplyTo":"17bef197ac874ae6.70b1dd9aae081c6e.203dcd72f6563036@zivdesk","subject":"Re: What's cooking in git.git (Mar 2024, #05; Tue, 19)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-03-22T01:59:52Z","receivedAt":"2024-03-22T01:59:56Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Brian Lyles\" <brianmlyles@gmail.com> writes:\n\n> Yes, I suspect you are right. I think the cover letter would be a good\n> start at the very least. Would you welcome a patch to\n> 'Documentation/SubmittingPatches' that adds a new expectation for this,\n> or do you think this would be best handled yourself? I am interested in\n> contributing but, as I'm sure you've noticed, I'm also quite new to the\n> project =)\n\nI'd prefer to start with a much less official \"experimental\" launch\nof such a new workflow, instead of adding an unproven idea as if it\nis a new hard requirement to the SubmittingPatches document.  If it\nworks well, we can write it down later.\n\nBut even a soft launch needs some way to advertise it to the target\naudience, and the SubmittingPatches document is the only sensible\nplace to do so.  So, perhaps do something like this?  I dunno.\n\n------- >8 ------------- >8 ------------- >8 -------\nSubject: SubmittingPatches: release-notes entry experiment\n\nIt has been the maintainer's task to prepare the description of each\ntopic listed in the \"What's cooking\" report.  The description is\nautomatically picked up from the \"What's cooking\" report and used in\nthe commit log message of the merge commit when the topic is merged\ninto integration branches.  These commit log messges of the merge\ncommits are then propagated to the release notes.\n\nThe original author of a topic may be in the best position to write\nthe initial description of a topic, but we so far lacked a formal\nchannel for the author to tell what description to use.  The usual\nprocedure has been to see the topic described in \"What's cooking\"\nreport, and then either complain about inaccurate explanation and/or\noffer a rewrite.\n\nLet's try an experiment to optionally let the author propose the one\nparagraph description when the topic is submitted.  Pick the cover\nletter as the logical place to do so, and describe an experimental\nworkflow in the SubmittingPatches document.\n\nSigned-off-by: Junio C Hamano <gitster@pobox.com>\n---\n [for what's cooking]\n * An experimental procedure for a topic author to propose the topic\n   description to be used in \"What's cooking\" report and in the\n   release notes have been added to the SubmittingPatches document.\n\n Documentation/SubmittingPatches | 11 +++++++++++\n 1 file changed, 11 insertions(+)\n\ndiff --git i/Documentation/SubmittingPatches w/Documentation/SubmittingPatches\nindex e734a3f0f1..05e15b9436 100644\n--- i/Documentation/SubmittingPatches\n+++ w/Documentation/SubmittingPatches\n@@ -459,6 +459,17 @@ an explanation of changes between each iteration can be kept in\n Git-notes and inserted automatically following the three-dash\n line via `git format-patch --notes`.\n \n+[[a-paragraph-summary]]\n+\n+*This is EXPERIMENTAL*.  When sending a topic, you can propose one\n+paragraph summary that appears in the \"What's cooking\" report when it\n+is picked up to explain the topic.  If you choose to do so, please\n+write 2-5 lines of a paragraph that will fit well in our release notes\n+(see Documentation/RelNotes/* directory for examples), and put it in\n+the cover letter, clearly marked as such.  For a single-patch series,\n+use the space between the three-dash line and the diffstat, as\n+described earlier.\n+\n [[attachment]]\n Do not attach the patch as a MIME attachment, compressed or not.\n Do not let your e-mail client send quoted-printable.  Do not let\n"},{"id":"491215","messageId":"17bef643ca4eabab.70b1dd9aae081c6e.203dcd72f6563036@zivdesk","threadId":"61152","inReplyTo":"xmqqcyrn58mf.fsf@gitster.g","subject":"Re: What's cooking in git.git (Mar 2024, #05; Tue, 19)","fromName":"Brian Lyles","fromEmail":"brianmlyles@gmail.com","sentAt":"2024-03-22T02:47:59Z","receivedAt":"2024-03-22T02:48:00Z","isPatch":false,"sender":{"key":"brianmlyles@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1123282?v=4"},"body":"Hi Junio\n\nOn Thu, Mar 21, 2024 at 8:59 PM Junio C Hamano <gitster@pobox.com> wrote:\n\n> \"Brian Lyles\" <brianmlyles@gmail.com> writes:\n> \n>> Yes, I suspect you are right. I think the cover letter would be a good\n>> start at the very least. Would you welcome a patch to\n>> 'Documentation/SubmittingPatches' that adds a new expectation for this,\n>> or do you think this would be best handled yourself? I am interested in\n>> contributing but, as I'm sure you've noticed, I'm also quite new to the\n>> project =)\n> \n> I'd prefer to start with a much less official \"experimental\" launch\n> of such a new workflow, instead of adding an unproven idea as if it\n> is a new hard requirement to the SubmittingPatches document.  If it\n> works well, we can write it down later.\n> \n> But even a soft launch needs some way to advertise it to the target\n> audience, and the SubmittingPatches document is the only sensible\n> place to do so.  So, perhaps do something like this?  I dunno.\n\nI would agree that it would be hard to advertise without some change\nthere. I think that documenting an optional opportunity for now before\nconsidering if it should be a requirement later makes sense.\n\n> ------- >8 ------------- >8 ------------- >8 -------\n> Subject: SubmittingPatches: release-notes entry experiment\n> \n> It has been the maintainer's task to prepare the description of each\n> topic listed in the \"What's cooking\" report.  The description is\n> automatically picked up from the \"What's cooking\" report and used in\n> the commit log message of the merge commit when the topic is merged\n> into integration branches.  These commit log messges of the merge\n> commits are then propagated to the release notes.\n> \n> The original author of a topic may be in the best position to write\n> the initial description of a topic, but we so far lacked a formal\n> channel for the author to tell what description to use.  The usual\n> procedure has been to see the topic described in \"What's cooking\"\n> report, and then either complain about inaccurate explanation and/or\n> offer a rewrite.\n> \n> Let's try an experiment to optionally let the author propose the one\n> paragraph description when the topic is submitted.  Pick the cover\n> letter as the logical place to do so, and describe an experimental\n> workflow in the SubmittingPatches document.\n> \n> Signed-off-by: Junio C Hamano <gitster@pobox.com>\n> ---\n>  [for what's cooking]\n>  * An experimental procedure for a topic author to propose the topic\n>    description to be used in \"What's cooking\" report and in the\n>    release notes have been added to the SubmittingPatches document.\n> \n>  Documentation/SubmittingPatches | 11 +++++++++++\n>  1 file changed, 11 insertions(+)\n> \n> diff --git i/Documentation/SubmittingPatches w/Documentation/SubmittingPatches\n> index e734a3f0f1..05e15b9436 100644\n> --- i/Documentation/SubmittingPatches\n> +++ w/Documentation/SubmittingPatches\n> @@ -459,6 +459,17 @@ an explanation of changes between each iteration can be kept in\n>  Git-notes and inserted automatically following the three-dash\n>  line via `git format-patch --notes`.\n>  \n> +[[a-paragraph-summary]]\n> +\n> +*This is EXPERIMENTAL*.  When sending a topic, you can propose one\n> +paragraph summary that appears in the \"What's cooking\" report when it\n> +is picked up to explain the topic.  If you choose to do so, please\n> +write 2-5 lines of a paragraph that will fit well in our release notes\n> +(see Documentation/RelNotes/* directory for examples), and put it in\n> +the cover letter, clearly marked as such.  For a single-patch series,\n> +use the space between the three-dash line and the diffstat, as\n> +described earlier.\n\nWould it be beneficial to request some specific heading, phrase, or\nother structured text such that this summary is obvious, or even easily\nextracted with some sort of script? Or is that perhaps overkill for now?\nI could see relying on any sort of automatic extraction being unreliable\neven with such a recommendation so perhaps it's not worth pursuing for\nthat reason, but I could imagine it may be useful to have a standardized\nway to separate this release notes/what's cooking summary from the rest\nof the cover letter (which also acts as a summary of the series).\n\nBut in general, I think this looks like a good proposal. Thanks!\n\n> +\n>  [[attachment]]\n>  Do not attach the patch as a MIME attachment, compressed or not.\n>  Do not let your e-mail client send quoted-printable.  Do not let\n\n-- \nThank you,\nBrian Lyles\n"},{"id":"491217","messageId":"18052bdadfc3dd54aaaff5aa68063702@manjaro.org","threadId":"61152","inReplyTo":"xmqqcyrn58mf.fsf@gitster.g","subject":"Re: What's cooking in git.git (Mar 2024, #05; Tue, 19)","fromName":"Dragan Simic","fromEmail":"dsimic@manjaro.org","sentAt":"2024-03-22T05:05:29Z","receivedAt":"2024-03-22T05:05:31Z","isPatch":false,"sender":{"key":"dsimic@manjaro.org","avatar":null},"body":"On 2024-03-22 02:59, Junio C Hamano wrote:\n> +[[a-paragraph-summary]]\n> +\n> +*This is EXPERIMENTAL*.  When sending a topic, you can propose one\n> +paragraph summary that appears in the \"What's cooking\" report when it\n> +is picked up to explain the topic.  If you choose to do so, please\n> +write 2-5 lines of a paragraph that will fit well in our release notes\n> +(see Documentation/RelNotes/* directory for examples), and put it in\n> +the cover letter, clearly marked as such.  For a single-patch series,\n> +use the space between the three-dash line and the diffstat, as\n> +described earlier.\n\nLooking good to me.\n"},{"id":"491218","messageId":"c62a14c7de6ff487b1f66f149d685126@manjaro.org","threadId":"61152","inReplyTo":"17bef643ca4eabab.70b1dd9aae081c6e.203dcd72f6563036@zivdesk","subject":"Re: What's cooking in git.git (Mar 2024, #05; Tue, 19)","fromName":"Dragan Simic","fromEmail":"dsimic@manjaro.org","sentAt":"2024-03-22T05:14:37Z","receivedAt":"2024-03-22T05:14:39Z","isPatch":false,"sender":{"key":"dsimic@manjaro.org","avatar":null},"body":"On 2024-03-22 03:47, Brian Lyles wrote:\n> I would agree that it would be hard to advertise without some change\n> there. I think that documenting an optional opportunity for now before\n> considering if it should be a requirement later makes sense.\n\nIMHO, making it a strict requirement would only raise the bar for\ncontributors even higher, and increase the \"do this, do that\" kind\nof traffic on the mailing list.  In other words, I think it's the\nbest to start slowly and see how many new patches will include the\nadditional summary.\n\n> Would it be beneficial to request some specific heading, phrase, or\n> other structured text such that this summary is obvious, or even easily\n> extracted with some sort of script? Or is that perhaps overkill for \n> now?\n> I could see relying on any sort of automatic extraction being \n> unreliable\n> even with such a recommendation so perhaps it's not worth pursuing for\n> that reason, but I could imagine it may be useful to have a \n> standardized\n> way to separate this release notes/what's cooking summary from the rest\n> of the cover letter (which also acts as a summary of the series).\n\nOf course, it would be nice to have a strict format in place, to\nallow automated parsing and extraction, but I'm not sure how many\npatches would actually adhere to that requirement.\n"},{"id":"491241","messageId":"Zf18DEHen_K_HWvo@framework","threadId":"61152","inReplyTo":"c62a14c7de6ff487b1f66f149d685126@manjaro.org","subject":"Re: What's cooking in git.git (Mar 2024, #05; Tue, 19)","fromName":"Max Gautier","fromEmail":"mg@max.gautier.name","sentAt":"2024-03-22T12:39:40Z","receivedAt":"2024-03-22T12:39:47Z","isPatch":false,"sender":{"key":"mg@max.gautier.name","avatar":"https://avatars.githubusercontent.com/u/13346812?v=4"},"body":"On Fri, Mar 22, 2024 at 06:14:37AM +0100, Dragan Simic wrote:\n> On 2024-03-22 03:47, Brian Lyles wrote:\n> > I would agree that it would be hard to advertise without some change\n> > there. I think that documenting an optional opportunity for now before\n> > considering if it should be a requirement later makes sense.\n> \n> IMHO, making it a strict requirement would only raise the bar for\n> contributors even higher, and increase the \"do this, do that\" kind\n> of traffic on the mailing list.  In other words, I think it's the\n> best to start slowly and see how many new patches will include the\n> additional summary.\n> \n> > Would it be beneficial to request some specific heading, phrase, or\n> > other structured text such that this summary is obvious, or even easily\n> > extracted with some sort of script? Or is that perhaps overkill for now?\n> > I could see relying on any sort of automatic extraction being unreliable\n> > even with such a recommendation so perhaps it's not worth pursuing for\n> > that reason, but I could imagine it may be useful to have a standardized\n> > way to separate this release notes/what's cooking summary from the rest\n> > of the cover letter (which also acts as a summary of the series).\n> \n> Of course, it would be nice to have a strict format in place, to\n> allow automated parsing and extraction, but I'm not sure how many\n> patches would actually adhere to that requirement.\n\nWhile not every patch would use the format, proposing one might be a good\nidea nevertheless, because \"clearly marked as such\" is not necessarily\nclear for everyone. At least that way if you don't have any idea you can\nuse the format.\nFor instance (inspired from the k8s project):\n\n```RELNOTE\nYour release note here\n```\n\n-- \nMax Gautier\n"},{"id":"491243","messageId":"6a9d06f622f4c2dc9d00e54e454adeda@manjaro.org","threadId":"61152","inReplyTo":"Zf18DEHen_K_HWvo@framework","subject":"Re: What's cooking in git.git (Mar 2024, #05; Tue, 19)","fromName":"Dragan Simic","fromEmail":"dsimic@manjaro.org","sentAt":"2024-03-22T13:25:42Z","receivedAt":"2024-03-22T13:25:45Z","isPatch":false,"sender":{"key":"dsimic@manjaro.org","avatar":null},"body":"On 2024-03-22 13:39, Max Gautier wrote:\n> On Fri, Mar 22, 2024 at 06:14:37AM +0100, Dragan Simic wrote:\n>> On 2024-03-22 03:47, Brian Lyles wrote:\n>> > I would agree that it would be hard to advertise without some change\n>> > there. I think that documenting an optional opportunity for now before\n>> > considering if it should be a requirement later makes sense.\n>> \n>> IMHO, making it a strict requirement would only raise the bar for\n>> contributors even higher, and increase the \"do this, do that\" kind\n>> of traffic on the mailing list.  In other words, I think it's the\n>> best to start slowly and see how many new patches will include the\n>> additional summary.\n>> \n>> > Would it be beneficial to request some specific heading, phrase, or\n>> > other structured text such that this summary is obvious, or even easily\n>> > extracted with some sort of script? Or is that perhaps overkill for now?\n>> > I could see relying on any sort of automatic extraction being unreliable\n>> > even with such a recommendation so perhaps it's not worth pursuing for\n>> > that reason, but I could imagine it may be useful to have a standardized\n>> > way to separate this release notes/what's cooking summary from the rest\n>> > of the cover letter (which also acts as a summary of the series).\n>> \n>> Of course, it would be nice to have a strict format in place, to\n>> allow automated parsing and extraction, but I'm not sure how many\n>> patches would actually adhere to that requirement.\n> \n> While not every patch would use the format, proposing one might be a \n> good\n> idea nevertheless, because \"clearly marked as such\" is not necessarily\n> clear for everyone. At least that way if you don't have any idea you \n> can\n> use the format.\n> For instance (inspired from the k8s project):\n> \n> ```RELNOTE\n> Your release note here\n> ```\n\nMakes sense, providing some kind of example as part of this addition\nto the documentation would be beneficial.\n"},{"id":"491245","messageId":"xmqqfrwi495d.fsf@gitster.g","threadId":"61152","inReplyTo":"17bef643ca4eabab.70b1dd9aae081c6e.203dcd72f6563036@zivdesk","subject":"Re: What's cooking in git.git (Mar 2024, #05; Tue, 19)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-03-22T14:46:06Z","receivedAt":"2024-03-22T14:46:09Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Brian Lyles\" <brianmlyles@gmail.com> writes:\n\n>> \n>> Signed-off-by: Junio C Hamano <gitster@pobox.com>\n>> ---\n>>  [for what's cooking]\n>>  * An experimental procedure for a topic author to propose the topic\n>>    description to be used in \"What's cooking\" report and in the\n>>    release notes have been added to the SubmittingPatches document.\n>> \n>>  Documentation/SubmittingPatches | 11 +++++++++++\n>>  1 file changed, 11 insertions(+)\n>> \n>> diff --git i/Documentation/SubmittingPatches w/Documentation/SubmittingPatches\n>> index e734a3f0f1..05e15b9436 100644\n>> --- i/Documentation/SubmittingPatches\n>> +++ w/Documentation/SubmittingPatches\n>> @@ -459,6 +459,17 @@ an explanation of changes between each iteration can be kept in\n>>  Git-notes and inserted automatically following the three-dash\n>>  line via `git format-patch --notes`.\n>>  \n>> +[[a-paragraph-summary]]\n>> +\n>> +*This is EXPERIMENTAL*.  When sending a topic, you can propose one\n>> +paragraph summary that appears in the \"What's cooking\" report when it\n>> +is picked up to explain the topic.  If you choose to do so, please\n>> +write 2-5 lines of a paragraph that will fit well in our release notes\n>> +(see Documentation/RelNotes/* directory for examples), and put it in\n>> +the cover letter, clearly marked as such.  For a single-patch series,\n>> +use the space between the three-dash line and the diffstat, as\n>> +described earlier.\n>\n> Would it be beneficial to request some specific heading, phrase, or\n> other structured text such that this summary is obvious, or even easily\n> extracted with some sort of script? Or is that perhaps overkill for now?\n\nWe do not even know if it is a good idea, so let's start with a\nlightweight process that does not burden participants with too much\nred tape.  For a series with a cover letter, the rule might end up\nto be as simple as \"When the first paragraph of the message looks\nlike an entry in the Release Notes, it is used as such\".  The \" a\nparagraph that is 2-5 lines long, indented by three SPs, whose first\nline has SP-asterisk-SP instead\" may be a distinct enough style that\nit may not require any further marking.\n"}]}