* What's cooking in git.git (Mar 2024, #05; Tue, 19)
@ 2024-03-19 16:53 Junio C Hamano
2024-03-20 15:15 ` Brian Lyles
0 siblings, 1 reply; 15+ messages in thread
From: Junio C Hamano @ 2024-03-19 16:53 UTC (permalink / raw)
To: git
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>
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: What's cooking in git.git (Mar 2024, #05; Tue, 19)
2024-03-19 16:53 What's cooking in git.git (Mar 2024, #05; Tue, 19) Junio C Hamano
@ 2024-03-20 15:15 ` Brian Lyles
2024-03-20 16:11 ` Junio C Hamano
0 siblings, 1 reply; 15+ messages in thread
From: Brian Lyles @ 2024-03-20 15:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Hi Junio
> * 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.
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.
> Comments?
> source: <20240119060721.3734775-2-brianmlyles@gmail.com>
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/
--
Thank you,
Brian Lyles
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: What's cooking in git.git (Mar 2024, #05; Tue, 19)
2024-03-20 15:15 ` Brian Lyles
@ 2024-03-20 16:11 ` Junio C Hamano
2024-03-21 1:13 ` Brian Lyles
0 siblings, 1 reply; 15+ messages in thread
From: Junio C Hamano @ 2024-03-20 16:11 UTC (permalink / raw)
To: Brian Lyles; +Cc: git, phillip.wood123, Jean-Noël AVILA
"Brian Lyles" <brianmlyles@gmail.com> writes:
>> "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.
>
> 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.
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)?
> 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/
I added a few folks who were in the review discussion to Cc: of this
message.
Thanks.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: What's cooking in git.git (Mar 2024, #05; Tue, 19)
2024-03-20 16:11 ` Junio C Hamano
@ 2024-03-21 1:13 ` Brian Lyles
2024-03-21 1:36 ` Junio C Hamano
2024-03-21 13:02 ` Junio C Hamano
0 siblings, 2 replies; 15+ messages in thread
From: Brian Lyles @ 2024-03-21 1:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, phillip.wood123, Jean-Noël AVILA
On Wed, Mar 20, 2024 at 11:11 AM Junio C Hamano <gitster@pobox.com> wrote:
> 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 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?
--
Thank you,
Brian Lyles
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: What's cooking in git.git (Mar 2024, #05; Tue, 19)
2024-03-21 1:13 ` Brian Lyles
@ 2024-03-21 1:36 ` Junio C Hamano
2024-03-21 2:04 ` Brian Lyles
2024-03-21 13:02 ` Junio C Hamano
1 sibling, 1 reply; 15+ messages in thread
From: Junio C Hamano @ 2024-03-21 1:36 UTC (permalink / raw)
To: Brian Lyles; +Cc: git, phillip.wood123, Jean-Noël AVILA
"Brian Lyles" <brianmlyles@gmail.com> writes:
> On Wed, Mar 20, 2024 at 11:11 AM Junio C Hamano <gitster@pobox.com> wrote:
>
>> 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 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 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.
> 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.
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.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: What's cooking in git.git (Mar 2024, #05; Tue, 19)
2024-03-21 1:36 ` Junio C Hamano
@ 2024-03-21 2:04 ` Brian Lyles
0 siblings, 0 replies; 15+ messages in thread
From: Brian Lyles @ 2024-03-21 2:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, phillip.wood123, Jean-Noël AVILA
On Wed, Mar 20, 2024 at 8:36 PM Junio C Hamano <gitster@pobox.com> wrote:
> "Brian Lyles" <brianmlyles@gmail.com> writes:
>
>> 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 few things. There is only one maintainer.
Got it -- that certainly provides some good context.
> [...] 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.
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.
> 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.
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?
> 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".
I definitely think that it makes sense for the original author to write
*something*.
> [...] 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 ;-)
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.
> [...] 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 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.
>> 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.
>
> 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.
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!
--
Thank you,
Brian Lyles
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: What's cooking in git.git (Mar 2024, #05; Tue, 19)
2024-03-21 1:13 ` Brian Lyles
2024-03-21 1:36 ` Junio C Hamano
@ 2024-03-21 13:02 ` Junio C Hamano
2024-03-22 1:22 ` Brian Lyles
1 sibling, 1 reply; 15+ messages in thread
From: Junio C Hamano @ 2024-03-21 13:02 UTC (permalink / raw)
To: Brian Lyles; +Cc: git, phillip.wood123, Jean-Noël AVILA
"Brian Lyles" <brianmlyles@gmail.com> writes:
> 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.
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.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: What's cooking in git.git (Mar 2024, #05; Tue, 19)
2024-03-21 13:02 ` Junio C Hamano
@ 2024-03-22 1:22 ` Brian Lyles
2024-03-22 1:59 ` Junio C Hamano
0 siblings, 1 reply; 15+ messages in thread
From: Brian Lyles @ 2024-03-22 1:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, phillip.wood123, Jean-Noël AVILA
Hi Junio
On Thu, Mar 21, 2024 at 8:02 AM Junio C Hamano <gitster@pobox.com> wrote:
> "Brian Lyles" <brianmlyles@gmail.com> writes:
>
>> 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.
>
> 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.
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 =)
--
Thank you,
Brian Lyles
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: What's cooking in git.git (Mar 2024, #05; Tue, 19)
2024-03-22 1:22 ` Brian Lyles
@ 2024-03-22 1:59 ` Junio C Hamano
2024-03-22 2:47 ` Brian Lyles
2024-03-22 5:05 ` Dragan Simic
0 siblings, 2 replies; 15+ messages in thread
From: Junio C Hamano @ 2024-03-22 1:59 UTC (permalink / raw)
To: Brian Lyles; +Cc: git, phillip.wood123, Jean-Noël AVILA
"Brian Lyles" <brianmlyles@gmail.com> writes:
> 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 =)
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(+)
diff --git i/Documentation/SubmittingPatches w/Documentation/SubmittingPatches
index e734a3f0f1..05e15b9436 100644
--- i/Documentation/SubmittingPatches
+++ w/Documentation/SubmittingPatches
@@ -459,6 +459,17 @@ an explanation of changes between each iteration can be kept in
Git-notes and inserted automatically following the three-dash
line via `git format-patch --notes`.
+[[a-paragraph-summary]]
+
+*This is EXPERIMENTAL*. When sending a topic, you can propose one
+paragraph summary that appears in the "What's cooking" report when it
+is picked up to explain the topic. If you choose to do so, please
+write 2-5 lines of a paragraph that will fit well in our release notes
+(see Documentation/RelNotes/* directory for examples), and put it in
+the cover letter, clearly marked as such. For a single-patch series,
+use the space between the three-dash line and the diffstat, as
+described earlier.
+
[[attachment]]
Do not attach the patch as a MIME attachment, compressed or not.
Do not let your e-mail client send quoted-printable. Do not let
^ permalink raw reply related [flat|nested] 15+ messages in thread
* Re: What's cooking in git.git (Mar 2024, #05; Tue, 19)
2024-03-22 1:59 ` Junio C Hamano
@ 2024-03-22 2:47 ` Brian Lyles
2024-03-22 5:14 ` Dragan Simic
2024-03-22 14:46 ` Junio C Hamano
2024-03-22 5:05 ` Dragan Simic
1 sibling, 2 replies; 15+ messages in thread
From: Brian Lyles @ 2024-03-22 2:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, phillip.wood123, Jean-Noël AVILA
Hi Junio
On Thu, Mar 21, 2024 at 8:59 PM Junio C Hamano <gitster@pobox.com> wrote:
> "Brian Lyles" <brianmlyles@gmail.com> writes:
>
>> 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 =)
>
> 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.
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.
> ------- >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(+)
>
> diff --git i/Documentation/SubmittingPatches w/Documentation/SubmittingPatches
> index e734a3f0f1..05e15b9436 100644
> --- i/Documentation/SubmittingPatches
> +++ w/Documentation/SubmittingPatches
> @@ -459,6 +459,17 @@ an explanation of changes between each iteration can be kept in
> Git-notes and inserted automatically following the three-dash
> line via `git format-patch --notes`.
>
> +[[a-paragraph-summary]]
> +
> +*This is EXPERIMENTAL*. When sending a topic, you can propose one
> +paragraph summary that appears in the "What's cooking" report when it
> +is picked up to explain the topic. If you choose to do so, please
> +write 2-5 lines of a paragraph that will fit well in our release notes
> +(see Documentation/RelNotes/* directory for examples), and put it in
> +the cover letter, clearly marked as such. For a single-patch series,
> +use the space between the three-dash line and the diffstat, as
> +described earlier.
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!
> +
> [[attachment]]
> Do not attach the patch as a MIME attachment, compressed or not.
> Do not let your e-mail client send quoted-printable. Do not let
--
Thank you,
Brian Lyles
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: What's cooking in git.git (Mar 2024, #05; Tue, 19)
2024-03-22 1:59 ` Junio C Hamano
2024-03-22 2:47 ` Brian Lyles
@ 2024-03-22 5:05 ` Dragan Simic
1 sibling, 0 replies; 15+ messages in thread
From: Dragan Simic @ 2024-03-22 5:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Brian Lyles, git, phillip.wood123, Jean-Noël AVILA
On 2024-03-22 02:59, Junio C Hamano wrote:
> +[[a-paragraph-summary]]
> +
> +*This is EXPERIMENTAL*. When sending a topic, you can propose one
> +paragraph summary that appears in the "What's cooking" report when it
> +is picked up to explain the topic. If you choose to do so, please
> +write 2-5 lines of a paragraph that will fit well in our release notes
> +(see Documentation/RelNotes/* directory for examples), and put it in
> +the cover letter, clearly marked as such. For a single-patch series,
> +use the space between the three-dash line and the diffstat, as
> +described earlier.
Looking good to me.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: What's cooking in git.git (Mar 2024, #05; Tue, 19)
2024-03-22 2:47 ` Brian Lyles
@ 2024-03-22 5:14 ` Dragan Simic
2024-03-22 12:39 ` Max Gautier
2024-03-22 14:46 ` Junio C Hamano
1 sibling, 1 reply; 15+ messages in thread
From: Dragan Simic @ 2024-03-22 5:14 UTC (permalink / raw)
To: Brian Lyles; +Cc: Junio C Hamano, git, phillip.wood123, Jean-Noël AVILA
On 2024-03-22 03:47, Brian Lyles 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.
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.
> 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).
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.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: What's cooking in git.git (Mar 2024, #05; Tue, 19)
2024-03-22 5:14 ` Dragan Simic
@ 2024-03-22 12:39 ` Max Gautier
2024-03-22 13:25 ` Dragan Simic
0 siblings, 1 reply; 15+ messages in thread
From: Max Gautier @ 2024-03-22 12:39 UTC (permalink / raw)
To: Dragan Simic
Cc: Brian Lyles, Junio C Hamano, git, phillip.wood123,
Jean-Noël AVILA
On Fri, Mar 22, 2024 at 06:14:37AM +0100, Dragan Simic wrote:
> On 2024-03-22 03:47, Brian Lyles 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.
>
> 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.
>
> > 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).
>
> 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.
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
```
--
Max Gautier
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: What's cooking in git.git (Mar 2024, #05; Tue, 19)
2024-03-22 12:39 ` Max Gautier
@ 2024-03-22 13:25 ` Dragan Simic
0 siblings, 0 replies; 15+ messages in thread
From: Dragan Simic @ 2024-03-22 13:25 UTC (permalink / raw)
To: Max Gautier
Cc: Brian Lyles, Junio C Hamano, git, phillip.wood123,
Jean-Noël AVILA
On 2024-03-22 13:39, Max Gautier wrote:
> On Fri, Mar 22, 2024 at 06:14:37AM +0100, Dragan Simic wrote:
>> On 2024-03-22 03:47, Brian Lyles 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.
>>
>> 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.
>>
>> > 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).
>>
>> 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.
>
> 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
> ```
Makes sense, providing some kind of example as part of this addition
to the documentation would be beneficial.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: What's cooking in git.git (Mar 2024, #05; Tue, 19)
2024-03-22 2:47 ` Brian Lyles
2024-03-22 5:14 ` Dragan Simic
@ 2024-03-22 14:46 ` Junio C Hamano
1 sibling, 0 replies; 15+ messages in thread
From: Junio C Hamano @ 2024-03-22 14:46 UTC (permalink / raw)
To: Brian Lyles; +Cc: git, phillip.wood123, Jean-Noël AVILA
"Brian Lyles" <brianmlyles@gmail.com> writes:
>>
>> 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(+)
>>
>> diff --git i/Documentation/SubmittingPatches w/Documentation/SubmittingPatches
>> index e734a3f0f1..05e15b9436 100644
>> --- i/Documentation/SubmittingPatches
>> +++ w/Documentation/SubmittingPatches
>> @@ -459,6 +459,17 @@ an explanation of changes between each iteration can be kept in
>> Git-notes and inserted automatically following the three-dash
>> line via `git format-patch --notes`.
>>
>> +[[a-paragraph-summary]]
>> +
>> +*This is EXPERIMENTAL*. When sending a topic, you can propose one
>> +paragraph summary that appears in the "What's cooking" report when it
>> +is picked up to explain the topic. If you choose to do so, please
>> +write 2-5 lines of a paragraph that will fit well in our release notes
>> +(see Documentation/RelNotes/* directory for examples), and put it in
>> +the cover letter, clearly marked as such. For a single-patch series,
>> +use the space between the three-dash line and the diffstat, as
>> +described earlier.
>
> 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?
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.
^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2024-03-22 14:46 UTC | newest]
Thread overview: 15+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-03-19 16:53 What's cooking in git.git (Mar 2024, #05; Tue, 19) Junio C Hamano
2024-03-20 15:15 ` Brian Lyles
2024-03-20 16:11 ` Junio C Hamano
2024-03-21 1:13 ` Brian Lyles
2024-03-21 1:36 ` Junio C Hamano
2024-03-21 2:04 ` Brian Lyles
2024-03-21 13:02 ` Junio C Hamano
2024-03-22 1:22 ` Brian Lyles
2024-03-22 1:59 ` Junio C Hamano
2024-03-22 2:47 ` Brian Lyles
2024-03-22 5:14 ` Dragan Simic
2024-03-22 12:39 ` Max Gautier
2024-03-22 13:25 ` Dragan Simic
2024-03-22 14:46 ` Junio C Hamano
2024-03-22 5:05 ` Dragan Simic
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).