{"thread":{"id":"62823","subject":"What's cooking in git.git (Jan 2025, #05; Fri, 17)","startedAt":"2025-01-18T00:42:04Z","lastAt":"2025-01-24T17:06:37Z","messageCount":23,"participants":["Junio C Hamano","Jeff King","David Aguilar","Derrick Stolee","Karthik Nayak","Taylor Blau","Patrick Steinhardt"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"510859","messageId":"xmqqwmetgdgm.fsf@gitster.g","threadId":"62823","inReplyTo":null,"subject":"What's cooking in git.git (Jan 2025, #05; Fri, 17)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-01-18T00:42:01Z","receivedAt":"2025-01-18T00:42:04Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Here are the topics that have been cooking in my tree. Commits\nprefixed with '+' are in 'next' (being in 'next' is a sign that a\ntopic is stable enough to be used and are candidate to be in a\nfuture release). Commits prefixed with '-' are only in 'seen', and\naren't considered \"accepted\" at all and may be annotated with an URL\nto a message that raises issues but they are no means exhaustive. A\ntopic without enough support may be discarded after a long period of\nno activity (of course they can be resubmit when new interests\narise).\n\nThere are quite a few topics that are listed here but without much\nreview activities. I'll review the notes below with list archive\nmyself to see which ones are truly stale and discard them, maybe\nlater next week.\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[Graduated to 'master']\n\n* as/long-option-help-i18n (2024-12-30) 1 commit\n (merged to 'next' on 2024-12-30 at 900c79808f)\n + parse-options: localize mark-up of placeholder text in the short help\n\n Tweak the help text used for the option value placeholders by\n parse-options API so that translations can customize the \"<>\"\n placeholder signal (e.g. \"--option=\").\n source: <20241228114221.10351-4-ash@kambanaria.org>\n\n\n* mb/t7110-use-test-path-helper (2025-01-03) 1 commit\n (merged to 'next' on 2025-01-06 at cd96b0ac82)\n + t7110: replace `test -f` with `test_path_is_*` helpers\n\n Test modernization.\n source: <20250103130035.79376-1-matteobagnolini2003@gmail.com>\n\n\n* ps/meson-weak-sha1-build (2024-12-30) 8 commits\n (merged to 'next' on 2025-01-01 at e01db872e4)\n + meson: provide a summary of configured backends\n + meson: wire up unsafe SHA1 backend\n + meson: add missing dots for build options\n + meson: simplify conditions for HTTPS and SHA1 dependencies\n + meson: require SecurityFramework when it's used as SHA1 backend\n + meson: deduplicate access to SHA1/SHA256 backend options\n + meson: consistenlty spell 'CommonCrypto'\n + Merge branch 'ps/weak-sha1-for-tail-sum-fix' into ps/meson-weak-sha1-build\n (this branch is used by ps/build-meson-fixes and ps/zlib-ng.)\n\n meson-based build now supports the unsafe-sha1 build knob.\n source: <20241230-pks-meson-sha1-unsafe-v1-0-efb276e171f5@pks.im>\n\n\n* ps/more-sign-compare (2024-12-27) 10 commits\n (merged to 'next' on 2025-01-01 at 41c78cf690)\n + sign-compare: avoid comparing ptrdiff with an int/unsigned\n + commit-reach: use `size_t` to track indices when computing merge bases\n + shallow: fix -Wsign-compare warnings\n + builtin/log: fix remaining -Wsign-compare warnings\n + builtin/log: use `size_t` to track indices\n + commit-reach: use `size_t` to track indices in `get_reachable_subset()`\n + commit-reach: use `size_t` to track indices in `remove_redundant()`\n + commit-reach: fix type of `min_commit_date`\n + commit-reach: fix index used to loop through unsigned integer\n + prio-queue: fix type of `insertion_ctr`\n\n More -Wsign-compare fixes.\n cf. https://staticthinking.wordpress.com/2023/07/25/wsign-compare-is-garbage/\n source: <20241227-b4-pks-commit-reach-sign-compare-v1-0-07c59c2aa632@pks.im>\n\n\n* ps/object-collision-check (2025-01-06) 4 commits\n (merged to 'next' on 2025-01-06 at 540e2bae11)\n + object-file: retry linking file into place when occluding file vanishes\n + object-file: don't special-case missing source file in collision check\n + object-file: rename variables in `check_collision()`\n (merged to 'next' on 2024-12-30 at e083ea3154)\n + object-file: fix race in object collision check\n\n CI jobs gave sporadic failures, which turns out that that the\n object finalization code was giving an error when it did not have\n to.\n source: <20250106-b4-pks-object-file-racy-collision-check-v2-0-8b3984ecbb18@pks.im>\n\n\n* re/submodule-parse-opt (2024-12-11) 7 commits\n (merged to 'next' on 2024-12-21 at 9e65a56a63)\n + git-submodule.sh: rename some variables\n + git-submodule.sh: improve variables readability\n + git-submodule.sh: add some comments\n + git-submodule.sh: get rid of unused variable\n + git-submodule.sh: get rid of isnumber\n + git-submodule.sh: improve parsing of short options\n + git-submodule.sh: improve parsing of some long options\n\n \"git submodule\" learned various ways to spell the same option,\n e.g. \"--branch=B\" can be spelled \"--branch B\" or \"-bB\".\n source: <20241211063234.7610-1-royeldar0@gmail.com>\n\n--------------------------------------------------\n[New Topics]\n\n* sj/meson-doc-technical-dependency-fix (2025-01-14) 1 commit\n (merged to 'next' on 2025-01-16 at 3ec55e0703)\n + meson: fix missing deps for technical articles\n\n The meson build procedure for Documentation/technical/ hiearchy was\n missing necessary dependencies, which has been corrected.\n\n Will merge to 'master'.\n source: <5114dc9a00377826a55f6bab007d2ad1a4de8bc5.1736866030.git.sam@gentoo.org>\n\n\n* tc/meson-use-our-version-def-h (2025-01-14) 1 commit\n (merged to 'next' on 2025-01-16 at 76e9e81736)\n + meson: ensure correct version-def.h is used\n\n The meson build procedure looked for the 'version-def.h' file in a\n wrong directory, which has been corrected.\n\n Will merge to 'master'.\n source: <20250114-toon-fix-meson-version-v2-1-66ddb1a82c28@iotcl.com>\n\n\n* js/libgit-rust (2025-01-16) 6 commits\n - fixup! common-main: split init and exit code into new files\n - Makefile: add option to build and test libgit-rs and libgit-rs-sys\n - libgit: add higher-level libgit crate\n - libgit-sys: also export some config_set functions\n - libgit-sys: introduce Rust wrapper for libgit.a\n - common-main: split init and exit code into new files\n\n Foreign language interface for Rust into our code base has been added.\n\n Needs to be aware of meson build?\n cf. \n source: \n\n\n* kn/reflog-migration-fix (2025-01-15) 1 commit\n (merged to 'next' on 2025-01-16 at ae8f9ce9a0)\n + reftable: write correct max_update_index to header\n (this branch is used by kn/reflog-migration-fix-followup.)\n\n \"git refs migrate\" for migrating reflog data was broken.\n\n Will merge to 'master'.\n cf. \n source: \n\n\n* jc/show-usage-help (2025-01-17) 6 commits\n - builtin: send usage() help text to standard output\n - oddballs: send usage() help text to standard output\n - builtins: send usage_with_options() help text to standard output\n - usage: add show_usage_if_asked()\n - parse-options: add show_usage_with_options_if_asked()\n - t0012: optionally check that \"-h\" output goes to stdout\n\n The help text from \"git $cmd -h\" appear on the standard output for\n some $cmd and the standard error for others. The built-in commands\n have been fixed to show them on the standard output consistently.\n\n Will merge to 'next'.\n cf. <20250117114123.GA2356746@coredump.intra.peff.net>\n\n\n* kn/pack-write-with-reduced-globals (2025-01-17) 5 commits\n - pack-write: pass hash_algo to internal functions\n - pack-write: pass hash_algo to `write_rev_file()`\n - pack-write: pass hash_algo to `write_idx_file()`\n - pack-write: pass repository to `index_pack_lockfile()`\n - pack-write: pass hash_algo to `fixup_pack_header_footer()`\n\n Code clean-up.\n\n Well merge to 'next'?\n cf. \n source: <20250117-kn-the-repo-cleanup-v2-0-a7fdc19688f5@gmail.com>\n\n\n* ps/reftable-sign-compare (2025-01-16) 10 commits\n - reftable: address trivial -Wsign-compare warnings\n - reftable/blocksource: adjust `read_block()` to return `ssize_t`\n - reftable/blocksource: adjust type of the block length\n - reftable/block: adjust type of the restart length\n - reftable/block: adapt header and footer size to return a `size_t`\n - reftable/basics: adjust `hash_size()` to return `uint32_t`\n - reftable/basics: adjust `common_prefix_size()` to return `size_t`\n - reftable/record: handle overflows when decoding varints\n - reftable/record: drop unused `print` function pointer\n - meson: stop disabling -Wsign-compare\n\n THe reftable/ library code has been made -Wsign-compare clean.\n\n Will merge to 'next'?\n source: <20250116-b4-pks-reftable-sign-compare-v1-0-bd30e2ee96e7@pks.im>\n\n\n* sk/unit-tests (2025-01-17) 4 commits\n - t/unit-tests: convert reftable tree test to use clar test framework\n - t/unit-tests: adapt priority queue test to use clar test framework\n - t/unit-tests: convert mem-pool test to use clar test framework\n - t/unit-tests: handle dashes in test suite filenames\n\n Move a few more unit tests to the clar test framework.\n\n Will merge to 'next'.\n source: <20250117122926.101749-1-kuforiji98@gmail.com>\n\n\n* zh/gc-expire-to (2025-01-16) 1 commit\n - gc: add `--expire-to` option\n\n \"git gc\" learned the \"--expire-to\" option and passes it down to\n underlying \"git repack\".\n\n Needs review.\n source: \n\n\n* jc/cli-doc-option-and-config (2025-01-17) 1 commit\n (merged to 'next' on 2025-01-17 at 71f41b00d8)\n + gitcli: document that command line trumps config and env\n\n Doc update.\n\n Will merge to 'master'.\n source: \n\n\n* jk/pack-header-parse-alignment-fix (2025-01-17) 3 commits\n - index-pack, unpack-objects: use skip_prefix to avoid magic number\n - parse_pack_header_option(): avoid unaligned memory writes\n - packfile: factor out --pack_header argument parsing\n\n It was possible for \"git unpack-objects\" and \"git index-pack\" to\n make an unaligned access, which has been corrected.\n\n Will merge to 'next'.\n source: <20250117125207.GB2356599@coredump.intra.peff.net>\n\n\n* kn/reflog-migration-fix-followup (2025-01-17) 4 commits\n - reftable: prevent 'update_index' changes after header write\n - refs: use 'uint64_t' for 'ref_update.index'\n - refs: mark `ref_transaction_update_reflog()` as static\n - Merge branch 'kn/reflog-migration-fix' into kn/reflog-migration-fix-followup\n (this branch uses kn/reflog-migration-fix.)\n\n Code clean-up.\n\n source: <20250117-461-corrupted-reftable-followup-v1-0-70ee605ae3fe@gmail.com>\n\n\n* mh/connect-sign-compare (2025-01-17) 1 commit\n - connect: address -Wsign-compare warnings\n\n The code in connect.c has been updated to work around complaints\n from -Wsign-compare.\n\n Will merge to 'next'.\n source: <20250117074909.1430067-1-mh@glandium.org>\n\n\n* ps/build-meson-subtree (2025-01-17) 3 commits\n - meson: wire up the git-subtree(1) command\n - meson: introduce build option for contrib\n - contrib/subtree: fix building docs\n\n THe meson-driven build is now aware of \"git-subtree\" housed in\n contrib/subtree hierarchy.\n\n Will merge to 'next'.\n source: <20250117-b4-pks-build-subtree-v1-0-03c2ed6cc42e@pks.im>\n\n--------------------------------------------------\n[Cooking]\n\n* ak/instaweb-python-port-binding-fix (2025-01-10) 1 commit\n (merged to 'next' on 2025-01-17 at bcb5e21e0b)\n + instaweb: fix ip binding for the python http.server\n\n The \"instaweb\" bound only to local IP address without \"--local\" and\n to all addresses with \"--local\", which was the other way around, when\n using Python's http.server class, which has been corrected.\n\n Will merge to 'master'.\n source: <20250110101346.30416-1-alecsk@gmail.com>\n\n\n* bf/fetch-set-head-fix (2025-01-13) 1 commit\n - fetch set_head: fix non-mirror remotes in bare repositories\n\n Fetching into a bare repository incorrectly assumed it always used\n a mirror layout when deciding to update remote-tracking HEAD, which\n has been corrected.\n\n Needs review.\n source: <20250112165125.130400-1-bence@ferdinandy.com>\n\n\n* mh/doc-credential-helpers-with-pat (2025-01-10) 2 commits\n (merged to 'next' on 2025-01-17 at a70beabaf5)\n + docs: discuss caching personal access tokens\n + docs: list popular credential helpers\n\n Document that it is insecure to use Personal Access Tokens, which\n some hosting providers take as username/password, embedded in URLs.\n\n Will merge to 'master'.\n source: \n\n\n* ps/build-meson-fixes (2025-01-14) 12 commits\n - ci: wire up Visual Studio build with Meson\n - ci: raise error when Meson generates warnings\n - meson: fix compilation with Visual Studio\n - meson: make the CSPRNG backend configurable\n - meson: wire up fuzzers\n - meson: wire up generation of distribution archive\n - meson: wire up development environments\n - meson: fix dependencies for generated headers\n - meson: populate project version via GIT-VERSION-GEN\n - GIT-VERSION-GEN: allow running without input and output files\n - GIT-VERSION-GEN: simplify computing the dirty marker\n - Merge branch 'ps/meson-weak-sha1-build' into ps/build-meson-fixes\n (this branch is used by ps/zlib-ng.)\n\n More build fixes and enhancements on meson based build procedure.\n\n Needs review.\n source: <20250114-b4-pks-meson-additions-v2-0-8d7ec676cfd9@pks.im>\n\n\n* ps/zlib-ng (2025-01-16) 12 commits\n - ci: make \"linux-musl\" job use zlib-ng\n - ci: switch linux-musl to use Meson\n - compat/zlib: allow use of zlib-ng as backend\n - git-zlib: cast away potential constness of `next_in` pointer\n - compat/zlib: provide stubs for `deflateSetHeader()`\n - compat/zlib: provide `deflateBound()` shim centrally\n - git-compat-util: move include of \"compat/zlib.h\" into \"git-zlib.h\"\n - compat: introduce new \"zlib.h\" header\n - git-compat-util: drop `z_const` define\n - compat: drop `uncompress2()` compatibility shim\n - Merge branch 'ps/build-meson-fixes' into ps/zlib-ng\n - Merge branch 'ps/meson-weak-sha1-build' into ps/zlib-ng\n (this branch uses ps/build-meson-fixes.)\n\n The code paths to interact with zlib has been cleaned up in\n preparation for building with zlib-ng.\n\n Needs review.\n source: <20250116-b4-pks-compat-drop-uncompress2-v3-0-f2af1f5c4a06@pks.im>\n\n\n* rs/ref-fitler-used-atoms-value-fix (2025-01-13) 1 commit\n - ref-filter: share bases and is_base_tips between formatting and sorting\n\n \"git branch --sort=...\" and \"git for-each-ref --format=... --sort=...\"\n did not work as expected with some atoms, which has been corrected.\n\n cf. https://lore.kernel.org/git/20250113051700.GA767856@coredump.intra.peff.net/\n source: <6b824f05-6f16-4cd9-85b7-3b8b236158b4@web.de>\n\n\n* tb/unsafe-hash-cleanup (2025-01-17) 8 commits\n - hash.h: drop unsafe_ function variants\n - csum-file: introduce hashfile_checkpoint_init()\n - t/helper/test-hash.c: use unsafe_hash_algo()\n - csum-file.c: use unsafe_hash_algo()\n - hash.h: introduce `unsafe_hash_algo()`\n - csum-file.c: extract algop from hashfile_checksum_valid()\n - csum-file: store the hash algorithm as a struct field\n - t/helper/test-tool: implement sha1-unsafe helper\n\n The API around choosing to use unsafe variant of SHA-1\n implementation has been updated in an attempt to make it harder to\n abuse.\n\n Will merge to 'next'?\n source: \n\n\n* dk/zsh-config-completion-fix (2025-01-06) 1 commit\n (merged to 'next' on 2025-01-10 at efba7d534c)\n + completion: repair config completion for Zsh\n\n Completion script updates for zsh\n\n Will merge to 'master'.\n source: \n\n\n* en/object-name-with-funny-refname-fix (2025-01-13) 2 commits\n (merged to 'next' on 2025-01-16 at 89cd7778c9)\n + object-name: be more strict in parsing describe-like output\n + object-name: fix resolution of object names containing curly braces\n\n Extended SHA-1 expression parser did not work well when a branch\n with an unusual name (e.g. \"foo{bar\") is involved.\n\n Will merge to 'master'.\n source: \n\n\n* sj/ref-consistency-checks-more (2025-01-06) 10 commits\n - builtin/fsck: add `git refs verify` child process\n - packed-backend: check whether the \"packed-refs\" is sorted\n - packed-backend: add check for object consistency\n - packed-backend: create \"fsck_packed_ref_entry\" to store parsing info\n - packed-backend: add \"packed-refs\" entry consistency check\n - packed-backend: check whether the refname contains NULL binaries\n - packed-backend: add \"packed-refs\" header consistency check\n - packed-backend: check whether the \"packed-refs\" is regular\n - builtin/refs.h: get worktrees without reading head info\n - files-backend: add object check for regular ref\n\n \"git fsck\" becomes more careful when checking the refs.\n source: \n\n\n* jk/lsan-race-ignore-false-positive (2025-01-07) 3 commits\n (merged to 'next' on 2025-01-09 at 3d7cd910b5)\n + test-lib: add a few comments to LSan log checking\n + test-lib: simplify lsan results check\n + test-lib: invert return value of check_test_results_san_file_empty\n\n The code to check LSan results has been simplified and made more\n robust.\n\n Will merge to 'master'.\n source: <20250107070409.GA584456@coredump.intra.peff.net>\n\n\n* jk/t7407-use-test-grep (2025-01-07) 1 commit\n (merged to 'next' on 2025-01-09 at 1d584ee42d)\n + t7407: use test_grep\n\n Test clean-up.\n\n Will merge to 'master'.\n source: <20250107071824.GA594237@coredump.intra.peff.net>\n\n\n* jt/fsck-skiplist-parse-fix (2025-01-07) 1 commit\n (merged to 'next' on 2025-01-09 at d08b30fd78)\n + fsck: reject misconfigured fsck.skipList\n\n A misconfigured \"fsck.skiplist\" configuration variable was not\n diagnosed as an error, which has been corrected.\n\n Will merge to 'master'.\n source: <20250107162914.3756968-2-jltobler@gmail.com>\n\n\n* ps/reftable-get-random-fix (2025-01-07) 2 commits\n (merged to 'next' on 2025-01-09 at bc024b7a45)\n + reftable/stack: accept insecure random bytes\n + wrapper: allow generating insecure random bytes\n\n The code to compute \"unique\" name used git_rand() which can fail or\n get stuck; the callsite does not require cryptographic security.\n Introduce the \"insecure\" mode and use it appropriately.\n\n Will merge to 'master'.\n source: <20250107-b4-pks-reftable-csprng-v1-0-6109a54a8756@pks.im>\n\n\n* mh/credential-cache-authtype-request-fix (2025-01-09) 1 commit\n - credential-cache: respect authtype capability\n\n The \"cache\" credential back-end did not handle authtype correctly,\n which has been corrected.\n source: \n\n\n* mh/gitattr-doc-markup-fix (2025-01-07) 1 commit\n (merged to 'next' on 2025-01-10 at 9b8f84ebe2)\n + docs: fix typesetting of merge driver placeholders\n\n Doc markup fix.\n\n Will merge to 'master'.\n source: <20250107212421.7yyvuzw4uqxnqv7t@archP14s>\n\n\n* sk/unit-test-hash (2025-01-09) 1 commit\n (merged to 'next' on 2025-01-13 at 865b121824)\n + t/unit-tests: convert hash to use clar test framework\n\n Test update.\n\n Will merge to 'master'.\n source: <20250109140952.5267-1-kuforiji98@gmail.com>\n\n\n* aj/difftool-config-doc-fix (2025-01-09) 1 commit\n (merged to 'next' on 2025-01-10 at b8902a53d1)\n + difftool docs: restore correct position of tool list\n\n Docfix.\n\n Will merge to 'master'.\n source: \n\n\n* jk/combine-diff-cleanup (2025-01-09) 14 commits\n - tree-diff: make list tail-passing more explicit\n - tree-diff: simplify emit_path() list management\n - tree-diff: use the name \"tail\" to refer to list tail\n - tree-diff: drop list-tail argument to diff_tree_paths()\n - combine-diff: drop public declaration of combine_diff_path_size()\n - tree-diff: inline path_appendnew()\n - tree-diff: pass whole path string to path_appendnew()\n - tree-diff: drop path_appendnew() alloc optimization\n - run_diff_files(): de-mystify the size of combine_diff_path struct\n - diff: add a comment about combine_diff_path.parent.path\n - combine-diff: use pointer for parent paths\n - tree-diff: clear parent array in path_appendnew()\n - combine-diff: add combine_diff_path_new()\n - run_diff_files(): delay allocation of combine_diff_path\n\n Code clean-up for code paths around combined diff.\n source: <20250109082723.GA2748497@coredump.intra.peff.net>\n\n\n* sc/help-autocorrect-one (2025-01-13) 1 commit\n - help: interpret boolean string values for help.autocorrect\n\n \"[help] autocorrect = 1\" used to be a way to say \"please wait for\n 0.1 second after suggesting a typofix of the command name before\n running that command\"; now it means \"yes, if there is a plausible\n typofix for the command name, please run it immediately\".\n\n Looking good except for \"should 0 and false be 'tell it without doing it'?\".\n source: \n\n\n* ja/doc-notes-markup-updates (2025-01-10) 1 commit\n - doc: convert git-notes to new documentation format\n\n Doc mark-up updates.\n source: \n\n\n* ja/doc-restore-markup-update (2025-01-10) 1 commit\n - doc: convert git-restore to new style format\n\n Doc mark-up updates.\n source: \n\n\n* ua/os-version-capability (2025-01-17) 6 commits\n . version: introduce osversion.command config for os-version output\n . connect: advertise OS version\n . t5701: add setup test to remove side-effect dependency\n . version: extend get_uname_info() to hide system details\n . version: refactor get_uname_info()\n . version: refactor redact_non_printables()\n\n The value of \"uname -s\" is by default sent over the wire as a new\n capability, with an opt-out for privacy-concious folks.\n\n source: <20250117104639.65608-1-usmanakinyemi202@gmail.com>\n\n\n* ja/doc-commit-markup-updates (2025-01-15) 5 commits\n - doc: migrate git-commit manpage secondary files to new format\n - doc: convert git commit config to new format\n - doc: make more direct explanations in git commit options\n - doc: the mode param of -u of git commit is optional\n - doc: apply new documentation guidelines to git commit\n\n Doc updates.\n\n Will merge to 'next'?\n source: \n\n\n* ps/ci-misc-updates (2025-01-10) 10 commits\n - ci: remove stale code for Azure Pipelines\n - ci: use latest Ubuntu release\n - ci: stop special-casing for Ubuntu 16.04\n - gitlab-ci: add linux32 job testing against i386\n - gitlab-ci: remove the \"linux-old\" job\n - github: simplify computation of the job's distro\n - github: convert all Linux jobs to be containerized\n - github: adapt containerized jobs to be rootless\n - t7422: fix flaky test caused by buffered stdout\n - t0060: fix EBUSY in MinGW when setting up runtime prefix\n\n CI updates (containerization, dropping stale ones, etc.).\n source: <20250110-b4-pks-ci-fixes-v4-0-6e4613446080@pks.im>\n\n\n* sk/strlen-returns-size_t (2024-12-26) 1 commit\n - date.c: Fix type missmatch warings from msvc\n\n Code clean-up.\n\n The remainder needs to be reviewed.\n source: <20241223110407.3308-3-soekkle@freenet.de>\n\n\n* sk/maintenance-remote-prune (2025-01-03) 1 commit\n - maintenance: add prune-remote-refs task\n\n A new periodic maintenance task to run \"git remote prune\" has been\n introduced.\n\n Expecting a reroll.\n source: \n\n\n* jc/show-index-h-update (2024-12-20) 1 commit\n - show-index: the short help should say the command reads from its input\n\n Doc and short-help text for \"show-index\" has been clarified to\n stress that the command reads its data from the standard input.\n\n Comments?\n source: \n\n\n* ps/the-repository (2024-12-18) 15 commits\n (merged to 'next' on 2025-01-09 at 1de40edade)\n + match-trees: stop using `the_repository`\n + graph: stop using `the_repository`\n + add-interactive: stop using `the_repository`\n + tmp-objdir: stop using `the_repository`\n + resolve-undo: stop using `the_repository`\n + credential: stop using `the_repository`\n + mailinfo: stop using `the_repository`\n + diagnose: stop using `the_repository`\n + server-info: stop using `the_repository`\n + send-pack: stop using `the_repository`\n + serve: stop using `the_repository`\n + trace: stop using `the_repository`\n + pager: stop using `the_repository`\n + progress: stop using `the_repository`\n + Merge branch 'ps/build-sign-compare' into ps/the-repository\n\n More code paths have a repository passed through the callchain,\n instead of assuming the primary the_repository object.\n\n Will merge to 'master'.\n source: <20241217-pks-use-the-repository-conversion-v1-0-0dba48bcc239@pks.im>\n\n\n* jc/doc-attr-tree (2024-12-14) 1 commit\n - doc: give attr.tree a bit more visibility\n\n Make sure that \"git --attr-source=X\", GIT_ATTR_SOURCE, and\n attr.tree configuration variables appear at the same places in the\n documentation.\n\n On hold.\n cf. <20241216111112.GA2201417@coredump.intra.peff.net>\n source: \n\n\n* ps/3.0-remote-deprecation (2025-01-06) 6 commits\n - remote: announce removal of \"branches/\" and \"remotes/\"\n - builtin/pack-redundant: remove subcommand with breaking changes\n - ci: repurpose \"linux-gcc\" job for deprecations\n - ci: merge linux-gcc-default into linux-gcc\n - Makefile: wire up build option for deprecated features\n - Merge branch 'ps/build' into ps/3.0-remote-deprecation\n\n Following the procedure we established to introduce breaking\n changes for Git 3.0, allow an early opt-in for removing support of\n $GIT_DIR/branches/ and $GIT_DIR/remotes/ directories to configure\n remotes.\n source: <20250106-pks-remote-branches-deprecation-v2-0-2ce87c053536@pks.im>\n\n\n* cc/lop-remote (2024-12-07) 5 commits\n . doc: add technical design doc for large object promisors\n . promisor-remote: check advertised name or URL\n . Add 'promisor-remote' capability to protocol v2\n . strbuf: refactor strbuf_trim_trailing_ch()\n . version: refactor strbuf_sanitize()\n\n Expecting a reroll.\n cf. \n source: <20241206124248.160494-1-christian.couder@gmail.com>\n\n\n* ds/backfill (2024-12-20) 6 commits\n - backfill: assume --sparse when sparse-checkout is enabled\n - backfill: add --sparse option\n - backfill: add --min-batch-size= option\n - backfill: basic functionality and tests\n - backfill: add builtin boilerplate\n - Merge branch 'ds/path-walk-1' into ds/backfill\n (this branch uses ds/path-walk-1.)\n\n Lazy-loading missing files in a blobless clone on demand is costly\n as it tends to be one-blob-at-a-time. \"git backfill\" is introduced\n to help bulk-download necessary files beforehand.\n\n Expecting a reroll.\n cf. \n source: \n\n\n* tb/incremental-midx-part-2 (2024-11-20) 15 commits\n - midx: implement writing incremental MIDX bitmaps\n - pack-bitmap.c: use `ewah_or_iterator` for type bitmap iterators\n - pack-bitmap.c: keep track of each layer's type bitmaps\n - ewah: implement `struct ewah_or_iterator`\n - pack-bitmap.c: apply pseudo-merge commits with incremental MIDXs\n - pack-bitmap.c: compute disk-usage with incremental MIDXs\n - pack-bitmap.c: teach `rev-list --test-bitmap` about incremental MIDXs\n - pack-bitmap.c: support bitmap pack-reuse with incremental MIDXs\n - pack-bitmap.c: teach `show_objects_for_type()` about incremental MIDXs\n - pack-bitmap.c: teach `bitmap_for_commit()` about incremental MIDXs\n - pack-bitmap.c: open and store incremental bitmap layers\n - pack-revindex: prepare for incremental MIDX bitmaps\n - Documentation: describe incremental MIDX bitmaps\n - Merge branch 'tb/pseudo-merge-bitmap-fixes' into tb/incremental-midx-part-2\n - Merge branch 'tb/incremental-midx-part-1' into tb/incremental-midx-part-2\n\n Incrementally updating multi-pack index files.\n\n Needs review.\n source: \n\n\n* ps/send-pack-unhide-error-in-atomic-push (2024-11-14) 2 commits\n - transport: don't ignore git-receive-pack(1) exit code on atomic push\n - t5504: modernize test by moving heredocs into test bodies\n\n \"git push --atomic --porcelain\" used to ignore failures from the\n other side, losing the error status from the child process, which\n has been corrected.\n\n Needs to see if competing parallel topic needs to replace this one.\n source: <20241113-pks-push-atomic-respect-exit-code-v1-0-7965f01e7f4e@pks.im>\n\n\n* ds/name-hash-tweaks (2024-12-20) 8 commits\n - pack-objects: add third name hash version\n - pack-objects: prevent name hash version change\n - test-tool: add helper for name-hash values\n - p5313: add size comparison test\n - pack-objects: add GIT_TEST_NAME_HASH_VERSION\n - repack: add --name-hash-version option\n - pack-objects: add --name-hash-version option\n - pack-objects: create new name-hash function version\n\n \"git pack-objects\" and its wrapper \"git repack\" learned an option\n to use an alternative path-hash function to improve delta-base\n selection to produce a packfile with deeper history than window\n size.\n\n Comments?\n source: \n\n\n* ds/path-walk-1 (2024-12-20) 7 commits\n - path-walk: reorder object visits\n - path-walk: mark trees and blobs as UNINTERESTING\n - path-walk: visit tags and cached objects\n - path-walk: allow consumer to specify object types\n - t6601: add helper for testing path-walk API\n - test-lib-functions: add test_cmp_sorted\n - path-walk: introduce an object walk by path\n (this branch is used by ds/backfill.)\n\n Introduce a new API to visit objects in batches based on a common\n path, or by type.\n\n Will merge to 'next'?\n cf. \n source: \n\n\n* ej/cat-file-remote-object-info (2025-01-14) 8 commits\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 - fetch-pack: move fetch initialization\n - fetch-pack: refactor packet writing\n - t1006: split test utility functions into new \"lib-cat-file.sh\"\n - cat-file: add declaration of variable i inside its for loop\n - git-compat-util: add strtoul_ul() with error handling\n\n \"git cat-file --batch\" and friends can optionally ask a remote\n server about objects it does not have.\n\n Comments?\n source: <20250114021502.41499-1-eric.peijian@gmail.com>\n\n\n* jc/move-is-bare-repository-cfg-variable-to-repo (2024-11-07) 3 commits\n . repository: BUG when is_bare_cfg is not initialized\n . setup: initialize is_bare_cfg\n . git: remove is_bare_repository_cfg global variable\n\n Code rewrite to turn the is_bare_repository_cfg global variable\n into a member in the the_repo singleton repository object.\n\n Will discard.\n Has been in \"Waiting for response to reviews\" state for too long.\n cf. \n Seems to break t0021-conversion on Windows.\n cf. https://lore.kernel.org/git/xmqqzfl1hl52.fsf@gitster.g/\n source: \n"},{"id":"510872","messageId":"20250118131507.GA387197@coredump.intra.peff.net","threadId":"62823","inReplyTo":"xmqqwmetgdgm.fsf@gitster.g","subject":"Re: What's cooking in git.git (Jan 2025, #05; Fri, 17)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2025-01-18T13:15:07Z","receivedAt":"2025-01-18T13:15:09Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Jan 17, 2025 at 04:42:01PM -0800, Junio C Hamano wrote:\n\n> * jk/pack-header-parse-alignment-fix (2025-01-17) 3 commits\n> - index-pack, unpack-objects: use skip_prefix to avoid magic number\n> - parse_pack_header_option(): avoid unaligned memory writes\n> - packfile: factor out --pack_header argument parsing\n> \n> It was possible for \"git unpack-objects\" and \"git index-pack\" to\n> make an unaligned access, which has been corrected.\n> \n> Will merge to 'next'.\n> source: <20250117125207.GB2356599@coredump.intra.peff.net>\n\nI was planning to re-roll this with your sparse fix included, and adding\nanother patch to do get_be32() on the reading side. So maybe hold off\nfor a moment.\n\n(I'd also be interested in any comments on the \"maybe we should just\nalign these buffers\" approach; I'm undecided on it).\n\n-Peff\n"},{"id":"510880","messageId":"xmqq34hg3utv.fsf@gitster.g","threadId":"62823","inReplyTo":"20250118131507.GA387197@coredump.intra.peff.net","subject":"Re: What's cooking in git.git (Jan 2025, #05; Fri, 17)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-01-18T17:17:32Z","receivedAt":"2025-01-18T17:17:35Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> On Fri, Jan 17, 2025 at 04:42:01PM -0800, Junio C Hamano wrote:\n>\n>> * jk/pack-header-parse-alignment-fix (2025-01-17) 3 commits\n>> ...\n>> Will merge to 'next'.\n>> source: <20250117125207.GB2356599@coredump.intra.peff.net>\n>\n> I was planning to re-roll this with your sparse fix included, and adding\n> another patch to do get_be32() on the reading side. So maybe hold off\n> for a moment.\n\nThanks.\n\n> (I'd also be interested in any comments on the \"maybe we should just\n> align these buffers\" approach; I'm undecided on it).\n\nUnless we have the buffer _inside_ the helper function that may\nperform the possibly-unaligned access, I am not sure how it helps.\n\nI guess that we can align buffers used by two existing callers,\ndocument that the helper function takes an aligned buffer and that\nit is a fault of the caller if somebody passes an unaligned buffer,\nbut I am not sure if that is where we want to go.\n"},{"id":"510902","messageId":"20250119125146.GB1538605@coredump.intra.peff.net","threadId":"62823","inReplyTo":"xmqq34hg3utv.fsf@gitster.g","subject":"Re: What's cooking in git.git (Jan 2025, #05; Fri, 17)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2025-01-19T12:51:46Z","receivedAt":"2025-01-19T12:51:47Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Jan 18, 2025 at 09:17:32AM -0800, Junio C Hamano wrote:\n\n> > (I'd also be interested in any comments on the \"maybe we should just\n> > align these buffers\" approach; I'm undecided on it).\n> \n> Unless we have the buffer _inside_ the helper function that may\n> perform the possibly-unaligned access, I am not sure how it helps.\n\nWe sort-of do. The offending code is all static local to\nunpack-objects.c, and always operates on the same buffer (directly for\nwriting, and for reading through the static fill() macro which returns\nit directly). And likewise in index-pack.c.\n\nI think these two are oddballs in that they read parts of a pack into a\nbuffer. Whereas all of the more generic pack code will mmap() it, and\npresumably that ends up with suitable alignment. I guess platforms with\nNO_MMAP would read into a malloc'd buffer, but that should likewise be\nprepared for any alignment. (I suppose another way of achieving\nalignment would simply be to turn \"buffer\" into a pointer and malloc it\nat the program start, but that still leaves the need to fix sizeof()\ncalls).\n\n> I guess that we can align buffers used by two existing callers,\n> document that the helper function takes an aligned buffer and that\n> it is a fault of the caller if somebody passes an unaligned buffer,\n> but I am not sure if that is where we want to go.\n\nThe functions themselves aren't really reusable, so any new code which\nwants to do the same thing would end up rewriting it and potentially\ncreating the same problem. But that's probably an argument for switching\naway from the cast and to put/get_be32(). It provides a more obviously\nbetter example for people to copy from.\n\nI'll post a re-roll in a bit.\n\n-Peff\n"},{"id":"510903","messageId":"20250119125526.GA1540196@coredump.intra.peff.net","threadId":"62823","inReplyTo":"20250119125146.GB1538605@coredump.intra.peff.net","subject":"Re: What's cooking in git.git (Jan 2025, #05; Fri, 17)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2025-01-19T12:55:26Z","receivedAt":"2025-01-19T12:55:28Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Jan 19, 2025 at 07:51:46AM -0500, Jeff King wrote:\n\n> > Unless we have the buffer _inside_ the helper function that may\n> > perform the possibly-unaligned access, I am not sure how it helps.\n> \n> We sort-of do. The offending code is all static local to\n> unpack-objects.c, and always operates on the same buffer (directly for\n> writing, and for reading through the static fill() macro which returns\n> it directly). And likewise in index-pack.c.\n\nOh, reading this again, I guess you were thinking of the helper that I\nhad factored out. Yes, if that requires aligned memory that is an awful\ninterface. :-/\n\nI was thinking to just leave the offending code untouched in the\nindividual commands if we went this route.\n\nBut anyway, I'll prepare a version going the other get_be32() direction.\n\n-Peff\n"},{"id":"510923","messageId":"Z43y0mNhHsEdF22L@gmail.com","threadId":"62823","inReplyTo":"xmqqwmetgdgm.fsf@gitster.g","subject":"Re: What's cooking in git.git (Jan 2025, #05; Fri, 17)","fromName":"David Aguilar","fromEmail":"davvid@gmail.com","sentAt":"2025-01-20T06:53:06Z","receivedAt":"2025-01-20T06:53:11Z","isPatch":false,"sender":{"key":"davvid@gmail.com","avatar":"https://avatars.githubusercontent.com/u/13196?v=4"},"body":"On Fri, Jan 17, 2025 at 04:42:01PM -0800, Junio C Hamano wrote:\n> * sc/help-autocorrect-one (2025-01-13) 1 commit\n> - help: interpret boolean string values for help.autocorrect\n> \n> \"[help] autocorrect = 1\" used to be a way to say \"please wait for\n> 0.1 second after suggesting a typofix of the command name before\n> running that command\"; now it means \"yes, if there is a plausible\n> typofix for the command name, please run it immediately\".\n> \n> Looking good except for \"should 0 and false be 'tell it without doing it'?\".\n> source: \n\n(The text below is from the original thread; sorry I don't have it handy\nso I just replied here instead)\n\n> ... but would it be simpler if we made it an extended boolean, i.e.\n> \n> true, yes, on, 1 -> same as \"immediate\"\n> false, no, off, 0 -> same as \"never\"\n> immediate -> same as what we currently do\n> never -> same as what we currently do\n> prompt -> same as what we currently do\n> number -> same as what we currently do\n\nI do think that, \"0 -> same as never,\" makes a lot of sense from a\nusability perspective.\n\nOn the other hand, I don't think that, \"1 -> same as immediate,\" is a\nvery safe thing to do. One reason is that we should try to do the least\nsurprising thing possible, especially when the command may be something\nthat the user did not intend to run.\n\nRecall that this topic was spun up because a value of \"1\" was\ninterpreted as 0.1 seconds, which is effectively the same as\n\"immediate.\" The original interpretation is arguably a usability issue\nthat is not improved by these changes.\n\nI would instead recommend that, \"1 -> same as prompt,\" would be a safer\nand less surprising behavior. If the user wants \"immediate\" they can be\nexplicit about it. \"immediate\" is the most dangerous of all of these\noptions so adding ambiguous routes to it seems like a step backwards.\n\nI don't really think backwards-compatibility is much of a concern here\nat all. It *would* be a concern if we were moving from a safe behavior\nto a less-safe behavior (like this patch currently does) but not so in\nthe other direction like I'm proposing by making \"1\" mean \"prompt\".\n\nDo we think this is a valid assessment and worth changing?\nIf so I can try to whip up a quick patch over the existing state of\n\"seen\" to change the behavior to \"prompt\" when \"1\" is seen and\n\"never\" when \"0\" is seen.\n-- \nDavid\n"},{"id":"510931","messageId":"20250120075452.137992-1-davvid@gmail.com","threadId":"62823","inReplyTo":"Z43y0mNhHsEdF22L@gmail.com","subject":"[PATCH] help: make help.autocorrect = 1 the same as \"prompt\"","fromName":"David Aguilar","fromEmail":"davvid@gmail.com","sentAt":"2025-01-20T07:54:52Z","receivedAt":"2025-01-20T07:54:55Z","isPatch":true,"sender":{"key":"davvid@gmail.com","avatar":"https://avatars.githubusercontent.com/u/13196?v=4"},"body":"Choose the least surprising behavior by prompting the user\nwhen when help.autocorrect is set to a boolean \"true\" value.\n\nMake \"0\" and other \"false\" boolean values the same as \"never\".\n\nMake \"help.autocorrect = show\" the same as the default behavior\nso that users can override it in a repository-local .git/config.\n\nSigned-off-by: David Aguilar \n---\nHere's what the proposed changes to make \"true\" = \"prompt\"\nmight look like.\n\n Documentation/config/help.txt | 26 ++++++++++++++++--------\n help.c | 14 +++++++++----\n t/t9003-help-autocorrect.sh | 38 +++++++++++++++++------------------\n 3 files changed, 47 insertions(+), 31 deletions(-)\n\ndiff --git a/Documentation/config/help.txt b/Documentation/config/help.txt\nindex a4c6079af8..344b4b13f7 100644\n--- a/Documentation/config/help.txt\n+++ b/Documentation/config/help.txt\n@@ -11,14 +11,24 @@ help.autoCorrect::\n \tIf git detects typos and can identify exactly one valid command similar\n \tto the error, git will try to suggest the correct command or even\n \trun the suggestion automatically. Possible config values are:\n-\t - 0: show the suggested command (default).\n-\t - 1, \"true\", \"on\", \"yes\", \"immediate\": run the suggested command\n-immediately.\n-\t - positive number > 1: run the suggested command after specified\n-deciseconds (0.1 sec).\n-\t - \"false\", \"off\", \"no\", \"never\": don't run or show any suggested command.\n-\t - \"prompt\": show the suggestion and prompt for confirmation to run\n-the command.\n++\n+--\n+show;;\n+\tShow the suggested command but do not run it. This is the default.\n+\n+immediate;;\n+\tRun the suggested command immediately.\n+\n+never, false, off, no, 0;;\n+\tDo not run or show the suggested command.\n+\n+prompt, true, on, yes, 1;;\n+\tShow the suggestion and prompt for confirmation to run the command.\n+\n+positive number greater than 1;;\n+\tRun the suggested command after specified deciseconds (0.1 sec).\n+--\n++\n \n help.htmlPath::\n \tSpecify the path where the HTML documentation resides. File system paths\ndiff --git a/help.c b/help.c\nindex 7148963e46..447e0c9423 100644\n--- a/help.c\n+++ b/help.c\n@@ -552,6 +552,7 @@ struct help_unknown_cmd_config {\n \tstruct cmdnames aliases;\n };\n \n+#define AUTOCORRECT_SHOW (-4)\n #define AUTOCORRECT_PROMPT (-3)\n #define AUTOCORRECT_NEVER (-2)\n #define AUTOCORRECT_IMMEDIATELY (-1)\n@@ -560,7 +561,7 @@ static int parse_autocorrect(const char *value)\n {\n \tswitch (git_parse_maybe_bool_text(value)) {\n \t\tcase 1:\n-\t\t\treturn AUTOCORRECT_IMMEDIATELY;\n+\t\t\treturn AUTOCORRECT_PROMPT;\n \t\tcase 0:\n \t\t\treturn AUTOCORRECT_NEVER;\n \t\tdefault: /* other random text */\n@@ -573,6 +574,8 @@ static int parse_autocorrect(const char *value)\n \t\treturn AUTOCORRECT_NEVER;\n \tif (!strcmp(value, \"immediate\"))\n \t\treturn AUTOCORRECT_IMMEDIATELY;\n+\tif (!strcmp(value, \"show\"))\n+\t\treturn AUTOCORRECT_SHOW;\n \n \treturn 0;\n }\n@@ -589,8 +592,10 @@ static int git_unknown_cmd_config(const char *var, const char *value,\n \n \t\tif (!v) {\n \t\t\tv = git_config_int(var, value, ctx->kvi);\n-\t\t\tif (v < 0 || v == 1)\n-\t\t\t\tv = AUTOCORRECT_IMMEDIATELY;\n+\t\t\tif (v == 1)\n+\t\t\t\tv = AUTOCORRECT_PROMPT;\n+\t\t\telse if (v <= 0)\n+\t\t\t\tv = AUTOCORRECT_NEVER;\n \t\t}\n \n \t\tcfg->autocorrect = v;\n@@ -713,7 +718,8 @@ char *help_unknown_cmd(const char *cmd)\n \t\t n++)\n \t\t\t; /* still counting */\n \t}\n-\tif (cfg.autocorrect && n == 1 && SIMILAR_ENOUGH(best_similarity)) {\n+\tif (cfg.autocorrect && cfg.autocorrect != AUTOCORRECT_SHOW &&\n+\t n == 1 && SIMILAR_ENOUGH(best_similarity)) {\n \t\tchar *assumed = xstrdup(main_cmds.names[0]->name);\n \n \t\tfprintf_ln(stderr,\ndiff --git a/t/t9003-help-autocorrect.sh b/t/t9003-help-autocorrect.sh\nindex 85a5074b5e..ea20526248 100755\n--- a/t/t9003-help-autocorrect.sh\n+++ b/t/t9003-help-autocorrect.sh\n@@ -29,7 +29,7 @@ test_expect_success 'setup' '\n '\n \n test_expect_success 'autocorrect showing candidates' '\n-\tgit config help.autocorrect 0 &&\n+\tgit config help.autocorrect show &&\n \n \ttest_must_fail git lfg 2>actual &&\n \tgrep \"^\tlgf\" actual &&\n@@ -38,28 +38,28 @@ test_expect_success 'autocorrect showing candidates' '\n \tgrep \"^\tdistimdistim\" actual\n '\n \n-for immediate in -1 immediate\n-do\n-\ttest_expect_success 'autocorrect running commands' '\n-\t\tgit config help.autocorrect $immediate &&\n+test_expect_success 'autocorrect running commands' '\n+\tgit config help.autocorrect immediate &&\n \n-\t\tgit lfg >actual &&\n-\t\techo \"a single log entry\" >expect &&\n-\t\ttest_cmp expect actual &&\n+\tgit lfg >actual &&\n+\techo \"a single log entry\" >expect &&\n+\ttest_cmp expect actual &&\n \n-\t\tgit distimdist >actual &&\n-\t\techo \"distimdistim was called\" >expect &&\n-\t\ttest_cmp expect actual\n-\t'\n-done\n+\tgit distimdist >actual &&\n+\techo \"distimdistim was called\" >expect &&\n+\ttest_cmp expect actual\n+'\n \n-test_expect_success 'autocorrect can be declined altogether' '\n-\tgit config help.autocorrect never &&\n+for never in -1 0 no false never\n+do\n+\ttest_expect_success 'autocorrect can be declined altogether' '\n+\t\tgit config help.autocorrect $never &&\n \n-\ttest_must_fail git lfg 2>actual &&\n-\tgrep \"is not a git command\" actual &&\n-\ttest_line_count = 1 actual\n-'\n+\t\ttest_must_fail git lfg 2>actual &&\n+\t\tgrep \"is not a git command\" actual &&\n+\t\ttest_line_count = 1 actual\n+\t'\n+done\n \n test_expect_success 'autocorrect works in work tree created from bare repo' '\n \tgit clone --bare . bare.git &&\n-- \n2.48.0.rc2.33.gfa4adeb460\n\n"},{"id":"511011","messageId":"xmqqfrlc0yem.fsf@gitster.g","threadId":"62823","inReplyTo":"20250119125526.GA1540196@coredump.intra.peff.net","subject":"Re: What's cooking in git.git (Jan 2025, #05; Fri, 17)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-01-21T19:17:37Z","receivedAt":"2025-01-21T19:17:39Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> I was thinking to just leave the offending code untouched in the\n> individual commands if we went this route.\n\nAh, I see. Yeah, then we have a subtle and possibly brittle code\npaths that are well contained inside two functions.\n\n> But anyway, I'll prepare a version going the other get_be32() direction.\n\nThanks. That probably results in better code with fewer magic.\n\nTHanks.\n"},{"id":"511012","messageId":"xmqq5xm80y53.fsf@gitster.g","threadId":"62823","inReplyTo":"Z43y0mNhHsEdF22L@gmail.com","subject":"Re: What's cooking in git.git (Jan 2025, #05; Fri, 17)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-01-21T19:23:20Z","receivedAt":"2025-01-21T19:23:23Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"David Aguilar writes:\n\n> (The text below is from the original thread; sorry I don't have it handy\n> so I just replied here instead)\n>\n>> ... but would it be simpler if we made it an extended boolean, i.e.\n>> \n>> true, yes, on, 1 -> same as \"immediate\"\n>> false, no, off, 0 -> same as \"never\"\n>> immediate -> same as what we currently do\n>> never -> same as what we currently do\n>> prompt -> same as what we currently do\n>> number -> same as what we currently do\n>\n> I do think that, \"0 -> same as never,\" makes a lot of sense from a\n> usability perspective.\n\nI obviously do not agree. \"Suggest the right spelling and let the\nuser decide without time-bomb\" is a very useful and safe UI, and the\nabove summary was done by mistake.\n\n> I would instead recommend that, \"1 -> same as prompt,\" would be a safer\n> and less surprising behavior. If the user wants \"immediate\" they can be\n> explicit about it. \"immediate\" is the most dangerous of all of these\n> options so adding ambiguous routes to it seems like a step backwards.\n\nThanks for raising your concern.\n\nAs somebody who does *not* use the time-bomb UI that makes me wait\nwhen the heuristics guessed correctly and forces me to scramble to\nhit \\C-c when it didn't, I am not qualified to comment in favor of\nsuch a huge behaviour change, so I won't, and let others discuss.\n\n> I don't really think backwards-compatibility is much of a concern here\n> at all. It *would* be a concern if we were moving from a safe behavior\n> to a less-safe behavior (like this patch currently does) but not so in\n> the other direction like I'm proposing by making \"1\" mean \"prompt\".\n"},{"id":"511015","messageId":"1331d214-890e-4b47-87c6-44f445172bb2@gmail.com","threadId":"62823","inReplyTo":"xmqqwmetgdgm.fsf@gitster.g","subject":"Re: What's cooking in git.git (Jan 2025, #05; Fri, 17)","fromName":"Derrick Stolee","fromEmail":"stolee@gmail.com","sentAt":"2025-01-21T20:19:26Z","receivedAt":"2025-01-21T20:19:28Z","isPatch":false,"sender":{"key":"stolee@gmail.com","avatar":"https://avatars.githubusercontent.com/u/570044?v=4"},"body":"On 1/17/25 7:42 PM, Junio C Hamano wrote:\n\n> * ds/name-hash-tweaks (2024-12-20) 8 commits\n> - pack-objects: add third name hash version\n> - pack-objects: prevent name hash version change\n> - test-tool: add helper for name-hash values\n> - p5313: add size comparison test\n> - pack-objects: add GIT_TEST_NAME_HASH_VERSION\n> - repack: add --name-hash-version option\n> - pack-objects: add --name-hash-version option\n> - pack-objects: create new name-hash function version\n> \n> \"git pack-objects\" and its wrapper \"git repack\" learned an option\n> to use an alternative path-hash function to improve delta-base\n> selection to produce a packfile with deeper history than window\n> size.\n> \n> Comments?\n> source: \n\nI'll poke the thread, too, but this seems to be the most promising\ntopic in the area of better delta compression. The latest version\ndoes not have any comments.\n\nThe only decision point I think remains is whether or not to\ninclude the last patch (--name-hash-version=3) which I would be\nhappy either way.\n\nThanks,\n-Stolee\n\n"},{"id":"511017","messageId":"xmqqv7u7zz8v.fsf@gitster.g","threadId":"62823","inReplyTo":"1331d214-890e-4b47-87c6-44f445172bb2@gmail.com","subject":"Re: What's cooking in git.git (Jan 2025, #05; Fri, 17)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-01-21T20:30:08Z","receivedAt":"2025-01-21T20:30:10Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Derrick Stolee writes:\n\n> On 1/17/25 7:42 PM, Junio C Hamano wrote:\n>\n>> * ds/name-hash-tweaks (2024-12-20) 8 commits\n>> - pack-objects: add third name hash version\n>> - pack-objects: prevent name hash version change\n>> - test-tool: add helper for name-hash values\n>> - p5313: add size comparison test\n>> - pack-objects: add GIT_TEST_NAME_HASH_VERSION\n>> - repack: add --name-hash-version option\n>> - pack-objects: add --name-hash-version option\n>> - pack-objects: create new name-hash function version\n>> \"git pack-objects\" and its wrapper \"git repack\" learned an option\n>> to use an alternative path-hash function to improve delta-base\n>> selection to produce a packfile with deeper history than window\n>> size.\n>> Comments?\n>> source: \n>\n> I'll poke the thread, too, but this seems to be the most promising\n> topic in the area of better delta compression. The latest version\n> does not have any comments.\n>\n> The only decision point I think remains is whether or not to\n> include the last patch (--name-hash-version=3) which I would be\n> happy either way.\n\nI am happy with the updated function that gives us better of both\nworlds, without losing too much from the \"renamed from other\ndirectory\" while making sure we do not lose too many bits in deeper\ntrees.\n\nThanks.\n"},{"id":"511073","messageId":"CAOLa=ZSyEg8G9g1B78VRymgfk9eo=d3KkhD=+S14_BSqaAO2Mg@mail.gmail.com","threadId":"62823","inReplyTo":"xmqqwmetgdgm.fsf@gitster.g","subject":"Re: What's cooking in git.git (Jan 2025, #05; Fri, 17)","fromName":"Karthik Nayak","fromEmail":"karthik.188@gmail.com","sentAt":"2025-01-22T16:44:13Z","receivedAt":"2025-01-22T16:44:15Z","isPatch":false,"sender":{"key":"karthik.188@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1786334?v=4"},"body":"Junio C Hamano writes:\n\n> * kn/reflog-migration-fix (2025-01-15) 1 commit\n> (merged to 'next' on 2025-01-16 at ae8f9ce9a0)\n> + reftable: write correct max_update_index to header\n> (this branch is used by kn/reflog-migration-fix-followup.)\n>\n> \"git refs migrate\" for migrating reflog data was broken.\n>\n> Will merge to 'master'.\n> cf. \n> source: \n\nThis seems to be breaking on 'next'. I tested it locally with\n\n GIT_TEST_DEFAULT_REF_FORMAT=reftable meson test -v --test-args='-i'\nt1400-update-ref\n\nmy local tests were made on files backend, and it didn't trigger on the\nCI either for some reason (I shall investigate that soon). But dscho\n(CC'd) reported that macos builds for reftable were failing [1] for his\nbranch and I could bisect it to this.\n\nI'm yet to understand why this fails and also why the CI didn't notify\nof the issue. But that is something I shall do next. For now we need to\nremove it from next.\n\n[1]: https://github.com/dscho/git/actions/runs/12906424058/job/35987723223\n"},{"id":"511075","messageId":"CAOLa=ZT4nws0irdZKUuWc70Rv9RUNQuSXnGAt1SnE1O+umSReg@mail.gmail.com","threadId":"62823","inReplyTo":"CAOLa=ZSyEg8G9g1B78VRymgfk9eo=d3KkhD=+S14_BSqaAO2Mg@mail.gmail.com","subject":"Re: What's cooking in git.git (Jan 2025, #05; Fri, 17)","fromName":"Karthik Nayak","fromEmail":"karthik.188@gmail.com","sentAt":"2025-01-22T17:28:40Z","receivedAt":"2025-01-22T17:28:41Z","isPatch":false,"sender":{"key":"karthik.188@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1786334?v=4"},"body":"Karthik Nayak writes:\n\n> Junio C Hamano writes:\n>\n>> * kn/reflog-migration-fix (2025-01-15) 1 commit\n>> (merged to 'next' on 2025-01-16 at ae8f9ce9a0)\n>> + reftable: write correct max_update_index to header\n>> (this branch is used by kn/reflog-migration-fix-followup.)\n>>\n>> \"git refs migrate\" for migrating reflog data was broken.\n>>\n>> Will merge to 'master'.\n>> cf. \n>> source: \n>\n> This seems to be breaking on 'next'. I tested it locally with\n>\n> GIT_TEST_DEFAULT_REF_FORMAT=reftable meson test -v --test-args='-i' t1400-update-ref\n>\n> my local tests were made on files backend, and it didn't trigger on the\n> CI either for some reason (I shall investigate that soon). But dscho\n> (CC'd) reported that macos builds for reftable were failing [1] for his\n> branch and I could bisect it to this.\n>\n> I'm yet to understand why this fails and also why the CI didn't notify\n> of the issue. But that is something I shall do next. For now we need to\n> remove it from next.\n>\n> [1]: https://github.com/dscho/git/actions/runs/12906424058/job/35987723223\n\nThis is reproducible when the leak sanitizier is enabled and tested\nagainst reftable:\n\nSo setting up meson with:\n CC=clang meson setup --reconfigure -Db_sanitize=address,undefined build\nand running the test in the build folder with:\n GIT_TEST_DEFAULT_REF_FORMAT=reftable meson test -v\n--test-args='-ixd' t1400-update-ref\n\nreproduces the issue. I haven't found the root cause yet, but will\nmostly call it a day and get back to this tomorrow.\n\nKarthik\n"},{"id":"511076","messageId":"xmqqa5biyciu.fsf@gitster.g","threadId":"62823","inReplyTo":"CAOLa=ZT4nws0irdZKUuWc70Rv9RUNQuSXnGAt1SnE1O+umSReg@mail.gmail.com","subject":"Re: What's cooking in git.git (Jan 2025, #05; Fri, 17)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-01-22T17:38:33Z","receivedAt":"2025-01-22T17:38:36Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Karthik Nayak writes:\n\n> Karthik Nayak writes:\n>\n>> Junio C Hamano writes:\n>>\n>>> * kn/reflog-migration-fix (2025-01-15) 1 commit\n>>> (merged to 'next' on 2025-01-16 at ae8f9ce9a0)\n>>> + reftable: write correct max_update_index to header\n>>> (this branch is used by kn/reflog-migration-fix-followup.)\n>>>\n>>> \"git refs migrate\" for migrating reflog data was broken.\n>>>\n>>> Will merge to 'master'.\n>>> cf. \n>>> source: \n>>\n>> This seems to be breaking on 'next'. I tested it locally with\n>>\n>> GIT_TEST_DEFAULT_REF_FORMAT=reftable meson test -v --test-args='-i' t1400-update-ref\n>>\n>> my local tests were made on files backend, and it didn't trigger on the\n>> CI either for some reason (I shall investigate that soon). But dscho\n>> (CC'd) reported that macos builds for reftable were failing [1] for his\n>> branch and I could bisect it to this.\n>>\n>> I'm yet to understand why this fails and also why the CI didn't notify\n>> of the issue. But that is something I shall do next. For now we need to\n>> remove it from next.\n>>\n>> [1]: https://github.com/dscho/git/actions/runs/12906424058/job/35987723223\n>\n> This is reproducible when the leak sanitizier is enabled and tested\n> against reftable:\n>\n> So setting up meson with:\n> CC=clang meson setup --reconfigure -Db_sanitize=address,undefined build\n> and running the test in the build folder with:\n> GIT_TEST_DEFAULT_REF_FORMAT=reftable meson test -v\n> --test-args='-ixd' t1400-update-ref\n>\n> reproduces the issue. I haven't found the root cause yet, but will\n> mostly call it a day and get back to this tomorrow.\n\nThanks. I'll mark the topic as on-hold.\n\n"},{"id":"511084","messageId":"Z5E5KdbwHE7fmiJx@nand.local","threadId":"62823","inReplyTo":"xmqqv7u7zz8v.fsf@gitster.g","subject":"Re: What's cooking in git.git (Jan 2025, #05; Fri, 17)","fromName":"Taylor Blau","fromEmail":"me@ttaylorr.com","sentAt":"2025-01-22T18:30:01Z","receivedAt":"2025-01-22T18:30:04Z","isPatch":false,"sender":{"key":"me@ttaylorr.com","avatar":"https://avatars.githubusercontent.com/u/301000140?v=4"},"body":"On Tue, Jan 21, 2025 at 12:30:08PM -0800, Junio C Hamano wrote:\n> Derrick Stolee writes:\n>\n> > On 1/17/25 7:42 PM, Junio C Hamano wrote:\n> >\n> >> * ds/name-hash-tweaks (2024-12-20) 8 commits\n> >> - pack-objects: add third name hash version\n> >> - pack-objects: prevent name hash version change\n> >> - test-tool: add helper for name-hash values\n> >> - p5313: add size comparison test\n> >> - pack-objects: add GIT_TEST_NAME_HASH_VERSION\n> >> - repack: add --name-hash-version option\n> >> - pack-objects: add --name-hash-version option\n> >> - pack-objects: create new name-hash function version\n> >> \"git pack-objects\" and its wrapper \"git repack\" learned an option\n> >> to use an alternative path-hash function to improve delta-base\n> >> selection to produce a packfile with deeper history than window\n> >> size.\n> >> Comments?\n> >> source: \n> >\n> > I'll poke the thread, too, but this seems to be the most promising\n> > topic in the area of better delta compression. The latest version\n> > does not have any comments.\n> >\n> > The only decision point I think remains is whether or not to\n> > include the last patch (--name-hash-version=3) which I would be\n> > happy either way.\n>\n> I am happy with the updated function that gives us better of both\n> worlds, without losing too much from the \"renamed from other\n> directory\" while making sure we do not lose too many bits in deeper\n> trees.\n\nI had a couple of thoughts that I meant to share before the holiday\nbreak, and haven't quite had a chance to get to it now that I'm back at\nmy desk.\n\nLet me try and find some time to respond to the latest round of this\nseries, and apologies for holding it up in the meantime.\n\nThanks,\nTaylor\n"},{"id":"511091","messageId":"xmqqh65qv6oc.fsf@gitster.g","threadId":"62823","inReplyTo":"Z5E5KdbwHE7fmiJx@nand.local","subject":"Re: What's cooking in git.git (Jan 2025, #05; Fri, 17)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-01-22T22:13:07Z","receivedAt":"2025-01-22T22:13:10Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Taylor Blau writes:\n\n> On Tue, Jan 21, 2025 at 12:30:08PM -0800, Junio C Hamano wrote:\n>> Derrick Stolee writes:\n>>\n>> > On 1/17/25 7:42 PM, Junio C Hamano wrote:\n>> >\n>> >> * ds/name-hash-tweaks (2024-12-20) 8 commits\n>> ...\n>> I am happy with the updated function that gives us better of both\n>> worlds, without losing too much from the \"renamed from other\n>> directory\" while making sure we do not lose too many bits in deeper\n>> trees.\n>\n> I had a couple of thoughts that I meant to share before the holiday\n> break, and haven't quite had a chance to get to it now that I'm back at\n> my desk.\n>\n> Let me try and find some time to respond to the latest round of this\n> series, and apologies for holding it up in the meantime.\n\nThe topic has been stalled for unusually long time, so it won't hurt\ntoo much for it to wait for a few more days, but it wouldn't be fair\nto stall a topic further with just a promise to \"try and find time\"\nforever. Let's say we'll go ahead by this weekend unless we hear\notherwise?\n\nI am not ultra-happy with the last step, as I personally do not see\nthis different algorithm as \"version\" (in that people would always\nwant to use version N+1 over version N when both are available) but\nas \"variant\" (in that there may be prefer to use variant N over\nvariant N+1 depending on the circumstances), but that may be just\nthe matter of terminology. What's important is to make sure we do\nnot mix two algorhtims up while creating a packfile.\n\nThanks.\n"},{"id":"511112","messageId":"xmqqldv1tpgp.fsf@gitster.g","threadId":"62823","inReplyTo":"CAOLa=ZT4nws0irdZKUuWc70Rv9RUNQuSXnGAt1SnE1O+umSReg@mail.gmail.com","subject":"Re: What's cooking in git.git (Jan 2025, #05; Fri, 17)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-01-23T17:22:30Z","receivedAt":"2025-01-23T17:22:33Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Karthik Nayak writes:\n\n> Karthik Nayak writes:\n>\n>> Junio C Hamano writes:\n>>\n>>> * kn/reflog-migration-fix (2025-01-15) 1 commit\n>>> (merged to 'next' on 2025-01-16 at ae8f9ce9a0)\n>>> + reftable: write correct max_update_index to header\n>>> (this branch is used by kn/reflog-migration-fix-followup.)\n>>> ...\n>> This seems to be breaking on 'next'.\n> ...\n> reproduces the issue. I haven't found the root cause yet, but will\n> mostly call it a day and get back to this tomorrow.\n\nWe have a handful of topics related to refs subsystem in flight,\nand I am a bit lost here.\n\n(1) kn/reflog-migration-fix (the above) was done as a \"fix\" for the\n issue reported by brian in\n https://lore.kernel.org/all/Z4UbkcmJAU1MT-Rs@tapette.crustytoothpaste.net/ \n\n(2) You mention that (1) is broken in the message I am responding\n to. There is no known fix yet, so (1) needs to wait in 'next'\n until it gets fixed.\n\n(3) kn/reflog-migration-fix-followup is a code clean-up for (1); it\n has to wait for (2) as well.\n\n(4) kn/reflog-symref-fix is a fix for a different bug the commit\n that introduced the bug (1) addresses. It can proceed\n independently from the other topics.\n\n(5) ps/reflog-migration-with-logall-fix is another fix for a\n different bug introduced by the same series whose bugs are\n addressed by (1) and (4). It can proceed independently from the\n other topics.\n\nThe above is my current understanding; did I miss any other relevant\ntopics that are related to these efforts, and/or did I misunderstand\nthe dependencies among them?\n\nIf I am not misunderstanding the current status of these topics,\nI'll be marking (4) and (5) for 'next'; I am undecided for (3).\n\nThanks.\n\n"},{"id":"511124","messageId":"Z5KAUo4FeG2M1mIa@pks.im","threadId":"62823","inReplyTo":"xmqqldv1tpgp.fsf@gitster.g","subject":"Re: What's cooking in git.git (Jan 2025, #05; Fri, 17)","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2025-01-23T17:45:54Z","receivedAt":"2025-01-23T17:46:01Z","isPatch":false,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"On Thu, Jan 23, 2025 at 09:22:30AM -0800, Junio C Hamano wrote:\n> Karthik Nayak writes:\n> \n> > Karthik Nayak writes:\n> >\n> >> Junio C Hamano writes:\n> >>\n> >>> * kn/reflog-migration-fix (2025-01-15) 1 commit\n> >>> (merged to 'next' on 2025-01-16 at ae8f9ce9a0)\n> >>> + reftable: write correct max_update_index to header\n> >>> (this branch is used by kn/reflog-migration-fix-followup.)\n> >>> ...\n> >> This seems to be breaking on 'next'.\n> > ...\n> > reproduces the issue. I haven't found the root cause yet, but will\n> > mostly call it a day and get back to this tomorrow.\n> \n> We have a handful of topics related to refs subsystem in flight,\n> and I am a bit lost here.\n> \n> (1) kn/reflog-migration-fix (the above) was done as a \"fix\" for the\n> issue reported by brian in\n> https://lore.kernel.org/all/Z4UbkcmJAU1MT-Rs@tapette.crustytoothpaste.net/ \n> \n> (2) You mention that (1) is broken in the message I am responding\n> to. There is no known fix yet, so (1) needs to wait in 'next'\n> until it gets fixed.\n> \n> (3) kn/reflog-migration-fix-followup is a code clean-up for (1); it\n> has to wait for (2) as well.\n> \n> (4) kn/reflog-symref-fix is a fix for a different bug the commit\n> that introduced the bug (1) addresses. It can proceed\n> independently from the other topics.\n> \n> (5) ps/reflog-migration-with-logall-fix is another fix for a\n> different bug introduced by the same series whose bugs are\n> addressed by (1) and (4). It can proceed independently from the\n> other topics.\n> \n> The above is my current understanding; did I miss any other relevant\n> topics that are related to these efforts, and/or did I misunderstand\n> the dependencies among them?\n> \n> If I am not misunderstanding the current status of these topics,\n> I'll be marking (4) and (5) for 'next'; I am undecided for (3).\n\nKarthik has meanwhile sent a v2 [1] of the broken patch in (1) that\nfixes the issue discovered in (2). Given that (1) has already been in\nnext, (2) probably needs to be rerolled to be a patch on top of what we\nalready have in next.\n\nOther than that yes, I think (4) and (5) can be merged independently of\n(1) to (3).\n\nPatrick\n\n[1]: <20250123135613.748916-1-karthik.188@gmail.com>\n"},{"id":"511129","messageId":"xmqq1pwts7z1.fsf@gitster.g","threadId":"62823","inReplyTo":"Z5KAUo4FeG2M1mIa@pks.im","subject":"Re: What's cooking in git.git (Jan 2025, #05; Fri, 17)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-01-23T18:25:38Z","receivedAt":"2025-01-23T18:25:41Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Patrick Steinhardt writes:\n\n> Karthik has meanwhile sent a v2 [1] of the broken patch in (1) that\n> fixes the issue discovered in (2). Given that (1) has already been in\n> next, (2) probably needs to be rerolled to be a patch on top of what we\n> already have in next.\n>\n> Other than that yes, I think (4) and (5) can be merged independently of\n> (1) to (3).\n\nThanks for sanity checking me.\n"},{"id":"511136","messageId":"Z5LLNMKSa6Y2zvHK@nand.local","threadId":"62823","inReplyTo":"xmqqh65qv6oc.fsf@gitster.g","subject":"Re: What's cooking in git.git (Jan 2025, #05; Fri, 17)","fromName":"Taylor Blau","fromEmail":"me@ttaylorr.com","sentAt":"2025-01-23T23:05:24Z","receivedAt":"2025-01-23T23:05:37Z","isPatch":false,"sender":{"key":"me@ttaylorr.com","avatar":"https://avatars.githubusercontent.com/u/301000140?v=4"},"body":"On Wed, Jan 22, 2025 at 02:13:07PM -0800, Junio C Hamano wrote:\n> Taylor Blau writes:\n>\n> > On Tue, Jan 21, 2025 at 12:30:08PM -0800, Junio C Hamano wrote:\n> >> Derrick Stolee writes:\n> >>\n> >> > On 1/17/25 7:42 PM, Junio C Hamano wrote:\n> >> >\n> >> >> * ds/name-hash-tweaks (2024-12-20) 8 commits\n> >> ...\n> >> I am happy with the updated function that gives us better of both\n> >> worlds, without losing too much from the \"renamed from other\n> >> directory\" while making sure we do not lose too many bits in deeper\n> >> trees.\n> >\n> > I had a couple of thoughts that I meant to share before the holiday\n> > break, and haven't quite had a chance to get to it now that I'm back at\n> > my desk.\n> >\n> > Let me try and find some time to respond to the latest round of this\n> > series, and apologies for holding it up in the meantime.\n>\n> The topic has been stalled for unusually long time, so it won't hurt\n> too much for it to wait for a few more days, but it wouldn't be fair\n> to stall a topic further with just a promise to \"try and find time\"\n> forever. Let's say we'll go ahead by this weekend unless we hear\n> otherwise?\n\nI agree, and I apologize for the delay. I prioritized this yesterday and\nleft some review which I think you have seen since sending this email.\n\n> I am not ultra-happy with the last step, as I personally do not see\n> this different algorithm as \"version\" (in that people would always\n> want to use version N+1 over version N when both are available) but\n> as \"variant\" (in that there may be prefer to use variant N over\n> variant N+1 depending on the circumstances), but that may be just\n> the matter of terminology. What's important is to make sure we do\n> not mix two algorhtims up while creating a packfile.\n\nYeah, I think \"variant\" is probably more accurate, but I don't mind the\nnaming. I think having a unique identifier is important, but I am not\nconvinced that we need to introduce v2 and v3 at the same time. I would\nrather see us unify behind a single approach to present a\nclearer/smaller set of options to users.\n\nThanks,\nTaylor\n"},{"id":"511137","messageId":"xmqqmsfhqekm.fsf@gitster.g","threadId":"62823","inReplyTo":"Z5LLNMKSa6Y2zvHK@nand.local","subject":"Re: What's cooking in git.git (Jan 2025, #05; Fri, 17)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-01-23T23:46:01Z","receivedAt":"2025-01-23T23:46:04Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Taylor Blau writes:\n\n> Yeah, I think \"variant\" is probably more accurate, but I don't mind the\n> naming. I think having a unique identifier is important, but I am not\n> convinced that we need to introduce v2 and v3 at the same time. I would\n> rather see us unify behind a single approach to present a\n> clearer/smaller set of options to users.\n\nI agree with you that v2 is superiour most of the time over v1 and\nv3. If we keep v3, then \"version\" is an awkward phrasing to use.\nSome people with specialized needs may use \"v3\" while most people\nwho do nnot have to use \"v1\" are better off using \"v2\" not \"v3\".\n\nIf we were to drop v3, then \"version\" starts to make sense again, as\n\"v1\" is kept primarily for backward compatibility, and those who can\nafford to follow the latest can \"upgrade\" to \"v2\".\n\nPerhaps we can first agree to drop the last step from the series,\nkeep calling these \"versions\", and then later add \"v3\" when we come\nup with an algorithm that would perform better than \"v2\" in almost\nall cases? I dunno.\n\nThanks.\n\n"},{"id":"511155","messageId":"CAOLa=ZSotvEPgOyU0FnZBpNwnpjhBk4-PXk5rc=cQZuToUmVDw@mail.gmail.com","threadId":"62823","inReplyTo":"Z5KAUo4FeG2M1mIa@pks.im","subject":"Re: What's cooking in git.git (Jan 2025, #05; Fri, 17)","fromName":"Karthik Nayak","fromEmail":"karthik.188@gmail.com","sentAt":"2025-01-24T11:05:59Z","receivedAt":"2025-01-24T11:06:00Z","isPatch":false,"sender":{"key":"karthik.188@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1786334?v=4"},"body":"Patrick Steinhardt writes:\n\n> On Thu, Jan 23, 2025 at 09:22:30AM -0800, Junio C Hamano wrote:\n>> Karthik Nayak writes:\n>>\n>> > Karthik Nayak writes:\n>> >\n>> >> Junio C Hamano writes:\n>> >>\n>> >>> * kn/reflog-migration-fix (2025-01-15) 1 commit\n>> >>> (merged to 'next' on 2025-01-16 at ae8f9ce9a0)\n>> >>> + reftable: write correct max_update_index to header\n>> >>> (this branch is used by kn/reflog-migration-fix-followup.)\n>> >>> ...\n>> >> This seems to be breaking on 'next'.\n>> > ...\n>> > reproduces the issue. I haven't found the root cause yet, but will\n>> > mostly call it a day and get back to this tomorrow.\n>>\n>> We have a handful of topics related to refs subsystem in flight,\n>> and I am a bit lost here.\n>>\n>> (1) kn/reflog-migration-fix (the above) was done as a \"fix\" for the\n>> issue reported by brian in\n>> https://lore.kernel.org/all/Z4UbkcmJAU1MT-Rs@tapette.crustytoothpaste.net/\n>>\n>> (2) You mention that (1) is broken in the message I am responding\n>> to. There is no known fix yet, so (1) needs to wait in 'next'\n>> until it gets fixed.\n>>\n>> (3) kn/reflog-migration-fix-followup is a code clean-up for (1); it\n>> has to wait for (2) as well.\n>>\n>> (4) kn/reflog-symref-fix is a fix for a different bug the commit\n>> that introduced the bug (1) addresses. It can proceed\n>> independently from the other topics.\n>>\n>> (5) ps/reflog-migration-with-logall-fix is another fix for a\n>> different bug introduced by the same series whose bugs are\n>> addressed by (1) and (4). It can proceed independently from the\n>> other topics.\n>>\n>> The above is my current understanding; did I miss any other relevant\n>> topics that are related to these efforts, and/or did I misunderstand\n>> the dependencies among them?\n>>\n>> If I am not misunderstanding the current status of these topics,\n>> I'll be marking (4) and (5) for 'next'; I am undecided for (3).\n>\n> Karthik has meanwhile sent a v2 [1] of the broken patch in (1) that\n> fixes the issue discovered in (2). Given that (1) has already been in\n> next, (2) probably needs to be rerolled to be a patch on top of what we\n> already have in next.\n>\n> Other than that yes, I think (4) and (5) can be merged independently of\n> (1) to (3).\n>\n> Patrick\n>\n> [1]: <20250123135613.748916-1-karthik.188@gmail.com>\n\nThis seems right, just providing another set of eyes here.\n\nThanks!\n"},{"id":"511178","messageId":"xmqqa5bg16qs.fsf@gitster.g","threadId":"62823","inReplyTo":"CAOLa=ZSotvEPgOyU0FnZBpNwnpjhBk4-PXk5rc=cQZuToUmVDw@mail.gmail.com","subject":"Re: What's cooking in git.git (Jan 2025, #05; Fri, 17)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-01-24T17:06:35Z","receivedAt":"2025-01-24T17:06:37Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Karthik Nayak writes:\n\n\n> This seems right, just providing another set of eyes here.\n\nThanks for helping me out.\n"}]}