{"thread":{"id":"66071","subject":"What's cooking in git.git (Jul 2026, #12)","startedAt":"2026-07-27T03:09:15Z","lastAt":"2026-08-05T17:03:20Z","messageCount":17,"participants":["Junio C Hamano","Phillip Wood","Harald Nordgren","Matt Hunter"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"549062","messageId":"xmqqfr15ruw7.fsf@gitster.g","threadId":"66071","inReplyTo":null,"subject":"What's cooking in git.git (Jul 2026, #12)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2026-07-27T03:09:12Z","receivedAt":"2026-07-27T03:09:15Z","isPatch":false,"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 is a candidate to be in a\nfuture release). Commits prefixed with '-' are only in 'seen', and\naren't considered \"accepted\" at all. They may be annotated with a URL\nto a message that raises issues but they are by no means exhaustive.\nA topic without enough support may be discarded after a long period\nof no activity (of course, it can be resubmitted when new interest\narises).\n\nThe seventh batch of topics have now graduated to the 'master' branch.\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-scm/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[New Topics]\n\n* jc/remote-insteadof-leakfix (2026-07-25) 1 commit\n - remote: plug memory leaks\n\n rewrites_release() in 'remote.c' has been updated to free 'struct\n rewrite' instances and their '.instead_of' arrays, and their contents.\n\n Will merge to 'next'.\n cf. <20260725161819.GA2343104@coredump.intra.peff.net>\n source: \n\n\n* tb/pack-with-duplicates (2026-07-24) 5 commits\n - pack-bitmap: handle duplicate pack entries during MIDX reuse\n - test-tool bitmap: reject packs with duplicate objects\n - midx: verify duplicate pack entries by OID and offset\n - packfile: recover delta cycles through duplicate entries\n - t5308: test reverse indexes with duplicate objects\n\n The handling of packfiles with duplicate object entries has been\n hardened. Specifically, reverse index lookup, delta cycle\n recovery, multi-pack-index verification, and pack reuse paths have\n been updated to correctly handle or gracefully reject duplicate\n entries.\n\n Needs review.\n cf. \n source: \n\n\n* ps/cat-file-remote-object-info-type (2026-07-25) 6 commits\n - cat-file: unify default format\n - serve: advertise type capability\n - fetch-object-info: request all supported options dynamically\n - fetch-object-info: parse type from server response\n - protocol-caps: add type support to object-info\n - Merge branch 'ps/cat-file-remote-object-info' into ps/cat-file-remote-object-info-type\n (this branch uses ps/cat-file-remote-object-info.)\n\n The 'remote-object-info' command for 'git cat-file --batch-command'\n has been extended to support the '%(objecttype)' placeholder.\n\n Needs review.\n source: <20260725-objecttype-support-v1-0-2d4ca3bbabf1@gmail.com>\n\n\n* rs/branch-delete-bisect-warning (2026-07-25) 1 commit\n - branch: report active bisect run when rejecting delete\n\n 'git branch -d' learned to report when a branch cannot be deleted\n because it is being used in an active bisect run.\n\n Will merge to 'next'?\n cf. \n source: <590382fb-731b-4e14-911e-ff68356d1082@web.de>\n\n\n* jk/ci-static-analysis-image-bump (2026-07-26) 2 commits\n - ci: bump ubuntu image version for static-analysis job\n - bloom: silence CHECK_ASSERTION_SIDE_EFFECTS false positive\n\n The image version used by the static-analysis CI job has been bumped\n to ubuntu-latest (Ubuntu 24.04), which brings in a newer Coccinelle\n version that resolves a severe performance regression. A false\n positive warning from the CHECK_ASSERTION_SIDE_EFFECTS build with\n GCC 15 in the Bloom filter code has also been silenced to facilitate\n the image upgrade.\n\n Will merge to 'next'?\n cf. \n source: <20260726083254.GA3528497@coredump.intra.peff.net>\n\n\n* jk/diff-relative-cached-unmerged-more (2026-07-26) 3 commits\n - diff-lib: skip paths outside prefix in oneway_diff()\n - diff-lib: drop stale comment about advancing o->pos\n - Merge branch 'jk/diff-relative-cached-unmerged' into jk/diff-relative-cached-unmerged-more\n (this branch uses jk/diff-relative-cached-unmerged.)\n\n The code path that deals with relative paths in the diff-lib has\n been cleaned up.\n\n Will merge to 'next'?\n cf. \n source: <20260726084550.GC2366012@coredump.intra.peff.net>\n\n--------------------------------------------------\n[Stalled]\n\n* tb/repack-geometric-cruft (2026-06-28) 11 commits\n - SQUASH??? bare grep !???\n - repack: support combining '--geometric' with '--cruft'\n - pack-objects: support '--refs-snapshot' with 'follow-reachable'\n - pack-objects: introduce '--stdin-packs=follow-reachable'\n - pack-objects: extract `stdin_packs_add_all_pack_entries()`\n - repack-geometry: drop unused redundant-pack removal\n - repack: delete geometric packs via existing_packs\n - repack: teach MIDX retention about geometric rollups\n - repack: mark geometric progression of packs as retained\n - repack: extract `locate_existing_pack()` helper\n - repack: unconditionally exclude non-kept packs\n\n 'git repack' has been taught to accept '--geometric' and '--cruft'\n together. When both are given, non-cruft packs are rolled up by the\n geometric repack as usual, while a separate cruft pack is written to\n collect unreachable objects.\n\n Waiting for response for too long, stalled.\n cf. \n cf. \n source: \n\n\n* hn/checkout-track-fetch (2026-06-24) 2 commits\n - checkout: extend --track with a \"fetch\" mode to refresh start-point\n - branch: expose helpers for finding the remote owning a tracking ref\n\n The 'git checkout --track=...' command has been taught to optionally\n fetch the branch from the remote that the new branch will work with.\n\n Will be discarded.\n cf. \n cf. \n cf. \n source: \n\n\n* za/completion-hide-dotfiles (2026-06-20) 2 commits\n - completion: hide dotfiles by default for path completion\n - completion: hide dotfiles for selected path completion\n\n Path completion for commands like 'git rm' and 'git mv' has been\n updated to hide dotfiles by default unless the user explicitly starts\n the path with a dot, matching standard shell-completion behavior.\n\n Waiting for response, stalled.\n cf. \n cf. \n source: \n\n\n* kh/doc-trailers (2026-06-10) 10 commits\n - doc: interpret-trailers: document comment line treatment\n - doc: interpret-trailers: commit to “trailer block” term\n - doc: interpret-trailers: join new-trailers again\n - doc: interpret-trailers: add key format example\n - doc: interpret-trailers: explain key format\n - doc: interpret-trailers: explain the format after the intro\n - doc: interpret-trailers: not just for commit messages\n - doc: interpret-trailers: use “metadata” in Name as well\n - doc: interpret-trailers: replace “lines” with “metadata”\n - doc: interpret-trailers: stop fixating on RFC 822\n\n Documentation for 'git interpret-trailers' has been updated to explain\n the format of trailer keys (alphanumeric characters and hyphens),\n replace outdated terminology, define key terms upfront, and document\n how comment lines in the input are treated.\n\n Expecting a reroll for too long, stalled.\n cf. <729baf6b-53ea-4e8d-95ab-5935667e66c2@app.fastmail.com>\n source: \n\n\n* kh/doc-replay-config (2026-06-05) 4 commits\n - doc: replay: move “default” to the right-hand side\n - doc: replay: use a nested description list\n - doc: replay: improve config description\n - doc: link to config for git-replay(1)\n\n Documentation for 'git replay' has been updated to refer to its\n configuration variables.\n\n Waiting for response for too long, stalled.\n cf. <87cxwxofgv.fsf@emacs.iotcl.com>\n cf. \n source: \n\n--------------------------------------------------\n[Cooking]\n\n* af/clone-revision-v0-segfault-fix (2026-07-24) 1 commit\n - builtin/clone: fix segfault when using --revision with protocol v0\n\n 'git clone --revision' talking to a server that does not support\n protocol v2 (falling back to protocol v0) segfaulted, which has\n been corrected.\n\n Will merge to 'next'.\n cf. \n source: <20260724124138.666877-1-adrian.friedli@mt.com>\n\n\n* lo/mv-missing-dest-dir-check (2026-07-26) 2 commits\n - mv: reject a destination whose leading path is missing or a symlink\n - mv: name both source and destination when rename fails\n\n 'git mv' has been updated to check for a missing destination\n leading directory during the checking phase, allowing 'git mv -n'\n to report the failure. The error message when the rename(2)\n syscall fails has also been improved to name both the source and\n the destination.\n\n Needs review.\n source: \n\n\n* ps/odb-make-creation-pluggable (2026-07-23) 5 commits\n - odb: make creation of on-disk structures pluggable\n - odb/source: introduce function to map source type to name\n - setup: defer object database creation\n - setup: detangle loading of loose object maps\n - loose: load loose object map for the correct source\n\n The creation of the on-disk data structures for the object database\n has been made pluggable, allowing future backends to customize their\n setup. As part of this, the initialization of the object database\n has been deferred, and the loading of the loose-object map has been\n detangled from repository initialization.\n\n Waiting for response.\n cf. \n cf. \n cf. \n cf. \n cf. \n source: <20260724-pks-odb-create-on-disk-v1-0-3b3d265d979b@pks.im>\n\n\n* jt/config-lock-timeout (2026-05-17) 1 commit\n (merged to 'next' on 2026-07-24 at 3cb8da6b6a)\n + config: retry acquiring config.lock, configurable via core.configLockTimeout\n\n Configuration file locking has been updated to retry for a short\n period, avoiding failures when multiple processes attempt to update\n the configuration simultaneously.\n\n Will merge to 'master'.\n cf. \n cf. \n source: <20260517132111.1014901-1-joerg@thalheim.io>\n\n\n* hs/rebase-continue-edit (2026-07-21) 1 commit\n - rebase: add --[no-]edit to --continue\n\n Support for skipping the editor when continuing a rebase after\n conflict resolution has been added with the '--no-edit' option, and\n forcing it with '--edit'. A new configuration variable\n 'rebase.noEdit' can be used to set the default behavior.\n\n Waiting for a response.\n cf. \n cf. \n source: <20260721140443.1809379-2-hugo@hsal.es>\n\n\n* tn/stash-avoid-sparse-index-expansion (2026-07-20) 2 commits\n (merged to 'next' on 2026-07-23 at 8ccf28493e)\n + stash: avoid sparse-index expansion for in-cone paths\n + pathspec: use match for sparse-index expansion checks\n\n The 'git stash push' command has been optimized to avoid unnecessary\n sparse index expansion when pathspecs are wholly inside the\n sparse-checkout cone. Also, a potential out-of-bounds read in the\n sparse-index expansion check helper pathspec_needs_expanded_index()\n has been fixed by consistently using the parsed, prefixed path.\n\n Will merge to 'master'.\n cf. \n cf. \n source: <20260720223118.62821-4-tnyman@openai.com>\n\n\n* en/submodule-insteadof-remote-match (2026-07-22) 1 commit\n - submodule: resolve insteadOf aliases when matching remote\n\n The remote-matching logic for submodules has been corrected to\n resolve 'url.*.insteadOf' aliases before comparing the inventoried\n URL from '.gitmodules' with the URLs of configured remotes.\n\n Will merge to 'next'.\n cf. \n source: <20260723002132.3989727-1-ccjmne@gmail.com>\n\n\n* td/fsmonitor-darwin-cookie-flush (2026-07-21) 1 commit\n - fsmonitor: flush pending FSEvents before cookie wait\n\n The 'fsmonitor' daemon on macOS has been updated to flush pending\n FSEvents before waiting for the cookie file, to avoid premature\n timeouts on busy systems.\n\n Waiting for response.\n cf. \n cf. \n source: <20260721-fsmonitor-darwin-cookie-flush-v1-1-357dc5e32040@gmail.com>\n\n\n* jc/exclude-first-parent-seen (2026-07-22) 1 commit\n (merged to 'next' on 2026-07-25 at 85755d1d45)\n + revision: honor --exclude-first-parent-only with SEEN first parent\n\n Traversals with '--exclude-first-parent-only' have been corrected to\n properly stop after the first parent even when it has already been\n marked as SEEN.\n\n Will merge to 'master'.\n source: \n\n\n* sn/rebase-update-refs-symrefs (2026-07-22) 2 commits\n - rebase: guard non-branch symref targets\n - rebase: skip branch symref aliases\n\n 'git rebase --update-refs' has been taught to resolve local branch\n symrefs to their referents before queuing updates, ensuring aliases of\n the current branch are skipped and duplicate updates are avoided to\n prevent failures when branch aliases are present.\n\n Waiting for response.\n cf. <5bece313-6ffb-450b-add1-29652b64de10@gmail.com>\n cf. <00e529b6-7ae7-463f-a4b3-0991e9411aba@gmail.com>\n cf. \n cf. \n source: \n\n\n* bc/rust-hash-cleanups (2026-07-18) 2 commits\n (merged to 'next' on 2026-07-21 at 51627468a0)\n + rust: discard hash context when finished\n + hash: initialize context before cloning\n\n A few memory problems in the Rust interface to C hash functions have\n been corrected. The 'Clone' implementation of 'CryptoHasher' now\n properly initializes the context before cloning, and its 'Drop'\n implementation now discards the context to prevent leaks.\n\n Will merge to 'master'.\n cf. <20260719080754.GA429688@coredump.intra.peff.net>\n source: <20260719010842.17991-1-sandals@crustytoothpaste.net>\n\n\n* ja/doc-synopsis-style-yet-more (2026-07-23) 4 commits\n - doc: convert git-request-pull synopsis and options to new style\n - doc: convert git-send-email synopsis and options to new style\n - doc: convert git-format-patch synopsis and options to new style\n - doc: convert git-imap-send synopsis and options to new style\n\n Synopsis and options in the documentation for 'git format-patch',\n 'git imap-send', 'git send-email', and 'git request-pull' have been\n updated to the modern style.\n\n Needs review.\n source: \n\n\n* hn/url-push-tracking (2026-07-22) 2 commits\n (merged to 'next' on 2026-07-25 at 9b776656fc)\n + remote: find tracking branches for URL push destinations\n + remote: pass repository to push tracking helper\n\n When the push remote is specified as a URL, the fetch refspec of a\n uniquely matching configured remote is now used to find and update\n the remote-tracking branch (e.g., '@{push}').\n\n Will merge to 'master'.\n cf. \n source: \n\n\n* tl/gitweb-shorten-hashes-with-modes (2026-07-17) 1 commit\n (merged to 'next' on 2026-07-25 at 5b92e8a325)\n + gitweb: shorten index hashes with trailing file modes\n\n The object ID shortening and linking in the 'commitdiff' view of\n 'gitweb' has been corrected to work even when the index line carries\n a trailing file mode.\n\n Will merge to 'master'.\n cf. \n source: \n\n\n* kj/repo-info-more-path-keys (2026-07-26) 7 commits\n - repo: add path.git-prefix path key\n - repo: add path.grafts with absolute and relative suffix formatting\n - repo: add path.index with absolute and relative suffix formatting\n - repo: add path.hooks with absolute and relative suffix formatting\n - repo: add path.objects with absolute and relative suffix formatting\n - repo: add path.superproject-working-tree with absolute and relative suffixes\n - repo: add path.toplevel with absolute and relative suffix formatting\n\n The 'git repo info' command has been taught more keys to output\n paths of various repository components (such as the working tree\n root, superproject working tree, object database, etc.), supporting\n both absolute and relative path formats.\n\n Needs review.\n source: <20260726104343.16933-1-jayatheerthkulkarni2005@gmail.com>\n\n\n* sk/userdiff-swift (2026-07-20) 1 commit\n (merged to 'next' on 2026-07-23 at 45dbcc6307)\n + userdiff: add support for Swift\n\n Userdiff patterns for Swift have been added, with support for\n Swift-specific constructs such as attributes, modifiers, failable\n initializers, and generics.\n\n Will merge to 'master'.\n cf. <2a3a73c5-5e90-44a3-bf6a-6e98ce5e5a59@kdbg.org>\n cf. <7b541cd5-bd66-4675-818d-8e23eb1c9530@kdbg.org>\n source: <20260721065736.8747-1-diy2903@gmail.com>\n\n\n* ps/odb-move-loose-object-writing (2026-07-17) 10 commits\n (merged to 'next' on 2026-07-25 at 244d577d93)\n + object-file: move logic to write loose objects\n + object-file: move `force_object_loose()`\n + object-file: force objects loose via generic interface\n + object-file: fix memory leak in `force_object_loose()`\n + odb: support setting mtime when writing objects\n + odb: lift object existence check out of the \"loose\" backend\n + odb: compute object hash in `odb_write_object_ext()`\n + t/u-odb-inmemory: implement wrapper for writing objects\n + odb: compute compat object ID in `odb_write_object_ext()`\n + Merge branch 'jt/receive-pack-use-odb-transactions' into HEAD\n\n The logic to write loose objects has been refactored and moved from\n 'object-file.c' to the loose backend source file 'odb/source-loose.c',\n making the loose backend more self-contained. This is achieved by\n first refactoring force_object_loose() to use generic ODB write\n interfaces instead of loose-backend internals.\n\n Will merge to 'master'.\n cf. \n source: <20260717-pks-odb-move-loose-object-writing-v1-0-46446a3cb5b7@pks.im>\n\n\n* pw/rebase-fixup-fixes (2026-07-26) 2 commits\n - rebase: remember fixup -c after skipping fixup/squash\n - rebase -i: fix counting of fixups after rebase --skip\n\n Two bugs in how 'git rebase' handles skipped 'fixup' and 'squash'\n commands have been fixed. One bug caused an incorrect commit count to\n be shown in the template message when multiple commands were skipped,\n and another prevented the editor from opening when the final command\n in a chain containing 'fixup -c' was skipped.\n\n Will merge to 'next'?\n cf. \n source: \n\n\n* tc/last-modified-bloom (2026-07-17) 4 commits\n - last-modified: keep per-path Bloom filters for wildcard pathspecs\n - last-modified: check pathspec against Bloom filter first\n - revision: expose check for paths maybe changed in Bloom filter\n - revision: move bloom keyvec precondition into function\n\n The 'git last-modified' command has been optimized by using Bloom\n filters. It now reuses revision walk filtering logic from 'git log'\n to pre-filter commits, and maintains per-path Bloom filters even when\n wildcard pathspecs are used.\n\n Waiting for a response.\n cf. <20260720094218.GA681989@coredump.intra.peff.net>\n cf. \n source: <20260717-toon-speed-up-last-modified-v1-0-410418f18614@iotcl.com>\n\n\n* hn/bisect-reset-when-found (2026-07-20) 2 commits\n (merged to 'next' on 2026-07-22 at 1dc394ad9b)\n + bisect: add --reset-when-found to leave when done\n + bisect: let bisect_reset() optionally check out quietly\n\n The 'git bisect' command has been taught a\n '--reset-when-found[=]' option that tells the command to\n automatically run 'git bisect reset' to jump back to the original\n state or to the found culprit.\n\n Will merge to 'master'.\n cf. \n source: \n\n\n* js/coverity-unchecked-returns-fix (2026-07-14) 11 commits\n - bisect: handle dup() failure when redirecting stdout\n - bisect: check get_terms return at all call sites\n - bisect: check strbuf_getline_lf return when reading terms\n - transport-helper: warn when export-marks file cannot be finalized\n - transport-helper: check dup() return in get_exporter\n - compat/pread: check initial lseek for errors\n - last-modified: handle repo_parse_commit() failures\n - reftable tests: check reftable_table_init_ref_iterator() return\n - reftable/block: check deflateInit() return value\n - config: propagate launch_editor() failure in show_editor()\n - http: die on curl_easy_duphandle failure in get_active_slot\n\n A handful of code paths have been corrected to check return values\n from functions like curl_easy_duphandle(), deflateInit(), lseek(),\n dup(), and strbuf_getline_lf(), resolving several Coverity warnings\n about unchecked returns.\n\n Waiting for response.\n cf. \n cf. \n cf. \n cf. \n cf. \n cf. \n source: \n\n\n* jk/diff-relative-cached-unmerged (2026-07-14) 1 commit\n (merged to 'next' on 2026-07-25 at 8829f9b348)\n + diff: ignore unmerged paths outside prefix with --relative --cached\n (this branch is used by jk/diff-relative-cached-unmerged-more.)\n\n 'git diff --relative' running with '--cached' has been corrected to\n avoid a segfault when encountering unmerged paths outside the\n prefix.\n\n Will merge to 'master'.\n cf. \n source: <20260715060523.GA517940@coredump.intra.peff.net>\n\n\n* jc/submodule-helper-avoid-zu (2026-07-15) 1 commit\n (merged to 'next' on 2026-07-19 at b12d5d76f5)\n + submodule--helper: avoid use of %zu for now\n\n An accidental use of the '%zu' format specifier in 'git\n submodule--helper' has been corrected to use 'PRIuMAX' and cast the\n value to 'uintmax_t' to avoid portability issues.\n\n Will merge to 'master'.\n source: \n\n\n* ds/trace2-tolerate-failed-timestamp (2026-07-15) 1 commit\n - trace2: tolerate failed timestamp formatting\n\n The 'trace2' telemetry library has been updated to tolerate failures\n from system calls like gettimeofday() and datetime formatting\n functions, replacing potential program crashes with blank placeholder\n timestamps in the traces.\n\n Waiting for response.\n cf. \n cf. \n cf. \n cf. \n source: \n\n\n* mm/revision-pure-get-commit-action (2026-07-15) 1 commit\n - revision: make get_commit_action() a pure predicate\n\n The get_commit_action() function has been refactored to be a pure\n predicate by moving the side-effecting line-level log range folding to\n simplify_commit(). This ensures that evaluating a commit's action\n before the walk reaches it does not prematurely mutate its tracked\n line ranges, making it safer for potential lookahead evaluations.\n\n Waiting for review.\n cf. \n cf. \n source: \n\n\n* rs/remote-curl-simplify-push-specs (2026-07-14) 1 commit\n (merged to 'next' on 2026-07-19 at ff1b5528ba)\n + remote-curl: simplify passing of push specs\n\n The passing of push destination specifications in the 'remote-curl'\n helper has been simplified by removing the explicit 'count' parameter\n and relying on the NULL-termination of the array.\n\n Will merge to 'master'.\n source: <935883f3-3be4-4c51-9711-5208b9ef9ca1@web.de>\n\n\n* cc/fast-import-usage (2026-07-16) 7 commits\n - fast-import: use struct option for usage string\n - fast-import: move command state globals into 'struct fast_import_state'\n - fast-import: introduce 'struct fast_import_state'\n - fast-import: localize 'i' into the 'for' loops using it\n - api-parse-options.adoc: document hidden and OPT_*_F option macros\n - api-parse-options.adoc: document per-option flags\n - parse-options: introduce OPT_HIDDEN_GROUP\n\n The usage string of 'git fast-import' has been updated to use the\n parse_options() API for displaying help, and its SYNOPSIS in the\n documentation has been standardized to match.\n\n Waiting for response.\n cf. \n cf. \n source: <20260716165517.433849-1-christian.couder@gmail.com>\n\n\n* ps/copy-wo-the-repository (2026-07-16) 1 commit\n (merged to 'next' on 2026-07-20 at 9e38da0efc)\n + copy: drop dependency on `the_repository`\n\n The copy_file() and copy_file_with_time() functions have been\n refactored to take a repository parameter, allowing the removal of the\n implicit dependency on the global 'the_repository' variable in\n 'copy.c'.\n\n Will merge to 'master'.\n cf. \n cf. \n source: <20260716-pks-copy-wo-the-repository-v2-1-8f5e32942929@pks.im>\n\n\n* ps/refspec-wo-the-repository (2026-07-16) 3 commits\n (merged to 'next' on 2026-07-20 at 31044c3fc9)\n + refspec: stop depending on `the_repository`\n + refspec: let callers pass in hash algorithm when parsing items\n + refspec: group related structures and functions\n\n The dependency on the global 'the_repository' variable in the\n 'refspec.c' API has been removed by passing the hash algorithm\n explicitly to refspec-parsing functions and storing it in 'struct\n refspec'.\n\n Will merge to 'master'.\n source: <20260716-pks-refspec-wo-the-repository-v1-0-aa40844d067f@pks.im>\n\n\n* ps/writev (2026-07-16) 5 commits\n - fast-import: use writev(3p) to send cat-blob responses\n - sideband: use writev(3p) to send pktlines\n - wrapper: properly handle MAX_IO_SIZE in writev(3p)\n - wrapper: introduce writev(3p) wrappers\n - compat/posix: introduce writev(3p) wrapper\n\n A compatibility wrapper for writev(3p) has been reintroduced,\n including fixes for CMake build and 'MAX_IO_SIZE' limits on NonStop.\n Calls to write(3p) in send_sideband() and cat_blob() have been\n refactored to use writev(3p) wrappers to reduce syscall overhead.\n\n Waiting for response.\n cf. \n cf. \n cf. \n source: <20260716-pks-reintroduce-writev-v1-0-ea9038c884bc@pks.im>\n\n\n* sc/wt-status-avoid-quadratic-insertion (2026-07-18) 1 commit\n (merged to 'next' on 2026-07-20 at 9330d42a4a)\n + wt-status: avoid repeated insertion for untracked paths\n\n The enumeration of untracked and ignored files in 'git status' has\n been optimized by avoiding quadratic complexity when inserting into\n string lists, reducing the construction cost from O(n^2) to O(n log\n n).\n\n Will merge to 'master'.\n cf. <20260718083828.GE22588@coredump.intra.peff.net>\n source: <20260718081449.26747-1-sahityajb@gmail.com>\n\n\n* tb/send-pack-no-ref-delta (2026-07-12) 4 commits\n - send-pack: honor `no-ref-delta` capability\n - pack-objects: support reuse with `--no-ref-delta`\n - pack-objects: introduce `--no-ref-delta`\n - t/helper: teach pack-deltas to list delta entries\n\n 'git send-pack' has been taught to refrain from sending 'REF_DELTA'\n encoded packfiles when the other side asks it to.\n\n Needs review.\n source: \n\n\n* tn/packfile-uri-concurrency (2026-07-25) 3 commits\n - fetch-pack: accept \"pack\" output for packfile URIs\n - http: avoid concurrent appends to partial packs\n - http-fetch: correct --index-pack-arg documentation\n\n Concurrent downloads of packfiles via packfile URIs and dumb HTTP have\n been made safer by avoiding concurrent appends to the staging file.\n Opening the file in read-write mode and maintaining separate file\n offsets prevents corruption while preserving resumability. The\n 'fetch-pack' command has also been updated to tolerate pre-existing\n '.keep' files.\n\n Expecting a reroll.\n cf. <20260726092027.GA3529827@coredump.intra.peff.net>\n cf. <20260726102712.GA3535709@coredump.intra.peff.net>\n cf. <20260726100421.12648-1-tnyman@openai.com>\n source: \n\n\n* rs/tempfile-wo-the-repository (2026-07-14) 5 commits\n (merged to 'next' on 2026-07-22 at 968a116891)\n + use repo_hold_lock_file_for_update{,_mode,_timeout}() with custom repos\n + tempfile: stop using the_repository\n + lockfile: add repo_hold_lock_file_for_update{,_timeout}{,_mode}()\n + refs/packed: use repo_create_tempfile()\n + tempfile: add repo_create_tempfile{,_mode}()\n\n The tempfile and lockfile APIs have been refactored to stop depending\n on the 'the_repository' global variable, and their callers have been\n updated to use the repository-aware variants.\n\n Will merge to 'master'.\n cf. \n cf. \n source: <20260714175956.54601-1-l.s.r@web.de>\n\n\n* js/pack-objects-delta-size-t (2026-07-09) 12 commits\n - git-zlib: widen `git_deflate_bound()` to `size_t`\n - t/helper/test-pack-deltas: widen `do_compress()`'s maxsize local to `size_t`\n - http-push: widen `start_put()`'s size local from `ssize_t` to `size_t`\n - diff: widen `deflate_it()`'s bound local from int to `size_t`\n - archive-zip: widen `zlib_deflate_raw()`'s maxsize local to `size_t`\n - packfile, git-zlib: widen `use_pack()` and zstream avail fields to `size_t`\n - delta: widen `create_delta()` and `diff_delta()` to `size_t`\n - pack-objects: widen `mem_usage` and `try_delta()`'s out-param to `size_t`\n - pack-objects: widen `free_unpacked()` return to `size_t`\n - pack-objects: widen delta-cache accounting to `size_t`\n - delta: widen `create_delta_index()` parameter to `size_t`\n - diff-delta: widen `struct delta_index`' size fields to `size_t`\n\n The 'pack-objects' and delta-encoding code paths have been updated to\n use 'size_t' instead of 'unsigned long' for object sizes and offset\n limits, avoiding potential truncation issues on 64-bit Windows.\n\n Needs review.\n source: \n\n\n* pz/fetch-submodule-errors-config (2026-07-16) 2 commits\n - fetch: add fetch.submoduleErrors to make submodule fetch errors non-fatal\n - submodule: fix premature failure in recursive submodule fetch\n\n The 'git fetch' command has been updated to allow configuring how\n submodule fetch errors are handled. A new configuration variable\n 'fetch.submoduleErrors' and a corresponding '--submodule-errors'\n command-line option have been introduced, allowing users to make\n submodule fetch errors non-fatal (warn instead of fail).\n Additionally, a premature failure during recursive submodule fetches\n has been fixed by deferring the error until the OID-based retry phase\n also fails.\n\n Needs review.\n source: <20260716140956.1023740-1-paulius.zaleckas@gmail.com>\n\n\n* gr/add-e-use-apply-api (2026-07-10) 1 commit\n - builtin/add.c: replace run_command() with direct apply_all_patches() call\n\n The application of the edited patch in 'git add -e' has been\n refactored to use the internal apply API directly, avoiding the need\n to spawn a 'git apply' subprocess.\n\n Needs review.\n cf. \n source: <20260711061246.58079-1-gatlavishweshwarreddy26@gmail.com>\n\n\n* fz/rebase-autosquash-empty (2026-07-11) 1 commit\n . sequencer: honor --empty when a fixup!/squash! empties its target\n\n A commit that is emptied by melding a 'fixup!' or 'squash!' commit\n during 'git rebase --autosquash' is now handled according to the\n '--empty' option, allowing it to be dropped, kept, or to halt the\n rebase.\n\n Ejected due to conflicts with 'pw/rebase-drop-notes-with-commit'.\n\n Waiting for response.\n cf. <690b965e-5f07-4aa4-a64c-96e60a86d73b@gmail.com>\n cf. \n cf. \n source: <20260711-fz-autosquash-empty-v3-1-d227b63eb511@gmail.com>\n\n\n* mm/lib-httpd-cgi-safe (2026-07-10) 3 commits\n - t/README: document writing concurrency-safe helpers\n - t/lib-httpd: make http-429 first-request check atomic\n - t/lib-httpd: fix apply-one-time-script race under concurrent requests\n\n CGI helper scripts used by HTTP-related test scripts have been updated\n to use atomic filesystem operations, preventing race conditions when\n Apache handles concurrent requests.\n\n Needs review.\n source: \n\n\n* ps/odb-pluggable-housekeeping (2026-07-12) 12 commits\n - odb: make optimizations pluggable\n - builtin/gc: fix signedness issues in ODB-related functionality\n - builtin/gc: refactor ODB optimizations to operate on \"files\" source\n - builtin/gc: introduce `odb_optimize_required()`\n - builtin/gc: move geometric repacking into `odb_optimize()`\n - builtin/gc: introduce object database optimization options\n - builtin/gc: inline config values specific to the \"files\" backend\n - builtin/gc: make repack arguments self-contained\n - builtin/gc: extract object database optimizations into separate function\n - builtin/gc: move worktree and rerere tasks before object optimizations\n - odb: run \"pre-auto-gc\" hook for all maintenance tasks\n - t7900: simplify how we check for maintenance tasks\n\n Object database housekeeping in 'git gc' and 'git maintenance' has\n been refactored to be pluggable. The files-backend-specific logic,\n including incremental and geometric repacking as well as object\n pruning, has been moved out of the command implementation and into the\n files object database source, enabling future alternative object\n database backends to implement their own housekeeping services.\n\n Waiting for response.\n cf. \n cf. \n cf. \n cf. \n source: <20260713-b4-pks-odb-optimize-v2-0-9c2c3ee94b38@pks.im>\n\n\n* ps/refs-wo-the-repository (2026-07-15) 7 commits\n (merged to 'next' on 2026-07-19 at 12685f410c)\n + refs: remove remaining uses of `the_repository`\n + worktree: pass repository to public functions\n + worktree: pass repository to file-local functions\n + worktree: refactor code to use available repositories\n + refs/files: drop `USE_THE_REPOSITORY_VARIABLE`\n + refs/packed: de-globalize handling of \"core.packedRefsTimeout\"\n + Merge branch 'ps/refs-writing-subcommands' into ps/refs-wo-the-repository\n\n The ref subsystem and the worktree API have been refactored to pass a\n repository pointer down the call chain, allowing them to drop\n references to the global 'the_repository' variable. As part of this,\n the handling of the 'core.packedRefsTimeout' configuration has been\n moved into the per-repository ref store structure.\n\n Will merge to 'master'.\n source: <20260716-pks-refs-wo-the-repository-v3-0-db0a804e0224@pks.im>\n\n\n* ds/sparse-index-ita-crash (2026-07-06) 1 commit\n - sparse-index: avoid crash on intent-to-add entry outside the cone\n\n A crash in the 'sparse-index' collapse code when encountering an\n invalidated cache-tree node (due to an intent-to-add path) has been\n fixed by avoiding collapsing such subtrees.\n\n Needs review.\n source: \n\n\n* ij/subtree-reject-v2-config (2026-07-06) 2 commits\n - git-subtree: Bail out if we find output from Rust rewrite (test)\n - git-subtree: Bail out if we find output from Rust rewrite\n\n The shell script implementation of 'git subtree' has been updated to\n check for the presence of the configuration file of the new Rust\n implementation, preventing users from accidentally running the old\n script on repositories already managed by the new tool.\n\n Expecting a reroll.\n cf. <27219.20156.438730.881821@chiark.greenend.org.uk>\n source: <20260706115816.20267-1-ijackson@chiark.greenend.org.uk>\n\n\n* jm/t0213-skip-emulated-ancestry-tests (2026-07-06) 1 commit\n - t0213: skip ancestry tests under user-mode emulation\n\n The 'TRACE2_ANCESTRY' prerequisite in the 't0213' test script has been\n refined to avoid failures under user-mode emulation by verifying that\n the ancestry collector reports the expected process names rather than\n the emulator binary name.\n\n Needs review.\n cf. \n source: \n\n\n* zy/apply-abandoned-header-fix (2026-07-01) 1 commit\n - apply: avoid leaking abandoned git-header state\n\n A candidate 'git diff' header parsed by 'git apply' has been isolated\n in a temporary structure, preventing any partially parsed state from\n polluting the main patch structure and causing assertions to trip if\n the header is ultimately rejected.\n\n Needs review.\n source: <20260702041759.51572-1-zhihao.yao@njit.edu>\n\n\n* bl/t7412-use-test-path-helpers (2026-06-29) 1 commit\n - submodule absorbgitdirs tests: use test_* helper functions\n\n The test script 't7412' that tests 'git submodule absorbgitdirs' has\n been modernized to use test_path_is_file(), test_path_is_dir(), and\n test_path_is_missing() helper functions instead of raw 'test -[fde]'\n commands.\n\n Waiting for response, stalled.\n cf. \n cf. \n source: <20260630020220.1559190-1-bblima@usp.br>\n\n\n* pw/rebase-drop-notes-with-commit (2026-07-15) 9 commits\n (merged to 'next' on 2026-07-20 at 5475c9f935)\n + sequencer: do not record dropped commits as rewritten\n + sequencer: use an enum to represent result of picking a commit\n + sequencer: simplify pick_one_commit()\n + sequencer: remove unnecessary condition in pick_one_commit()\n + sequencer: simplify handling of fixup with conflicts\n + sequencer: remove unnecessary \"or\" in pick_one_commit()\n + sequencer: never reschedule on failed commit\n + sequencer: be more careful with external merge\n + t3400: restore coverage for note copying with apply backend\n\n The rebase post-rewrite notes-copying logic has been corrected. When\n a commit is dropped during rebase (e.g., because its changes are\n already upstream), it is no longer recorded as rewritten, preventing\n its notes from being copied to an unrelated commit.\n\n Will merge to 'master'.\n cf. \n source: \n\n\n* ty/migrate-excludes-file (2026-07-13) 10 commits\n (merged to 'next' on 2026-07-23 at 749560a29c)\n + repository: adjust the comment of config_values_private_\n + environment: move object_creation_mode into repo_config_values\n + environment: move autorebase into repo_config_values\n + environment: move push_default into repo_config_values\n + environment: migrate apply_default_whitespace and apply_default_ignorewhitespace\n + environment: move askpass_program into repo_config_values\n + environment: move pager_program into repo_config_values\n + environment: move editor_program into repo_config_values\n + environment: move excludes_file into repo_config_values\n + repository: introduce repo_config_values_clear()\n\n The 'excludes_file' and various other global configuration variables\n (including 'editor_program', 'pager_program', 'askpass_program', and\n 'push_default') have been migrated into the per-repository structure.\n\n Will merge to 'master'.\n cf. \n source: <20260714032525.1611141-1-cat@malon.dev>\n\n\n* ps/libgit-in-subdir (2026-07-12) 3 commits\n . Move libgit.a sources into separate \"lib/\" directory\n . t/helper: prepare \"test-example-tap.c\" for introduction of \"lib/\"\n . Merge branch 'ps/odb-source-packed' into ps/libgit-in-subdir\n\n The source files for 'libgit.a' have been moved into a new 'lib/'\n directory to clean up the top-level directory and clearly separate\n library code.\n\n Ejected for now, as it causes too many evil merges with other topics.\n\n Waiting for response.\n cf. \n cf. \n cf. \n source: <20260713-pks-libgit-in-subdir-v4-0-696240876eb1@pks.im>\n\n\n* mm/line-log-limited-ops (2026-06-27) 7 commits\n - diffcore-pickaxe: scope -G to the -L tracked range\n - diff: support --check with -L line ranges\n - line-log: support diff stat formats with -L\n - diff: extract a line-range diff helper for reuse\n - diff: emit -L hunk headers via xdiff's formatter\n - diff: simplify the line-range filter by classifying removals immediately\n - diff: rename and group the line-range filter for clarity\n (this branch is used by mm/diff-process-hunks.)\n\n The 'git log -L:' command has been taught to limit\n various 'diff' operations, such as '--stat', '--check', and '-G', to\n the specified range and path.\n\n Needs review.\n cf. \n source: \n\n\n* hn/history-squash (2026-07-20) 5 commits\n (merged to 'next' on 2026-07-23 at 2790c83e45)\n + history: re-edit a squash with every message\n + sequencer: share the squash message marker helpers and flags\n + history: add squash subcommand to fold a range\n + history: give commit_tree_ext a message template\n + history: extract helper for a commit's parent tree\n\n The experimental 'git history' command has been taught a new 'squash'\n subcommand to fold a range of commits into a single commit, with any\n descendants replayed on top.\n\n Will merge to 'master'.\n cf. \n cf. \n source: \n\n\n* tb/midx-incremental-custom-base (2026-06-12) 3 commits\n - midx-write: include packs above custom incremental base\n - midx: pass custom '--base' through incremental writes\n - t5334: expose shared `nth_line()` helper\n\n The 'git multi-pack-index write --incremental' command has been\n corrected to properly honor the '--base' option. Previously, the\n custom base was ignored by the normal write path; packs from layers\n above the selected base were incorrectly skipped by the pack exclusion\n logic, and reachability closure for bitmaps was broken.\n\n Needs review.\n source: \n\n\n* td/ref-filter-memoize-contains (2026-06-12) 3 commits\n (merged to 'next' on 2026-07-19 at 5b640e33a1)\n + commit-reach: die on contains walk errors\n + ref-filter: memoize --contains with generations\n + commit-reach: reject cycles in contains walk\n\n 'git branch --contains' and 'git for-each-ref --contains' have been\n optimized to use the memoized commit traversal previously used only by\n 'git tag --contains', significantly speeding up connectivity checks\n across many candidate refs with shared history.\n\n Will merge to 'master'.\n cf. <20260716091924.GB1212956@coredump.intra.peff.net>\n source: <20260612-ref-filter-memoized-contains-v4-0-5ed39fd001dd@gmail.com>\n\n\n* tc/replay-linearize (2026-07-07) 3 commits\n (merged to 'next' on 2026-07-09 at 371c2e9c3b)\n + replay: offer an option to linearize the commit topology\n + replay: resolve the replay base outside pick_regular_commit()\n + replay: add helper to put entry into replayed_commits\n\n The 'git replay' command has been taught the '--linearize' option to\n drop merge commits and linearize the replayed history, mimicking 'git\n rebase --no-rebase-merges'.\n\n On hold, waiting for response from the author.\n cf. \n cf. \n source: <20260707-toon-git-replay-drop-merges-v7-0-808ab9b4afa6@iotcl.com>\n\n\n* ps/cat-file-remote-object-info (2026-07-24) 13 commits\n (merged to 'next' on 2026-07-24 at e436a42272)\n + cat-file: make remote-object-info allow-list adapt to the server\n + cat-file: add remote-object-info to batch-command\n + transport: add client support for object-info\n + serve: advertise object-info feature\n + protocol-caps: check object existence regardless of the attributes requested\n + fetch-pack: move fetch initialization\n + connect: make write_fetch_command_and_capabilities() more generic\n + fetch-pack: move write_fetch_command_and_capabilities() to connect.c\n + fetch-pack: use unsigned int for hash_algo variable\n + fetch-pack: drop the static advertise_sid variable\n + t1006: extract helper functions into new 'lib-cat-file.sh'\n + cat-file: declare loop counter inside for()\n + transport-helper: fix memory leak of helper on disconnect\n (this branch is used by ps/cat-file-remote-object-info-type.)\n\n The 'remote-object-info' command has been added to 'git cat-file\n --batch-command', allowing clients to request object metadata\n (currently size) from a remote server via protocol v2 without\n downloading the entire object. Format placeholders are dynamically\n filtered on the client based on server-advertised capabilities,\n returning empty strings for inapplicable or unsupported fields.\n\n Will merge to 'master'.\n source: <20260724-ps-eric-work-rebase-v21-0-ba67f024fdff@gmail.com>\n\n\n* mm/diff-process-hunks (2026-07-26) 10 commits\n - line-log: consult diff process for range tracking\n - diff: consult diff process for --stat counts\n - blame: consult diff process for no-hunk detection\n - diff: bypass diff process with --no-ext-diff and in format-patch\n - diff: add long-running diff process via diff..process\n - sub-process: separate process lifecycle from hashmap management\n - userdiff: add diff..process config\n - xdiff: support external hunks via xpparam_t\n - gitattributes: document how external diff drivers relate to diff features\n - Merge branch 'mm/line-log-limited-ops' into mm/diff-process-hunks\n (this branch uses mm/line-log-limited-ops.)\n\n A new 'diff..process' configuration has been introduced to\n allow a long-running external process to act as a hunk provider,\n enabling external tools to control which lines Git considers changed\n while leaving all output formatting (word diff, color, blame, etc.) to\n Git's standard pipeline.\n\n Ejected for now, as it conflicts badly with 'mm/line-log-limited-ops'.\n\n Needs review.\n source: \n\n\n* ty/migrate-trust-executable-bit (2026-07-20) 4 commits\n (merged to 'next' on 2026-07-23 at 4873f289dd)\n + environment: move has_symlinks into repo_config_values\n + environment: move trust_executable_bit into repo_config_values\n + read-cache: pass 'repo' to 'ce_mode_from_stat()'\n + read-cache: remove redundant extern declarations\n\n The 'trust_executable_bit' (coming from the 'core.filemode'\n configuration) has been migrated into 'struct repo_config_values' to\n tie it to a specific repository instance.\n\n Will merge to 'master'.\n cf. \n cf. \n source: <20260720105335.3202013-1-cat@malon.dev>\n\n\n* ec/commit-fixup-options (2026-05-26) 2 commits\n - commit: allow -c/-C for all kinds of --fixup\n - commit: allow -m/-F for all kinds of --fixup\n\n Support for '-m', '-F', '-c', or '-C' options to supply a commit log\n message from outside the editor has been added for all 'git commit\n --fixup' variations.\n\n Needs review.\n source: \n\n\n* hn/branch-delete-merged (2026-07-25) 7 commits\n - branch: add --dry-run for --delete-merged\n - branch: add branch..deleteMerged opt-out\n - branch: add --delete-merged \n - branch: prepare delete_branches for a bulk caller\n - branch: let delete_branches skip unmerged branches on bulk refusal\n - branch: convert delete_branches() to a flags argument\n - branch: add --forked filter for --list mode\n\n The 'git branch' command has been taught the '--delete-merged' option\n to remove local branches that are already merged into their tracked\n remote-tracking branches.\n\n Will merge to 'next'?\n cf. \n source: \n\n\n* ps/shift-root-in-graph (2026-07-14) 7 commits\n (merged to 'next' on 2026-07-19 at bebf13a239)\n + graph: add --[no-]graph-indent and log.graphIndent\n + graph: move config reading into graph_read_config()\n + graph: wrap cascading commits after 4 columns\n + graph: indent visual root in graph\n + graph: add a 2 commit buffer for lookahead\n + revision: add next_commit_to_show()\n + lib-log-graph: move check_graph function\n\n 'git log --graph' has been modified to visually distinguish parentless\n 'root' commits (and commits that become roots due to history\n simplification) by indenting them, preventing them from appearing\n falsely related to unrelated commits rendered immediately above them.\n\n Will merge to 'master'.\n cf. \n source: <20260714-ps-pre-commit-indent-v12-0-d50938e006df@gmail.com>\n\n\n* kk/merge-base-exhaustion (2026-07-11) 11 commits\n - commit-reach: remove commit-date ordering fallback\n - commit-reach: move min_generation check into paint_queue_get()\n - commit-reach: terminate merge-base walk when one paint side is exhausted\n - commit-reach: introduce struct paint_state with per-side counters\n - t6600: add clock-skew topologies and step counts for edge cases\n - commit-reach: add trace2 instrumentation to paint_down_to_common()\n - t6099, t6600: add side-exhaustion regression tests\n - t6600: add test cases for side-exhaustion edge cases\n - test-lib-functions: improve diagnostic output for trace2 data assertions\n - Documentation/technical: add paint-down-to-common doc\n - Merge branch 'kk/commit-reach-find-all-fix' into kk/merge-base-exhaustion\n\n The merge-base computation has been optimized by stopping the walk\n early when one side's exclusive commits in the queue are exhausted,\n yielding significant speedups for queries with one-sided histories.\n\n Needs review.\n cf. \n source: \n"},{"id":"549204","messageId":"f5f7af53-df3e-4902-b350-8fcf8ccb02ad@gmail.com","threadId":"66071","inReplyTo":"xmqqfr15ruw7.fsf@gitster.g","subject":"Re: What's cooking in git.git (Jul 2026, #12)","fromName":"Phillip Wood","fromEmail":"phillip.wood123@gmail.com","sentAt":"2026-07-29T13:24:00Z","receivedAt":"2026-07-29T13:24:06Z","isPatch":false,"body":"On 27/07/2026 04:09, Junio C Hamano wrote:\n> \n> * hn/history-squash (2026-07-20) 5 commits\n> (merged to 'next' on 2026-07-23 at 2790c83e45)\n> + history: re-edit a squash with every message\n> + sequencer: share the squash message marker helpers and flags\n> + history: add squash subcommand to fold a range\n> + history: give commit_tree_ext a message template\n> + history: extract helper for a commit's parent tree\n> \n> The experimental 'git history' command has been taught a new 'squash'\n> subcommand to fold a range of commits into a single commit, with any\n> descendants replayed on top.\n> \n> Will merge to 'master'.\n> cf. \n> cf. \n> source: \n\nOh, I'd missed this going into master. Has the implementation received \nany serious review? I've seen messages from a couple of people trying it \nout but I can't see anybody reading the code. Having a quick look \nthrough it assumes the presence of an UNINTERESTING commit means we have \na BOTTOM commit. It then assumes that UNINTERESTING commit means we \ncannot reach any root commits. Both of those assumptions are false I \nthink. As far as I can see it allows multiple tips so that with\n\n - A - B - C\n \\\n D\n\nit accepts \"^A C D\" but does not squash them correctly. It will refuse \nto squash \"^A C\" if there is a branch pointing to \"B\", but not if there \nonly a branch pointing to \"D\" (in which case the branch is not \nrewritten). It also refuses to squash if there is a tag or remote \ntracking ref pointing to \"B\" which seems rather strange. None of the \nother history commands complain about rewriting commits that are pointed \nto by tags or remote tracking refs.\n\nWithout \"--reedit-message\", it will happily discard \"amend!\" and \n\"squash!\" commit messages even though the user creating them is a strong \nsignal that they intended to use them to reword the commit. \n\"--reedit-message\" is a rather verbose option name which does not make \nsense to me as we're creating a new commit with a new message so we're \nnot re-editing anything. I've commented elsewhere that I strongly \ndislike reusing the rebase squash message template for this command \nwhere we can squash fixups into multiple different commits at the same \ntime. I'll try and go through the patches and produce some fixups, \nthough that may not be until next week.\n\nThanks\n\nPhillip\n\n"},{"id":"549207","messageId":"xmqq1pclc210.fsf@gitster.g","threadId":"66071","inReplyTo":"f5f7af53-df3e-4902-b350-8fcf8ccb02ad@gmail.com","subject":"Re: What's cooking in git.git (Jul 2026, #12)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2026-07-29T14:18:35Z","receivedAt":"2026-07-29T14:18:37Z","isPatch":false,"body":"Phillip Wood writes:\n\n>> The experimental 'git history' command has been taught a new 'squash'\n>> subcommand to fold a range of commits into a single commit, with any\n>> descendants replayed on top.\n>> \n>> Will merge to 'master'.\n>> cf. \n>> cf. \n>> source: \n>\n> Oh, I'd missed this going into master. Has the implementation received \n> any serious review? I've seen messages from a couple of people trying it \n> out but I can't see anybody reading the code.\n\nThanks for stopping me. I am happy to immediately revert the merge\nof this topic into 'next'.\n\nPerhaps I should re-evaluate the \"What's Cooking\" report and eject\nother topics from 'next' as well. There are indeed topics I did not\npersonally read, relying instead on impressions from busy exchanges\n(including earlier iterations read by others X-<).\n\nAre there other topics in 'next' that do not deserve to be there\nyet?\n\nI cannot, of course, afford to be the sole serious reviewer and\nmerge only those I have carefully read through, given that there are\nonly 24 hours in a day and I have other obligations. So either our\nquality criteria must suffer, like this episode showed us, or more\ntopics must be ignored.\n\n> Having a quick look \n> through it assumes the presence of an UNINTERESTING commit means we have \n> a BOTTOM commit. It then assumes that UNINTERESTING commit means we \n> cannot reach any root commits. Both of those assumptions are false I \n> think.\n\nVery true.\n\n> ... I'll try and go through the patches and produce some fixups, \n> though that may not be until next week.\n\nThanks.\n"},{"id":"549211","messageId":"80bd230e-7b8c-41d3-af1c-fa84b0c7b1c4@gmail.com","threadId":"66071","inReplyTo":"xmqqfr15ruw7.fsf@gitster.g","subject":"Re: What's cooking in git.git (Jul 2026, #12)","fromName":"Phillip Wood","fromEmail":"phillip.wood123@gmail.com","sentAt":"2026-07-29T15:14:46Z","receivedAt":"2026-07-29T15:14:50Z","isPatch":false,"body":"On 27/07/2026 04:09, Junio C Hamano wrote:\n> \n> * hn/branch-delete-merged (2026-07-25) 7 commits\n> - branch: add --dry-run for --delete-merged\n> - branch: add branch..deleteMerged opt-out\n> - branch: add --delete-merged \n> - branch: prepare delete_branches for a bulk caller\n> - branch: let delete_branches skip unmerged branches on bulk refusal\n> - branch: convert delete_branches() to a flags argument\n> - branch: add --forked filter for --list mode\n> \n> The 'git branch' command has been taught the '--delete-merged' option\n> to remove local branches that are already merged into their tracked\n> remote-tracking branches.\n> \n> Will merge to 'next'?\n> cf. \n> source: \n\nI've just left some comments on this. It is almost there, but the way it \nchecks if pushing a branch updates its upstream looks dodgy to me. The \nbehavior wrt branches that are merged but are upstreams of other \nbranches has changed so that the entire hierarchy is now preseved. I \npreferred it when we only kept the branch that was the upstream of the \nunmerged branch and deleted everything underneath but I'm happy enough \nif others prefer this new behavior.\n\nThanks\n\nPhillip\n\n"},{"id":"549212","messageId":"414ebe62-c7f6-4d44-bde2-b689e35accfc@gmail.com","threadId":"66071","inReplyTo":"xmqq1pclc210.fsf@gitster.g","subject":"Re: What's cooking in git.git (Jul 2026, #12)","fromName":"Phillip Wood","fromEmail":"phillip.wood123@gmail.com","sentAt":"2026-07-29T15:20:56Z","receivedAt":"2026-07-29T15:20:59Z","isPatch":false,"body":"On 29/07/2026 15:18, Junio C Hamano wrote:\n> Phillip Wood writes:\n> \n>>> The experimental 'git history' command has been taught a new 'squash'\n>>> subcommand to fold a range of commits into a single commit, with any\n>>> descendants replayed on top.\n>>>\n>>> Will merge to 'master'.\n>>> cf. \n>>> cf. \n>>> source: \n>>\n>> Oh, I'd missed this going into master. Has the implementation received\n>> any serious review? I've seen messages from a couple of people trying it\n>> out but I can't see anybody reading the code.\n> \n> Thanks for stopping me. I am happy to immediately revert the merge\n> of this topic into 'next'.\n> \n> Perhaps I should re-evaluate the \"What's Cooking\" report and eject\n> other topics from 'next' as well. There are indeed topics I did not\n> personally read, relying instead on impressions from busy exchanges\n> (including earlier iterations read by others X-<).\n> \n> Are there other topics in 'next' that do not deserve to be there\n> yet?\n\nThere aren't any others that I'm aware of, but I've not looked at most \nof them so that probably does not mean much.\n\n> I cannot, of course, afford to be the sole serious reviewer and\n> merge only those I have carefully read through, given that there are\n> only 24 hours in a day and I have other obligations. So either our\n> quality criteria must suffer, like this episode showed us, or more\n> topics must be ignored.\n\nYes, we could really do with more reviewers\n\n>> Having a quick look\n>> through it assumes the presence of an UNINTERESTING commit means we have\n>> a BOTTOM commit. It then assumes that UNINTERESTING commit means we\n>> cannot reach any root commits. Both of those assumptions are false I\n>> think.\n> \n> Very true.\n> \n>> ... I'll try and go through the patches and produce some fixups,\n>> though that may not be until next week.\n\nHarald - I've got some half finished fixups that I didn't get round it \nfinishing when I had a look at this last week that I'll clean up and \nsend so I'd hold off re-rolling for now.\n\nThanks\n\nPhillip\n\n\n"},{"id":"549217","messageId":"xmqqa4r9aj4u.fsf@gitster.g","threadId":"66071","inReplyTo":"80bd230e-7b8c-41d3-af1c-fa84b0c7b1c4@gmail.com","subject":"Re: What's cooking in git.git (Jul 2026, #12)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2026-07-29T15:52:01Z","receivedAt":"2026-07-29T15:52:04Z","isPatch":false,"body":"Phillip Wood writes:\n\n> On 27/07/2026 04:09, Junio C Hamano wrote:\n>> \n>> * hn/branch-delete-merged (2026-07-25) 7 commits\n>> - branch: add --dry-run for --delete-merged\n>> - branch: add branch..deleteMerged opt-out\n>> - branch: add --delete-merged \n>> - branch: prepare delete_branches for a bulk caller\n>> - branch: let delete_branches skip unmerged branches on bulk refusal\n>> - branch: convert delete_branches() to a flags argument\n>> - branch: add --forked filter for --list mode\n>> \n>> The 'git branch' command has been taught the '--delete-merged' option\n>> to remove local branches that are already merged into their tracked\n>> remote-tracking branches.\n>> \n>> Will merge to 'next'?\n>> cf. \n>> source: \n>\n> I've just left some comments on this. It is almost there, but the way it \n> checks if pushing a branch updates its upstream looks dodgy to me. The \n> behavior wrt branches that are merged but are upstreams of other \n> branches has changed so that the entire hierarchy is now preseved. I \n> preferred it when we only kept the branch that was the upstream of the \n> unmerged branch and deleted everything underneath but I'm happy enough \n> if others prefer this new behavior.\n\nI don't particularly favor the behavior in the latest round myself,\nbut I doubt I am the primary target audience, so I'll let the list\nfigure out how much we collectively care ;-).\n\nThanks.\n"},{"id":"549225","messageId":"xmqqbjbpptzr.fsf@gitster.g","threadId":"66071","inReplyTo":"414ebe62-c7f6-4d44-bde2-b689e35accfc@gmail.com","subject":"Re: What's cooking in git.git (Jul 2026, #12)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2026-07-29T17:48:24Z","receivedAt":"2026-07-29T17:48:27Z","isPatch":false,"body":"Phillip Wood writes:\n\n>> Perhaps I should re-evaluate the \"What's Cooking\" report and eject\n>> other topics from 'next' as well. There are indeed topics I did not\n>> personally read, relying instead on impressions from busy exchanges\n>> (including earlier iterations read by others X-<).\n>> \n>> Are there other topics in 'next' that do not deserve to be there\n>> yet?\n>\n> There aren't any others that I'm aware of, but I've not looked at most \n> of them so that probably does not mean much.\n>\n>> I cannot, of course, afford to be the sole serious reviewer and\n>> merge only those I have carefully read through, given that there are\n>> only 24 hours in a day and I have other obligations. So either our\n>> quality criteria must suffer, like this episode showed us, or more\n>> topics must be ignored.\n>\n> Yes, we could really do with more reviewers\n\nPerhaps the sensible thing for me to do is to stop taking any new\ntopics into 'seen', even if I've spotted them, until I see somebody\ngive them a real review.\n\nOtherwise, it becomes too tempting for me to jump in, give them a\nsuperficial read after seeing them linger in the \"What's Cooking\"\ndraft in the \"Needs review\" state for too long, and, believing I've\nseen enough, mark them for 'next'. If I don't queue a patch that\nnobody seems to have read carefully, I won't succumb to such\ntemptation.\n"},{"id":"549260","messageId":"CAHwyqnXYi76rMOWYEgJhoh2rXaTgLbze7mKd+WGoC9BbDFHXHA@mail.gmail.com","threadId":"66071","inReplyTo":"f5f7af53-df3e-4902-b350-8fcf8ccb02ad@gmail.com","subject":"Re: What's cooking in git.git (Jul 2026, #12)","fromName":"Harald Nordgren","fromEmail":"haraldnordgren@gmail.com","sentAt":"2026-07-30T06:11:45Z","receivedAt":"2026-07-30T06:12:26Z","isPatch":false,"body":"> Without \"--reedit-message\", it will happily discard \"amend!\" and\n> \"squash!\" commit messages even though the user creating them is a strong\n> signal that they intended to use them to reword the commit.\n> \"--reedit-message\" is a rather verbose option name which does not make\n> sense to me as we're creating a new commit with a new message so we're\n> not re-editing anything. I've commented elsewhere that I strongly\n> dislike reusing the rebase squash message template for this command\n> where we can squash fixups into multiple different commits at the same\n> time.\n\nShould we always do \"--reedit-message\" then, i.e. remove the option\nand have it as the default? Do we need a \"--no-edit\" switch then\ninstead? Maybe not, user will then always have the editor opened and\nthey can save and quit if they don't care.\n\nI'm not sure about changing the template.\n\n\nHarald\n"},{"id":"549330","messageId":"DKCJF4116DLD.3B078238N2B12@lfurio.us","threadId":"66071","inReplyTo":"xmqq1pclc210.fsf@gitster.g","subject":"Re: What's cooking in git.git (Jul 2026, #12)","fromName":"Matt Hunter","fromEmail":"m@lfurio.us","sentAt":"2026-07-31T06:20:23Z","receivedAt":"2026-07-31T06:28:51Z","isPatch":false,"body":"On Wed Jul 29, 2026 at 10:18 AM EDT, Junio C Hamano wrote:\n> Phillip Wood writes:\n>\n>>> The experimental 'git history' command has been taught a new 'squash'\n>>> subcommand to fold a range of commits into a single commit, with any\n>>> descendants replayed on top.\n>>> \n>>> Will merge to 'master'.\n>>> cf. \n>>> cf. \n>>> source: \n>>\n>> Oh, I'd missed this going into master. Has the implementation received \n>> any serious review? I've seen messages from a couple of people trying it \n>> out but I can't see anybody reading the code.\n\nI believe I was one of the last people to comment on it. I _had_ done a\nread through of the code, spotted some things, but appear to have\nmissed these more nuanced interactions. My last \"lgtm\" message in the\nthread really meant to say \"these latest fixes sufficiently address my\ncomments\". And as someone who doesn't have much history on the mailing\nlist, I assumed Junio would weigh my approval accordingly :)\n\nI didn't notice this had advanced to next either, and may have spoken up\nsooner if I did.\n\nSo given all that, assuming I had come along and looked at these\npatches, but found no issues in the first place, I probably would have\nstayed silent. Should I be more careful with such a blanket \"this is\ngood\" message in the future?\n\nSorry for any hassle - though I don't expect you \"blame\" reviewers for\nthis sort of thing. It's a lot harder to demonstrate correctness than\npoint out some potential problem.\n"},{"id":"549331","messageId":"DKCKB3HW6VJA.19CQLPOHR6WTI@lfurio.us","threadId":"66071","inReplyTo":"CAHwyqnXYi76rMOWYEgJhoh2rXaTgLbze7mKd+WGoC9BbDFHXHA@mail.gmail.com","subject":"Re: What's cooking in git.git (Jul 2026, #12)","fromName":"Matt Hunter","fromEmail":"m@lfurio.us","sentAt":"2026-07-31T07:02:10Z","receivedAt":"2026-07-31T07:02:12Z","isPatch":false,"body":"On Thu Jul 30, 2026 at 2:11 AM EDT, Harald Nordgren wrote:\n>> Without \"--reedit-message\", it will happily discard \"amend!\" and\n>> \"squash!\" commit messages even though the user creating them is a strong\n>> signal that they intended to use them to reword the commit.\n>> \"--reedit-message\" is a rather verbose option name which does not make\n>> sense to me as we're creating a new commit with a new message so we're\n>> not re-editing anything. I've commented elsewhere that I strongly\n>> dislike reusing the rebase squash message template for this command\n>> where we can squash fixups into multiple different commits at the same\n>> time.\n\nI also agree with these points, but given that they were already brought\nup and dismissed before, I felt it wasn't my place to try to dictate\nhigh-level design.\n\nI may be misunderstanding your current concern with the first sentence\nPhillip, but this was (at least in part) one of the recent things\naddressed in this feature [1] [2]. If we go with the assumption that the\ndefault behavior is to squash all the changes, but abandon all context\noutside that provided by the first commit, then accepting amend!\nmessages for that first commit seems to drive the behavior closer to\nwhat you describe.\n\n> Should we always do \"--reedit-message\" then, i.e. remove the option\n> and have it as the default? Do we need a \"--no-edit\" switch then\n> instead? Maybe not, user will then always have the editor opened and\n> they can save and quit if they don't care.\n\nA script running 'git history squash' may have a harder time with this,\nthough something like 'git -c core.editor=/bin/true history squash' is\nat least _some_ workaround.\n\nIt would seem consistent with other git commands to offer both an --edit\nand --no-edit option. If --edit is the default, it may make sense to\noffer the option anyway, for the sake of some potential future where\nthere exists a config 'history.editSquashMsg' (for example). '--edit'\nwould then override a configured value of 'false'. Of course, the\nprecedent is --reedit-message so far in 'git history'.\n\n1: https://lore.kernel.org/git/DJY0QSJYNG0J.210HZQH198Y1N@lfurio.us/\n2: https://lore.kernel.org/git/pull.2337.v9.git.git.1784128573.gitgitgadget@gmail.com/\n"},{"id":"549354","messageId":"xmqq8q6rdvcl.fsf@gitster.g","threadId":"66071","inReplyTo":"DKCJF4116DLD.3B078238N2B12@lfurio.us","subject":"Re: What's cooking in git.git (Jul 2026, #12)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2026-07-31T15:36:42Z","receivedAt":"2026-07-31T15:36:44Z","isPatch":false,"body":"\"Matt Hunter\" writes:\n\n> Sorry for any hassle - though I don't expect you \"blame\" reviewers for\n> this sort of thing. It's a lot harder to demonstrate correctness than\n> point out some potential problem.\n\nYes, I agree that giving positive reviews is a lot harder to do.\n\n"},{"id":"549476","messageId":"f00673cc-afc8-4a4f-a668-e22c53b46181@gmail.com","threadId":"66071","inReplyTo":"DKCKB3HW6VJA.19CQLPOHR6WTI@lfurio.us","subject":"Re: What's cooking in git.git (Jul 2026, #12)","fromName":"Phillip Wood","fromEmail":"phillip.wood123@gmail.com","sentAt":"2026-08-03T09:05:15Z","receivedAt":"2026-08-03T09:05:19Z","isPatch":false,"body":"Hi Matt\n\nOn 31/07/2026 08:02, Matt Hunter wrote:\n> On Thu Jul 30, 2026 at 2:11 AM EDT, Harald Nordgren wrote:\n>>> Without \"--reedit-message\", it will happily discard \"amend!\" and\n>>> \"squash!\" commit messages even though the user creating them is a strong\n>>> signal that they intended to use them to reword the commit.\n>>> \"--reedit-message\" is a rather verbose option name which does not make\n>>> sense to me as we're creating a new commit with a new message so we're\n>>> not re-editing anything. I've commented elsewhere that I strongly\n>>> dislike reusing the rebase squash message template for this command\n>>> where we can squash fixups into multiple different commits at the same\n>>> time.\n> \n> I also agree with these points, but given that they were already brought\n> up and dismissed before, I felt it wasn't my place to try to dictate\n> high-level design.\n\nIf you raise a point and it is dismissed without a convincing \nexplanation then its fine to raise it again asking for more details so \nthat you can understand the reason behind the decision. That often leads \nto a productive discussion and an improved design.\n\n> I may be misunderstanding your current concern with the first sentence\n> Phillip, but this was (at least in part) one of the recent things\n> addressed in this feature [1] [2]. If we go with the assumption that the\n> default behavior is to squash all the changes, but abandon all context\n> outside that provided by the first commit, then accepting amend!\n> messages for that first commit seems to drive the behavior closer to\n> what you describe.\n\nMy feeling is that \"amend!\" and \"squash!\" commit messages indicate that \nthe user intended to use them when they squashed so I think we should be \na bit more careful about dropping them compared to other messages.\n\n>> Should we always do \"--reedit-message\" then, i.e. remove the option\n>> and have it as the default? Do we need a \"--no-edit\" switch then\n>> instead? Maybe not, user will then always have the editor opened and\n>> they can save and quit if they don't care.\n> \n> A script running 'git history squash' may have a harder time with this,\n> though something like 'git -c core.editor=/bin/true history squash' is\n> at least _some_ workaround.\n\nCan't the script just pass --edit/--no-edit?\n\n> It would seem consistent with other git commands to offer both an --edit\n> and --no-edit option. If --edit is the default, it may make sense to\n> offer the option anyway, for the sake of some potential future where\n> there exists a config 'history.editSquashMsg' (for example). '--edit'\n> would then override a configured value of 'false'. Of course, the\n> precedent is --reedit-message so far in 'git history'.\n\nThat precedent is unfortunate, \"--reedit-message\" makes sense for the \n\"fixup\" subcommand because we are reediting an existing message but \nthat's not the case with the \"squash\" subcommand where we're \nconstructing a new message from several commits. Given how new the \n\"fixup\" subcommand is I'm tempted to add an \"--edit\" option and \ndeprecate \"--reedit-message\".\n\nHaving thought about it a bit over the weekend I wonder if the best \nsolution when squashing is to default to looking at the commits being \nsquashed before deciding whether to open the editor or not and allow the \nuser to override that on the commandline like \"git commit\". If we're \nsquashing a bunch of \"fixup!\" and/or \"amend!\" commits into a single \ntarget then I'm not sure its worth opening the editor, but if we're \nsquashing other commits together then it probably makes sense to open \nthe editor so the user can check the result. I guess the danger is it \nends up being confusing.\n\nThanks\n\nPhillip\n\n> 1: https://lore.kernel.org/git/DJY0QSJYNG0J.210HZQH198Y1N@lfurio.us/\n> 2: https://lore.kernel.org/git/pull.2337.v9.git.git.1784128573.gitgitgadget@gmail.com/\n\n"},{"id":"549477","messageId":"ddd0160c-7f4c-41c7-855f-58288db00050@gmail.com","threadId":"66071","inReplyTo":"CAHwyqnXYi76rMOWYEgJhoh2rXaTgLbze7mKd+WGoC9BbDFHXHA@mail.gmail.com","subject":"Re: What's cooking in git.git (Jul 2026, #12)","fromName":"Phillip Wood","fromEmail":"phillip.wood123@gmail.com","sentAt":"2026-08-03T09:11:46Z","receivedAt":"2026-08-03T09:11:50Z","isPatch":false,"body":"Hi Harald\n\nOn 30/07/2026 07:11, Harald Nordgren wrote:\n>> Without \"--reedit-message\", it will happily discard \"amend!\" and\n>> \"squash!\" commit messages even though the user creating them is a strong\n>> signal that they intended to use them to reword the commit.\n>> \"--reedit-message\" is a rather verbose option name which does not make\n>> sense to me as we're creating a new commit with a new message so we're\n>> not re-editing anything. I've commented elsewhere that I strongly\n>> dislike reusing the rebase squash message template for this command\n>> where we can squash fixups into multiple different commits at the same\n>> time.\n> \n> Should we always do \"--reedit-message\" then, i.e. remove the option\n> and have it as the default? Do we need a \"--no-edit\" switch then\n> instead? Maybe not, user will then always have the editor opened and\n> they can save and quit if they don't care.\n\nI've left some thoughts about the default in my reply to Matt. Whatever \nthe default I don't think there is a good reason not to let the user \noverride it on the commandline,\n\n> I'm not sure about changing the template.\n\nI know you're reluctant but I don't remembering seeing an explanation as \nto why you think the rebase template, which was designed (or more \naccurately evolved) for squashing fixups into a single target, is a good \nfit for a command that squashes fixups into multiple targets. As I've \nexplained before my worry is that we end up with fragments of the commit \nmessage separated by a screen full of commented lines which makes it \nboth hard to edit the message and difficult to get an overview of which \ncommits are being squashed.\n\nThanks\n\nPhillip\n\n\n"},{"id":"549502","messageId":"xmqqfr0vyyxm.fsf@gitster.g","threadId":"66071","inReplyTo":"f00673cc-afc8-4a4f-a668-e22c53b46181@gmail.com","subject":"Re: What's cooking in git.git (Jul 2026, #12)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2026-08-03T16:02:45Z","receivedAt":"2026-08-03T16:02:48Z","isPatch":false,"body":"Phillip Wood writes:\n\n> If you raise a point and it is dismissed without a convincing \n> explanation then its fine to raise it again asking for more details so \n> that you can understand the reason behind the decision. That often leads \n> to a productive discussion and an improved design.\n\nTrue. But because \"convincing\" is not black and white, we need to\nbe careful a bit.\n\n> That precedent is unfortunate, \"--reedit-message\" makes sense for the \n> \"fixup\" subcommand because we are reediting an existing message but \n> that's not the case with the \"squash\" subcommand where we're \n> constructing a new message from several commits. Given how new the \n> \"fixup\" subcommand is I'm tempted to add an \"--edit\" option and \n> deprecate \"--reedit-message\".\n\nAs \"git history\" is marked experimental, we can afford to tweak the\nUI for the better ;-).\n\n> Having thought about it a bit over the weekend I wonder if the best \n> solution when squashing is to default to looking at the commits being \n> squashed before deciding whether to open the editor or not and allow the \n> user to override that on the commandline like \"git commit\". If we're \n> squashing a bunch of \"fixup!\" and/or \"amend!\" commits into a single \n> target then I'm not sure its worth opening the editor...\n\nHmph, a base commit with an \"amend!\" (tells the machinery to use the\nmessage from the \"amend!\" commit only, discarding the existing one)\nis clear to me that there is no need for further editing, but if\nthere is any \"fixup!\" (code change, for which need for associating\nlog message change is unknown) or if there are multiple \"amend!\", I\nam not so sure. It does make it confusing, I suspect.\n\n"},{"id":"549566","messageId":"97c244f4-52d1-4d59-9ced-6f2dbe14a2f6@gmail.com","threadId":"66071","inReplyTo":"xmqqfr0vyyxm.fsf@gitster.g","subject":"Re: What's cooking in git.git (Jul 2026, #12)","fromName":"Phillip Wood","fromEmail":"phillip.wood123@gmail.com","sentAt":"2026-08-04T13:19:51Z","receivedAt":"2026-08-04T13:19:59Z","isPatch":false,"body":"On 03/08/2026 17:02, Junio C Hamano wrote:\n> Phillip Wood writes:\n> \n>> If you raise a point and it is dismissed without a convincing\n>> explanation then its fine to raise it again asking for more details so\n>> that you can understand the reason behind the decision. That often leads\n>> to a productive discussion and an improved design.\n> \n> True. But because \"convincing\" is not black and white, we need to\n> be careful a bit.\n\nIndeed - what I'm really looking for in a discussion is to be convinced \nthat there is a reasonably logical rationale behind a decision and that \nthe other person has considered the counterarguments. Many decisions are \ntrade offs and different people may quite reasonably place different \nweight the factors involved leading to different results. If I disagree \nwith a decision I try to only keep pushing back if I think the logic \nbehind the decision is flawed. I also find such discussions useful for \nimproving my own understanding of the problem and sometimes change my \nmind as a result.\n\n>> Having thought about it a bit over the weekend I wonder if the best\n>> solution when squashing is to default to looking at the commits being\n>> squashed before deciding whether to open the editor or not and allow the\n>> user to override that on the commandline like \"git commit\". If we're\n>> squashing a bunch of \"fixup!\" and/or \"amend!\" commits into a single\n>> target then I'm not sure its worth opening the editor...\n> \n> Hmph, a base commit with an \"amend!\" (tells the machinery to use the\n> message from the \"amend!\" commit only, discarding the existing one)\n> is clear to me that there is no need for further editing, but if\n> there is any \"fixup!\" (code change, for which need for associating\n> log message change is unknown) or if there are multiple \"amend!\", I\n> am not so sure. It does make it confusing, I suspect.\n\nI certainly don't object to always opening the editor, it has the \nadvantage that it is much easier to explain and encourages users to \nrevise the commit message when they are squashing.\n\nThanks\n\nPhillip\n\n"},{"id":"549693","messageId":"47bd0302-fc52-4df0-98a0-6fad7eb0fb05@gmail.com","threadId":"66071","inReplyTo":"xmqqbjbpptzr.fsf@gitster.g","subject":"Re: What's cooking in git.git (Jul 2026, #12)","fromName":"Phillip Wood","fromEmail":"phillip.wood123@gmail.com","sentAt":"2026-08-05T13:10:39Z","receivedAt":"2026-08-05T13:10:17Z","isPatch":false,"body":"Hi Junio\n\nOn 29/07/2026 18:48, Junio C Hamano wrote:\n> \n> Perhaps the sensible thing for me to do is to stop taking any new\n> topics into 'seen', even if I've spotted them, until I see somebody\n> give them a real review.\n> \n> Otherwise, it becomes too tempting for me to jump in, give them a\n> superficial read after seeing them linger in the \"What's Cooking\"\n> draft in the \"Needs review\" state for too long, and, believing I've\n> seen enough, mark them for 'next'. If I don't queue a patch that\n> nobody seems to have read carefully, I won't succumb to such\n> temptation.\n\nMaybe, though I do find having the patches in seen makes it easier to do \nan in-depth review as it means I don't have to apply them myself.\n\nThanks\n\nPhillip\n\n"},{"id":"549749","messageId":"xmqqmrv0qz3d.fsf@gitster.g","threadId":"66071","inReplyTo":"47bd0302-fc52-4df0-98a0-6fad7eb0fb05@gmail.com","subject":"Re: What's cooking in git.git (Jul 2026, #12)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2026-08-05T17:03:18Z","receivedAt":"2026-08-05T17:03:20Z","isPatch":false,"body":"Phillip Wood writes:\n\n> Hi Junio\n>\n> On 29/07/2026 18:48, Junio C Hamano wrote:\n>> \n>> Perhaps the sensible thing for me to do is to stop taking any new\n>> topics into 'seen', even if I've spotted them, until I see somebody\n>> give them a real review.\n>> \n>> Otherwise, it becomes too tempting for me to jump in, give them a\n>> superficial read after seeing them linger in the \"What's Cooking\"\n>> draft in the \"Needs review\" state for too long, and, believing I've\n>> seen enough, mark them for 'next'. If I don't queue a patch that\n>> nobody seems to have read carefully, I won't succumb to such\n>> temptation.\n>\n> Maybe, though I do find having the patches in seen makes it easier to do \n> an in-depth review as it means I don't have to apply them myself.\n\nYes, that is a very good point. And if the authors are paying\nattention, it would hopefully also help them how well their changes\nplay with others' changes.\n\nOK, then I will keep picking them up, but under these conditions:\n\n (1) They will not leave 'seen' without anyone commenting on them;\n\n (2) They will automatically be discarded after four weeks without\n positive feedback; and\n\n (3) I will not feel obligated to review them even if no one steps up.\n\nThanks.\n"}]}