{"thread":{"id":"58142","subject":"What's cooking in git.git (Jul 2022, #03; Mon, 11)","startedAt":"2022-07-12T17:07:56Z","lastAt":"2022-08-17T01:38:04Z","messageCount":17,"participants":["Junio C Hamano","Glen Choo","Philip Oakley","Taylor Blau","Johannes Schindelin","Ævar Arnfjörð Bjarmason"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"458904","messageId":"xmqqo7xufee7.fsf@gitster.g","threadId":"58142","inReplyTo":null,"subject":"What's cooking in git.git (Jul 2022, #03; Mon, 11)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-07-12T17:07:44Z","receivedAt":"2022-07-12T17:07:56Z","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',\nand aren't considered \"accepted\" at all.\n\nMaintenance releases v2.37.1 and others have been tagged. They are\nto address CVE-2022-29187, a vulnerability related to CVE-2022-24765\nthat was fixed earlier. Big thanks to Carlo Arenas and Johannes\nSchindelin for fixing the issue and helping the releases out.\n\nCopies of the source code to Git live in many repositories, and the\nfollowing is a list of the ones I push into or their mirrors. Some\nrepositories have only a subset of branches.\n\nWith maint, master, next, seen, todo:\n\n\tgit://git.kernel.org/pub/scm/git/git.git/\n\tgit://repo.or.cz/alt-git.git/\n\thttps://kernel.googlesource.com/pub/scm/git/git/\n\thttps://github.com/git/git/\n\thttps://gitlab.com/git-vcs/git/\n\nWith all the integration branches and topics broken out:\n\n\thttps://github.com/gitster/git/\n\nEven though the preformatted documentation in HTML and man format\nare not sources, they are published in these repositories for\nconvenience (replace \"htmldocs\" with \"manpages\" for the manual\npages):\n\n\tgit://git.kernel.org/pub/scm/git/git-htmldocs.git/\n\thttps://github.com/gitster/git-htmldocs.git/\n\nRelease tarballs are available at:\n\n\thttps://www.kernel.org/pub/software/scm/git/\n\n--------------------------------------------------\n[Graduated to 'master']\n\n* ac/bitmap-format-doc (2022-06-16) 3 commits\n (merged to 'next' on 2022-06-16 at 5591d11601)\n + bitmap-format.txt: add information for trailing checksum\n + bitmap-format.txt: fix some formatting issues\n + bitmap-format.txt: feed the file to asciidoc to generate html\n\n Adjust technical/bitmap-format to be formatted by AsciiDoc, and\n add some missing information to the documentation.\n source: \n\n\n* cr/setup-bug-typo (2022-06-17) 1 commit\n (merged to 'next' on 2022-06-17 at 8834ffe0ab)\n + setup: fix function name in a BUG() message\n\n Typofix in a BUG() message.\n source: \n\n\n* ds/branch-checked-out (2022-06-21) 7 commits\n (merged to 'next' on 2022-06-21 at e42bc4566f)\n + branch: drop unused worktrees variable\n + fetch: stop passing around unused worktrees variable\n (merged to 'next' on 2022-06-17 at c881874257)\n + branch: fix branch_checked_out() leaks\n + branch: use branch_checked_out() when deleting refs\n + fetch: use new branch_checked_out() and add tests\n + branch: check for bisects and rebases\n + branch: add branch_checked_out() helper\n (this branch is used by ds/rebase-update-ref.)\n\n Introduce a helper to see if a branch is already being worked on\n (hence should not be newly checked out in a working tree), which\n performs much better than the existing find_shared_symref() to\n replace many uses of the latter.\n source: \n\n\n* ds/vscode-settings (2022-06-27) 1 commit\n (merged to 'next' on 2022-07-02 at fcbd2e7aca)\n + vscode: improve tab size and wrapping\n\n Will merge to 'master'.\n source: \n\n\n* jk/optim-promisor-object-enumeration (2022-06-16) 1 commit\n (merged to 'next' on 2022-06-16 at ce0712a74c)\n + is_promisor_object(): walk promisor packs in pack-order\n\n Collection of what is referenced by objects in promisor packs have\n been optimized to inspect these objects in the in-pack order.\n source: \n\n\n* jk/revisions-doc-markup-fix (2022-06-22) 1 commit\n (merged to 'next' on 2022-07-02 at e25dbe8cfb)\n + revisions.txt: escape \"...\" to avoid asciidoc horizontal ellipsis\n\n Documentation mark-up fix.\n source: \n\n\n* pb/diff-doc-raw-format (2022-06-13) 3 commits\n (merged to 'next' on 2022-07-02 at 198480cbc6)\n + diff-index.txt: update raw output format in examples\n + diff-format.txt: correct misleading wording\n + diff-format.txt: dst can be 0* SHA-1 when path is deleted, too\n\n Update \"git diff/log --raw\" format documentation.\n source: \n\n\n* rs/archive-with-internal-gzip (2022-06-15) 6 commits\n (merged to 'next' on 2022-06-17 at ab5af6acd1)\n + archive-tar: use internal gzip by default\n + archive-tar: use OS_CODE 3 (Unix) for internal gzip\n + archive-tar: add internal gzip implementation\n + archive-tar: factor out write_block()\n + archive: rename archiver data field to filter_command\n + archive: update format documentation\n\n Teach \"git archive\" to (optionally and then by default) avoid\n spawning an external \"gzip\" process when creating \".tar.gz\" (and\n \".tgz\") archives.\n source: <9df761c3-355a-ede9-7971-b32687fe9abb@web.de>\n\n\n* rs/combine-diff-with-incompatible-options (2022-06-21) 2 commits\n (merged to 'next' on 2022-07-02 at 0fe8b80a3e)\n + combine-diff: abort if --output is given\n + combine-diff: abort if --ignore-matching-lines is given\n\n Certain diff options are currently ignored when combined-diff is\n shown; mark them as incompatible with the feature.\n source: <220524.86v8tuvfl1.gmgdl@evledraar.gmail.com>\n\n--------------------------------------------------\n[New Topics]\n\n* po/doc-add-renormalize (2022-07-09) 1 commit\n - doc add: renormalize is not idempotent for CRCRLF\n\n Documentation for \"git add --renormalize\" has been improved.\n\n Will merge to 'next'?\n source: \n\n\n* po/glossary-around-traversal (2022-07-09) 3 commits\n - glossary: add reachability bitmap description\n - glossary: add commit graph description\n - glossary: add Object DataBase (ODB) abbreviation\n\n The glossary entries for \"commit-graph file\" and \"reachability\n bitmap\" have been added.\n\n Will merge to 'next'?\n source: \n\n\n* rs/cocci-array-copy (2022-07-10) 1 commit\n - cocci: avoid normalization rules for memcpy\n\n A coccinelle rule (in contrib/) to encourage use of COPY_ARRAY\n macro has been improved.\n\n Will merge to 'next'.\n source: \n\n\n* sg/multi-pack-index-parse-options-fix (2022-07-10) 1 commit\n (merged to 'next' on 2022-07-11 at 1e14685680)\n + multi-pack-index: simplify handling of unknown --options\n\n The way \"git multi-pack\" uses parse-options API has been improved.\n\n Will merge to 'master'.\n source: <20220710151645.GA2038@szeder.dev>\n\n\n* jk/ref-filter-discard-commit-buffer (2022-07-11) 1 commit\n - ref-filter: disable save_commit_buffer while traversing\n\n source: \n\n--------------------------------------------------\n[Stalled]\n\n* ll/curl-accept-language (2022-07-11) 1 commit\n - remote-curl: send Accept-Language header to server\n\n Earlier, HTTP transport clients learned to tell the server side\n what locale they are in by sending Accept-Language HTTP header, but\n this was done only for some requests but not others.\n\n Will merge to 'next'.\n source: \n\n\n* bc/stash-export (2022-04-08) 4 commits\n - builtin/stash: provide a way to import stashes from a ref\n - builtin/stash: provide a way to export stashes to a ref\n - builtin/stash: factor out revision parsing into a function\n - object-name: make get_oid quietly return an error\n\n A mechanism to export and import stash entries to and from a normal\n commit to transfer it across repositories has been introduced.\n\n Expecting a reroll.\n cf. \n source: <20220407215352.3491567-1-sandals@crustytoothpaste.net>\n\n\n* cw/remote-object-info (2022-05-06) 11 commits\n - SQUASH??? coccicheck\n - SQUASH??? ensure that coccicheck is happy\n - SQUASH??? compilation fix\n - cat-file: add --batch-command remote-object-info command\n - cat-file: move parse_cmd and DEFAULT_FORMAT up\n - transport: add object-info fallback to fetch\n - transport: add client side capability to request object-info\n - object-info: send attribute packet regardless of object ids\n - object-store: add function to free object_info contents\n - fetch-pack: move fetch default settings\n - fetch-pack: refactor packet writing\n\n A client component to talk with the object-info endpoint.\n\n Expecting a reroll.\n source: <20220502170904.2770649-1-calvinwan@google.com>\n\n--------------------------------------------------\n[Cooking]\n\n* ab/cocci-unused (2022-07-06) 6 commits\n (merged to 'next' on 2022-07-11 at 7fa60d2a5b)\n + cocci: generalize \"unused\" rule to cover more than \"strbuf\"\n + cocci: add and apply a rule to find \"unused\" strbufs\n + cocci: have \"coccicheck{,-pending}\" depend on \"coccicheck-test\"\n + cocci: add a \"coccicheck-test\" target and test *.cocci rules\n + Makefile & .gitignore: ignore & clean \"git.res\", not \"*.res\"\n + Makefile: remove mandatory \"spatch\" arguments from SPATCH_FLAGS\n\n Add Coccinelle rules to detect the pattern of initializing and then\n finalizing a structure without using it in between at all, which\n happens after code restructuring and the compilers fail to\n recognize as an unused varilable.\n\n Will merge to 'master'.\n source: \n\n\n* jk/clone-unborn-confusion (2022-07-11) 4 commits\n - clone: move unborn head creation to update_head()\n - clone: use remote branch if it matches default HEAD\n - clone: propagate empty remote HEAD even with other branches\n - clone: drop extra newline from warning message\n\n \"git clone\" from a repository with some ref whose HEAD is unborn\n did not set the HEAD in the resulting repository correctly, which\n has been corrected.\n\n Will merge to 'next'.\n source: \n source: \n\n\n* ac/bitmap-lookup-table (2022-07-06) 6 commits\n - p5310-pack-bitmaps.sh: remove pack.writeReverseIndex\n - bitmap-lookup-table: add performance tests for lookup table\n - pack-bitmap: prepare to read lookup table extension\n - pack-bitmap-write: learn pack.writeBitmapLookupTable and add tests\n - pack-bitmap-write.c: write lookup table extension\n - Documentation/technical: describe bitmap lookup table extension\n\n The pack bitmap file gained a bitmap-lookup table to speed up\n locating the necessary bitmap for a given commit.\n\n Will merge to 'next'?\n source: \n\n\n* bc/nettle-sha256 (2022-07-10) 1 commit\n (merged to 'next' on 2022-07-11 at cf9595d8ca)\n + sha256: add support for Nettle\n\n Support for libnettle as SHA256 implementation has been added.\n\n Will merge to 'master'.\n source: <20220710132907.1499365-1-sandals@crustytoothpaste.net>\n\n\n* jc/builtin-mv-move-array (2022-07-09) 1 commit\n (merged to 'next' on 2022-07-09 at 0d3b3f62e5)\n + builtin/mv.c: use the MOVE_ARRAY() macro instead of memmove()\n\n Apply Coccinelle rule to turn raw memmove() into MOVE_ARRAY() cpp\n macro, which would improve maintainability and readability.\n\n Will merge to 'master'.\n source: \n\n\n* jd/gpg-interface-trust-level-string (2022-07-10) 1 commit\n (merged to 'next' on 2022-07-11 at 7b3cca73a8)\n + gpg-interface: add function for converting trust level to string\n\n The code to convert between GPG trust level strings and internal\n constants we use to represent them have been cleaned up.\n\n Will merge to 'master'.\n source: \n\n\n* kk/p4-client-name-encoding-fix (2022-07-08) 1 commit\n (merged to 'next' on 2022-07-11 at 9c18616f76)\n + git-p4: fix bug with encoding of p4 client name\n\n \"git p4\" did not handle non-ASCII client name well, which has been\n corrected.\n\n Will merge to 'master'.\n source: \n\n\n* sa/cat-file-mailmap (2022-07-09) 4 commits\n - cat-file: add mailmap support\n - ident: rename commit_rewrite_person() to apply_mailmap_to_header()\n - ident: move commit_rewrite_person() to ident.c\n - revision: improve commit_rewrite_person()\n\n \"git cat-file\" learned an option to use the mailmap when showing\n commit and tag objects.\n source: <20220709154149.165524-1-siddharthasthana31@gmail.com>\n\n\n* fr/vimdiff-layout-fix (2022-07-08) 1 commit\n (merged to 'next' on 2022-07-09 at d8461bd236)\n + vimdiff: make layout engine more robust against user vim settings\n\n Recent update to vimdiff layout code has been made more robust\n against different end-user vim settings.\n\n Will merge to 'master'.\n source: <20220708181024.45839-1-greenfoo@u92.eu>\n\n\n* ds/git-rebase-doc-markup (2022-06-30) 1 commit\n (merged to 'next' on 2022-07-08 at 24a0b80b71)\n + git-rebase.txt: use back-ticks consistently\n\n References to commands-to-be-typed-literally in \"git rebase\"\n documentation mark-up have been corrected.\n\n Will merge to 'master'.\n source: \n\n\n* ds/rebase-update-ref (2022-06-28) 8 commits\n - rebase: add rebase.updateRefs config option\n - rebase: update refs from 'update-ref' commands\n - rebase: add --update-refs option\n - sequencer: add update-ref command\n - sequencer: define array with enum values\n - rebase-interactive: update 'merge' description\n - branch: consider refs under 'update-refs'\n - t2407: test branches currently using apply backend\n\n \"git rebase -i\" learns to update branches whose tip appear in the\n rebased range.\n\n Expecting a reroll.\n cf. <15631ea2-6722-fd24-c8a6-0cee638b0602@github.com>\n source: \n\n\n* tb/pack-objects-remove-pahole-comment (2022-06-28) 1 commit\n (merged to 'next' on 2022-07-06 at d7494fbdef)\n + pack-objects.h: remove outdated pahole results\n\n Comment fix.\n\n Will merge to 'master'.\n source: <1379af2e9d271b501ef3942398e7f159a9c77973.1656440978.git.me@ttaylorr.com>\n\n\n* ab/leakfix (2022-07-01) 11 commits\n (merged to 'next' on 2022-07-11 at 0b107fffcf)\n + pull: fix a \"struct oid_array\" memory leak\n + cat-file: fix a common \"struct object_context\" memory leak\n + gc: fix a memory leak\n + checkout: avoid \"struct unpack_trees_options\" leak\n + merge-file: fix memory leaks on error path\n + merge-file: refactor for subsequent memory leak fix\n + cat-file: fix a memory leak in --batch-command mode\n + revert: free \"struct replay_opts\" members\n + submodule.c: free() memory from xgetcwd()\n + clone: fix memory leak in wanted_peer_refs()\n + check-ref-format: fix trivial memory leak\n\n Plug various memory leaks.\n\n Will merge to 'master'.\n source: \n\n\n* ab/test-tool-leakfix (2022-07-01) 9 commits\n (merged to 'next' on 2022-07-11 at db7a724694)\n + test-tool delta: fix a memory leak\n + test-tool ref-store: fix a memory leak\n + test-tool bloom: fix memory leaks\n + test-tool json-writer: fix memory leaks\n + test-tool regex: call regfree(), fix memory leaks\n + test-tool urlmatch-normalization: fix a memory leak\n + test-tool {dump,scrap}-cache-tree: fix memory leaks\n + test-tool path-utils: fix a memory leak\n + test-tool test-hash: fix a memory leak\n\n Plug various memory leaks in test-tool commands.\n\n Will merge to 'master'.\n source: \n\n\n* en/t6429-test-must-be-empty-fix (2022-06-30) 1 commit\n (merged to 'next' on 2022-07-06 at 627c51773c)\n + t6429: fix use of non-existent function\n\n A test fix.\n\n Will merge to 'master'.\n source: \n\n\n* gc/submodule-use-super-prefix (2022-06-30) 8 commits\n (merged to 'next' on 2022-07-11 at 0d9cf172f9)\n + submodule--helper: remove display path helper\n + submodule--helper update: use --super-prefix\n + submodule--helper: remove unused SUPPORT_SUPER_PREFIX flags\n + submodule--helper: use correct display path helper\n + submodule--helper: don't recreate recursive prefix\n + submodule--helper update: use display path helper\n + submodule--helper tests: add missing \"display path\" coverage\n + Merge branch 'ab/submodule-cleanup' into gc/submodule-use-super-prefix\n (this branch uses ab/submodule-cleanup.)\n\n Another step to rewrite more parts of \"git submodule\" in C.\n\n Will merge to 'master'.\n source: <20220701021157.88858-1-chooglen@google.com>\n\n\n* hx/lookup-commit-in-graph-fix (2022-06-30) 1 commit\n (merged to 'next' on 2022-07-08 at cef32db0b6)\n + commit-graph.c: no lazy fetch in lookup_commit_in_graph()\n\n A corner case bug where lazily fetching objects from a promisor\n remote resulted in infinite recursion has been corrected.\n\n Will merge to 'master'.\n source: <96d4bb71505d87ed501c058bbd89bfc13d08b24a.1656593279.git.hanxin.hx@bytedance.com>\n\n\n* ll/ls-files-tests-update (2022-07-06) 1 commit\n (merged to 'next' on 2022-07-06 at 444d1eabd0)\n + ls-files: update test style\n\n Test update.\n\n Will merge to 'master'.\n source: \n\n\n* pw/xdiff-alloc (2022-07-08) 4 commits\n - xdiff: introduce XDL_ALLOC_GROW()\n - xdiff: introduce XDL_CALLOC_ARRAY()\n - xdiff: introduce xdl_calloc\n - xdiff: introduce XDL_ALLOC_ARRAY()\n\n Add a level of redirection to array allocation API in xdiff part,\n to make it easier to share with the libgit2 project.\n\n Will merge to 'next'?\n source: \n\n\n* sy/mv-out-of-cone (2022-07-01) 8 commits\n (merged to 'next' on 2022-07-08 at 654970fdb7)\n + mv: add check_dir_in_index() and solve general dir check issue\n + mv: use flags mode for update_mode\n + mv: check if exists in index to handle overwriting\n + mv: check if out-of-cone file exists in index with SKIP_WORKTREE bit\n + mv: decouple if/else-if checks using goto\n + mv: update sparsity after moving from out-of-cone to in-cone\n + t1092: mv directory from out-of-cone to in-cone\n + t7002: add tests for moving out-of-cone file/directory\n\n \"git mv A B\" in a sparsely populated working tree can be asked to\n move a path between directories that are \"in cone\" (i.e. expected\n to be materialized in the working tree) and \"out of cone\"\n (i.e. expected to be hidden). The handling of such cases has been\n improved.\n\n Will merge to 'master'.\n source: <20220630023737.473690-1-shaoxuan.yuan02@gmail.com>\n\n\n* ab/squelch-empty-fsync-traces (2022-06-30) 1 commit\n . trace2: don't include \"fsync\" events in all trace2 logs\n\n Omit fsync-related trace2 entries when their values are all zero.\n\n Breaks tests in hx/unpack-streaming with an interesting interaction.\n source: \n\n\n* cl/grep-max-count (2022-06-22) 1 commit\n (merged to 'next' on 2022-07-08 at 646199ab4c)\n + grep: add --max-count command line option\n\n \"git grep -m\" is a way to limit the hits shown per file.\n\n Will merge to 'master'.\n source: \n\n\n* tk/rev-parse-doc-clarify-at-u (2022-06-23) 1 commit\n (merged to 'next' on 2022-07-08 at 1075452f32)\n + rev-parse: documentation adjustment - mention remote tracking with @{u}\n\n Doc update.\n\n Will merge to 'master'.\n source: \n\n\n* en/merge-tree (2022-06-22) 17 commits\n (merged to 'next' on 2022-07-08 at a29b4896ab)\n + git-merge-tree.txt: add a section on potentional usage mistakes\n + merge-tree: add a --allow-unrelated-histories flag\n + merge-tree: allow `ls-files -u` style info to be NUL terminated\n + merge-ort: optionally produce machine-readable output\n + merge-ort: store more specific conflict information\n + merge-ort: make `path_messages` a strmap to a string_list\n + merge-ort: store messages in a list, not in a single strbuf\n + merge-tree: provide easy access to `ls-files -u` style info\n + merge-tree: provide a list of which files have conflicts\n + merge-ort: remove command-line-centric submodule message from merge-ort\n + merge-ort: provide a merge_get_conflicted_files() helper function\n + merge-tree: support including merge messages in output\n + merge-ort: split out a separate display_update_messages() function\n + merge-tree: implement real merges\n + merge-tree: add option parsing and initial shell for real merge function\n + merge-tree: move logic for existing merge into new function\n + merge-tree: rename merge_trees() to trivial_merge_trees()\n\n A new command is introduced that takes two commits and computes a\n tree that would be contained in the resulting merge commit, if the\n histories leading to these two commits were to be merged, and is\n added as a new mode of \"git merge-tree\" subcommand.\n\n Will merge to 'master'.\n source: \n\n\n* dr/i18n-die-warn-error-usage (2022-06-21) 1 commit\n (merged to 'next' on 2022-07-08 at 6f639750a1)\n + i18n: mark message helpers prefix for translation\n\n Give _() markings to fatal/warning/usage: labels that are shown in\n front of these messages.\n\n Will merge to 'master'.\n source: \n\n\n* ds/t5510-brokequote (2022-06-21) 1 commit\n (merged to 'next' on 2022-07-06 at 2776bed385)\n + t5510: replace 'origin' with URL more carefully\n\n Test fix.\n\n Will merge to 'master'.\n source: <484a330e-0902-6e1b-8189-63c72dcea494@github.com>\n\n\n* en/merge-restore-to-pristine (2022-06-21) 6 commits\n - merge: do not exit restore_state() prematurely\n - merge: ensure we can actually restore pre-merge state\n - merge: make restore_state() restore staged state too\n - merge: fix save_state() to work when there are racy-dirty files\n - merge: remove unused variable\n - t6424: make sure a failed merge preserves local changes\n\n When \"git merge\" finds that it cannot perform a merge, it should\n restore the working tree to the state before the command was\n initiated, but in some corner cases it didn't.\n\n Needs review.\n source: \n\n\n* tk/apply-case-insensitive (2022-06-21) 3 commits\n - apply: support case-only renames in case-insensitive filesystems\n - reset: new failing test for reset of case-insensitive duplicate in index\n - t4141: test \"git apply\" with core.ignorecase\n\n \"git apply\" barfed on a patch that makes a case-only rename on a\n case-insensitive filesystem.\n\n Needs review.\n source: \n\n\n* zh/ls-files-format (2022-07-11) 1 commit\n - ls-files: introduce \"--format\" option\n\n \"git ls-files\" learns the \"--format\" option to tweak its output.\n\n Getting closer to finish?\n cf. \n source: \n\n\n* ab/test-quoting-fix (2022-06-30) 3 commits\n (merged to 'next' on 2022-07-06 at 0aa78fd9db)\n + config tests: fix harmless but broken \"rm -r\" cleanup\n + test-lib.sh: fix prepend_var() quoting issue\n + tests: add missing double quotes to included library paths\n\n Fixes for tests when the source directory has unusual characters in\n its path, e.g. whitespaces, double-quotes, etc.\n\n Will merge to 'master'.\n source: \n\n\n* en/merge-dual-dir-renames-fix (2022-07-06) 5 commits\n (merged to 'next' on 2022-07-11 at 5f8dadf87b)\n + merge-ort: fix issue with dual rename and add/add conflict\n + merge-ort: shuffle the computation and cleanup of potential collisions\n + merge-ort: make a separate function for freeing struct collisions\n + merge-ort: small cleanups of check_for_directory_rename\n + t6423: add tests of dual directory rename plus add/add conflict\n\n Fixes a long-standing corner case bug around directory renames in\n the merge-ort strategy.\n\n Will merge to 'master'.\n source: \n\n\n* zk/push-use-bitmaps (2022-06-17) 1 commit\n (merged to 'next' on 2022-07-08 at 8aa1f94fad)\n + send-pack.c: add config push.useBitmaps\n\n \"git push\" sometimes perform poorly when reachability bitmaps are\n used, even in a repository where other operations are helped by\n bitmaps. The push.useBitmaps configuration variable is introduced\n to allow disabling use of reachability bitmaps only for \"git push\".\n\n Will merge to 'master'.\n source: \n\n\n* jk/remote-show-with-negative-refspecs (2022-06-17) 1 commit\n (merged to 'next' on 2022-07-08 at d4e49ad22a)\n + remote: handle negative refspecs in git remote show\n (this branch is used by jk/t5505-restructure.)\n\n \"git remote show [-n] frotz\" now pays attention to negative\n pathspecs.\n\n Will merge to 'master'.\n source: <20220617002036.1577-2-jacob.keller@gmail.com>\n\n\n* js/commit-graph-parsing-without-repo-settings (2022-06-15) 1 commit\n - commit-graph: refactor to avoid prepare_repo_settings\n\n Expecting a reroll.\n source: <9b56496b0809cc8a25af877ea97042e2cb7f2af6.1655246092.git.steadmon@google.com>\n\n\n* ro/mktree-allow-missing-fix (2022-06-21) 1 commit\n (merged to 'next' on 2022-07-08 at 599ed6fb84)\n + mktree: do not check type of remote objects\n\n \"git mktree --missing\" lazily fetched objects that are missing from\n the local object store, which was totally unnecessary for the purpose\n of creating the tree object(s) from its input.\n\n Will merge to 'master'.\n source: <748f39a9-65aa-2110-cf92-7ddf81b5f507@roku.com>\n\n\n* jt/connected-show-missing-from-which-side (2022-06-10) 1 commit\n - fetch,fetch-pack: clarify connectivity check error\n\n We may find an object missing after a \"git fetch\" stores the\n objects it obtained from the other side, but it is not necessarily\n because the remote failed to send necessary objects. Reword the\n messages in an attempt to help users explore other possibilities\n when they hit this error.\n\n Expecting a reroll.\n source: <20220610195247.1177549-1-jonathantanmy@google.com>\n\n\n* ab/submodule-cleanup (2022-06-28) 12 commits\n (merged to 'next' on 2022-07-08 at 6f3886aa03)\n + git-sh-setup.sh: remove \"say\" function, change last users\n + git-submodule.sh: use \"$quiet\", not \"$GIT_QUIET\"\n + submodule--helper: eliminate internal \"--update\" option\n + submodule--helper: understand --checkout, --merge and --rebase synonyms\n + submodule--helper: report \"submodule\" as our name in some \"-h\" output\n + submodule--helper: rename \"absorb-git-dirs\" to \"absorbgitdirs\"\n + submodule update: remove \"-v\" option\n + submodule--helper: have --require-init imply --init\n + git-submodule.sh: remove unused top-level \"--branch\" argument\n + git-submodule.sh: make the \"$cached\" variable a boolean\n + git-submodule.sh: remove unused $prefix variable\n + git-submodule.sh: remove unused sanitize_submodule_env()\n (this branch is used by gc/submodule-use-super-prefix.)\n\n Further preparation to turn git-submodule.sh into a builtin.\n\n Will merge to 'master'.\n source: \n\n\n* jc/resolve-undo (2022-07-11) 2 commits\n - fsck: do not dereference NULL while checking resolve-undo data\n (merged to 'next' on 2022-06-15 at c195e5a2d9)\n + revision: mark blobs needed for resolve-undo as reachable\n\n The resolve-undo information in the index was not protected against\n GC, which has been corrected.\n\n Will merge to 'next'.\n source: \n\n\n* ab/build-gitweb (2022-06-28) 8 commits\n (merged to 'next' on 2022-07-11 at 731e354ff0)\n + gitweb/Makefile: add a \"NO_GITWEB\" parameter\n + Makefile: build 'gitweb' in the default target\n + gitweb/Makefile: include in top-level Makefile\n + gitweb: remove \"test\" and \"test-installed\" targets\n + gitweb/Makefile: prepare to merge into top-level Makefile\n + gitweb/Makefile: clear up and de-duplicate the gitweb.{css,js} vars\n + gitweb/Makefile: add a $(GITWEB_ALL) variable\n + gitweb/Makefile: define all .PHONY prerequisites inline\n\n Teach \"make all\" to build gitweb as well.\n\n Will merge to 'master'.\n source: \n\n\n* ab/test-without-templates (2022-06-06) 7 commits\n (merged to 'next' on 2022-07-11 at afab6c1918)\n + tests: don't assume a .git/info for .git/info/sparse-checkout\n + tests: don't assume a .git/info for .git/info/exclude\n + tests: don't assume a .git/info for .git/info/refs\n + tests: don't assume a .git/info for .git/info/attributes\n + tests: don't assume a .git/info for .git/info/grafts\n + tests: don't depend on template-created .git/branches\n + t0008: don't rely on default \".git/info/exclude\"\n\n Tweak tests so that they still work when the \"git init\" template\n did not create .git/info directory.\n\n Will merge to 'master'.\n source: \n\n\n* hx/unpack-streaming (2022-06-13) 6 commits\n (merged to 'next' on 2022-07-08 at 4eb375ec2f)\n + unpack-objects: use stream_loose_object() to unpack large objects\n + core doc: modernize core.bigFileThreshold documentation\n + object-file.c: add \"stream_loose_object()\" to handle large object\n + object-file.c: factor out deflate part of write_loose_object()\n + object-file.c: refactor write_loose_object() to several steps\n + unpack-objects: low memory footprint for get_data() in dry_run mode\n\n Allow large objects read from a packstream to be streamed into a\n loose object file straight, without having to keep it in-core as a\n whole.\n\n Will merge to 'master'.\n source: \n\n\n* tb/show-ref-count (2022-06-06) 2 commits\n - builtin/show-ref.c: limit output with `--count`\n - builtin/show-ref.c: rename `found_match` to `matches_nr`\n\n \"git show-ref\" learned to stop after emitting N refs with the new\n \"--count=N\" option.\n\n Expecting a reroll.\n cf. \n source: \n\n\n* ds/bundle-uri-more (2022-06-06) 6 commits\n - fetch: add 'refs/bundle/' to log.excludeDecoration\n - bundle-uri: add support for http(s):// and file://\n - fetch: add --bundle-uri option\n - bundle-uri: create basic file-copy logic\n - remote-curl: add 'get' capability\n - docs: document bundle URI standard\n\n The \"bundle URI\" topic.\n\n Needs review.\n source: \n\n\n* js/bisect-in-c (2022-06-27) 16 commits\n - bisect: no longer try to clean up left-over `.git/head-name` files\n - bisect: remove Cogito-related code\n - Turn `git bisect` into a full built-in\n - bisect: move even the command-line parsing to `bisect--helper`\n - bisect: teach the `bisect--helper` command to show the correct usage strings\n - bisect--helper: return only correct exit codes in `cmd_*()`\n - bisect--helper: move the `BISECT_STATE` case to the end\n - bisect--helper: make `--bisect-state` optional\n - bisect--helper: align the sub-command order with git-bisect.sh\n - bisect--helper: using `--bisect-state` without an argument is a bug\n - bisect--helper: really retire `--bisect-autostart`\n - bisect--helper: really retire --bisect-next-check\n - bisect--helper: retire the --no-log option\n - bisect: avoid double-quoting when printing the failed command\n - bisect run: fix the error message\n - bisect: verify that a bogus option won't try to start a bisection\n\n Final bits of \"git bisect.sh\" have been rewritten in C.\n\n Expecting a (hopefully final) reroll.\n cf. <20627.86ilolhnnn.gmgdl@evledraar.gmail.com>\n source: \n\n\n* gc/bare-repo-discovery (2022-07-07) 5 commits\n - setup.c: create `discovery.bare`\n - safe.directory: use git_protected_config()\n - config: learn `git_protected_config()`\n - Documentation: define protected configuration\n - Documentation/git-config.txt: add SCOPES section\n\n Introduce a discovery.barerepository configuration variable that\n allows users to forbid discovery of bare repositories.\n\n Will merge to 'next'?\n source: \n\n\n* gg/worktree-from-the-above (2022-06-21) 2 commits\n (merged to 'next' on 2022-07-08 at fa0e71ba39)\n + dir: minor refactoring / clean-up\n + dir: traverse into repository\n\n In a non-bare repository, the behavior of Git when the\n core.worktree configuration variable points at a directory that has\n a repository as its subdirectory, regressed in Git 2.27 days.\n\n Will merge to 'master'.\n source: <20220616234433.225-1-gg.oss@outlook.com>\n source: <20220616231956.154-1-gg.oss@outlook.com>\n\n--------------------------------------------------\n[Discarded]\n\n* ar/send-email-confirm-by-default (2022-04-22) 1 commit\n . send-email: always confirm by default\n\n \"git send-email\" is changed so that by default it asks for\n confirmation before sending each message out.\n\n Discarded.\n I wanted to like this, and had it in the version of Git I use\n myself for daily work, but the prompting turned out to be somewhat\n distracting.\n source: <20220422083629.1404989-1-hi@alyssa.is>\n"},{"id":"458919","messageId":"kl6lpmia55ys.fsf@chooglen-macbookpro.roam.corp.google.com","threadId":"58142","inReplyTo":"xmqqo7xufee7.fsf@gitster.g","subject":"gc/bare-repo-discovery (was Re: What's cooking in git.git (Jul 2022, #03; Mon, 11))","fromName":"Glen Choo","fromEmail":"chooglen@google.com","sentAt":"2022-07-12T22:19:55Z","receivedAt":"2022-07-12T22:20:05Z","isPatch":false,"sender":{"key":"glencbz@gmail.com","avatar":"https://avatars.githubusercontent.com/u/58092771?v=4"},"body":"Junio C Hamano writes:\n\n> Maintenance releases v2.37.1 and others have been tagged. They are\n> to address CVE-2022-29187, a vulnerability related to CVE-2022-24765\n> that was fixed earlier. Big thanks to Carlo Arenas and Johannes\n> Schindelin for fixing the issue and helping the releases out.\n\n\\o/ thanks everyone!\n\n> * gc/bare-repo-discovery (2022-07-07) 5 commits\n> - setup.c: create `discovery.bare`\n> - safe.directory: use git_protected_config()\n> - config: learn `git_protected_config()`\n> - Documentation: define protected configuration\n> - Documentation/git-config.txt: add SCOPES section\n>\n> Introduce a discovery.barerepository configuration variable that\n> allows users to forbid discovery of bare repositories.\n>\n> Will merge to 'next'?\n> source: \n\nI have a (hopefully final) reroll planned that takes your\ndocumentation suggestions. I think it reads a lot better with those, so\nthanks!\n\nI also noted your distaste for the `discovery.*` namespace (fair\nenough). To avoid a reroll-of-the-reroll, I was hoping that we could\nagree on something on-list (thread here [1]) before I send out the next\nversion.\n\n[1] https://lore.kernel.org/git/kl6lsfn656cw.fsf@chooglen-macbookpro.roam.corp.google.com\n"},{"id":"458920","messageId":"dfe0c1ab-33f8-f13e-71ce-1829bb0d2d7f@iee.email","threadId":"58142","inReplyTo":"xmqqo7xufee7.fsf@gitster.g","subject":"Re: What's cooking in git.git (Jul 2022, #03; Mon, 11)","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.email","sentAt":"2022-07-12T22:29:21Z","receivedAt":"2022-07-12T22:29:28Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"On 12/07/2022 18:07, Junio C Hamano wrote:\n> [New Topics]\n>\n> * po/doc-add-renormalize (2022-07-09) 1 commit\n> - doc add: renormalize is not idempotent for CRCRLF\n>\n> Documentation for \"git add --renormalize\" has been improved.\n>\n> Will merge to 'next'?\n> source: \n>\n>\n> * po/glossary-around-traversal (2022-07-09) 3 commits\n> - glossary: add reachability bitmap description\n> - glossary: add commit graph description\n> - glossary: add Object DataBase (ODB) abbreviation\n>\n> The glossary entries for \"commit-graph file\" and \"reachability\n> bitmap\" have been added.\n>\n> Will merge to 'next'?\n> source: \nI'm expecting to do a re-roll for both these, though I'm just recovering\nfrom an infection.\nIf you could hold off for a few days that would be great.\n--\nPhilip\n"},{"id":"458927","messageId":"Ys4DjW9JjQFx5Bhb@nand.local","threadId":"58142","inReplyTo":"xmqqo7xufee7.fsf@gitster.g","subject":"ac/bitmap-lookup-table (was: Re: What's cooking in git.git (Jul 2022, #03; Mon, 11))","fromName":"Taylor Blau","fromEmail":"me@ttaylorr.com","sentAt":"2022-07-12T23:28:13Z","receivedAt":"2022-07-12T23:28:17Z","isPatch":false,"sender":{"key":"me@ttaylorr.com","avatar":"https://avatars.githubusercontent.com/u/301000140?v=4"},"body":"Hi Junio,\n\nOn Tue, Jul 12, 2022 at 10:07:44AM -0700, Junio C Hamano wrote:\n> * ac/bitmap-lookup-table (2022-07-06) 6 commits\n> - p5310-pack-bitmaps.sh: remove pack.writeReverseIndex\n> - bitmap-lookup-table: add performance tests for lookup table\n> - pack-bitmap: prepare to read lookup table extension\n> - pack-bitmap-write: learn pack.writeBitmapLookupTable and add tests\n> - pack-bitmap-write.c: write lookup table extension\n> - Documentation/technical: describe bitmap lookup table extension\n>\n> The pack bitmap file gained a bitmap-lookup table to speed up\n> locating the necessary bitmap for a given commit.\n>\n> Will merge to 'next'?\n> source: \n\nI think that this version is pretty close to being ready, but I haven't\nhad a chance to look it over carefully yet since getting back from my\ntime off last week.\n\nI should have time to review this in the next day or two, if neither of\nyou mind waiting.\n\nThanks,\nTaylor\n"},{"id":"458946","messageId":"s3726r9p-r96o-7793-0qrq-o54rs4npr972@tzk.qr","threadId":"58142","inReplyTo":"xmqqo7xufee7.fsf@gitster.g","subject":"js/bisect-in-c, was Re: What's cooking in git.git (Jul 2022, #03; Mon, 11)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2022-07-13T11:10:38Z","receivedAt":"2022-07-13T11:11:04Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Junio,\n\nOn Tue, 12 Jul 2022, Junio C Hamano wrote:\n\n> * js/bisect-in-c (2022-06-27) 16 commits\n> - bisect: no longer try to clean up left-over `.git/head-name` files\n> - bisect: remove Cogito-related code\n> - Turn `git bisect` into a full built-in\n> - bisect: move even the command-line parsing to `bisect--helper`\n> - bisect: teach the `bisect--helper` command to show the correct usage strings\n> - bisect--helper: return only correct exit codes in `cmd_*()`\n> - bisect--helper: move the `BISECT_STATE` case to the end\n> - bisect--helper: make `--bisect-state` optional\n> - bisect--helper: align the sub-command order with git-bisect.sh\n> - bisect--helper: using `--bisect-state` without an argument is a bug\n> - bisect--helper: really retire `--bisect-autostart`\n> - bisect--helper: really retire --bisect-next-check\n> - bisect--helper: retire the --no-log option\n> - bisect: avoid double-quoting when printing the failed command\n> - bisect run: fix the error message\n> - bisect: verify that a bogus option won't try to start a bisection\n>\n> Final bits of \"git bisect.sh\" have been rewritten in C.\n>\n> Expecting a (hopefully final) reroll.\n> cf. <20627.86ilolhnnn.gmgdl@evledraar.gmail.com>\n\nI did not find that one, but I found\nhttps://lore.kernel.org/git/220627.86ilolhnnn.gmgdl@evledraar.gmail.com/\n\nAnd that claims that Git has a convention to universally exit with code\n129 when options are passed with incorrect values.\n\nThat claim does not survive even minimal contact with Git's source\ncode, though.\n\nIf I find some time, I will respond to that mail, but a reroll is actually\nunnecessary.\n\n> source: \n\nThanks,\nDscho\n"},{"id":"458948","messageId":"220713.865yk1456z.gmgdl@evledraar.gmail.com","threadId":"58142","inReplyTo":"s3726r9p-r96o-7793-0qrq-o54rs4npr972@tzk.qr","subject":"Re: js/bisect-in-c, was Re: What's cooking in git.git (Jul 2022, #03; Mon, 11)","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2022-07-13T11:18:39Z","receivedAt":"2022-07-13T11:34:21Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Wed, Jul 13 2022, Johannes Schindelin wrote:\n\n> Hi Junio,\n>\n> On Tue, 12 Jul 2022, Junio C Hamano wrote:\n>\n>> * js/bisect-in-c (2022-06-27) 16 commits\n>> - bisect: no longer try to clean up left-over `.git/head-name` files\n>> - bisect: remove Cogito-related code\n>> - Turn `git bisect` into a full built-in\n>> - bisect: move even the command-line parsing to `bisect--helper`\n>> - bisect: teach the `bisect--helper` command to show the correct usage strings\n>> - bisect--helper: return only correct exit codes in `cmd_*()`\n>> - bisect--helper: move the `BISECT_STATE` case to the end\n>> - bisect--helper: make `--bisect-state` optional\n>> - bisect--helper: align the sub-command order with git-bisect.sh\n>> - bisect--helper: using `--bisect-state` without an argument is a bug\n>> - bisect--helper: really retire `--bisect-autostart`\n>> - bisect--helper: really retire --bisect-next-check\n>> - bisect--helper: retire the --no-log option\n>> - bisect: avoid double-quoting when printing the failed command\n>> - bisect run: fix the error message\n>> - bisect: verify that a bogus option won't try to start a bisection\n>>\n>> Final bits of \"git bisect.sh\" have been rewritten in C.\n>>\n>> Expecting a (hopefully final) reroll.\n>> cf. <20627.86ilolhnnn.gmgdl@evledraar.gmail.com>\n>\n> I did not find that one, but I found\n> https://lore.kernel.org/git/220627.86ilolhnnn.gmgdl@evledraar.gmail.com/\n>\n> And that claims that Git has a convention to universally exit with code\n> 129 when options are passed with incorrect values.\n>\n> That claim does not survive even minimal contact with Git's source\n> code, though.\n\nI'm not claiming that we always use 129 when we're fed bad options etc.,\nbut rather that that's what parse_options() does, so at this point most\ncommands do that consistently.\n\t\n\t./git --blah >/dev/null 2>&1; echo $?\n\t129\n\t./git status --blah >/dev/null 2>&1; echo $?\n\t129\n\nBut yes, you can find exceptions still, e.g. try that with \"git log\" and\nit'll return 128.\n\nYour series migrates the bisect--helper.c away from parse_options() in a\na way that I don't think is necessary, but leaving that aside mimicking\nthe exit codes we'd get from parse_options() for those cases you're\nhandling in your custom parsing seems like a good thing.\n\n> If I find some time, I will respond to that mail, but a reroll is actually\n> unnecessary.\n\nThere's some more in [1], but there's at least one outstanding bug in\nthis series, i.e. that you're moving away from parse_options(), but\nforgot to change the corresponding flag in git.c for the\nbuilt-in. That's then used by the completion mechanism.\n\nBut as noted in [2] and more recently in [1] I'm most concerned about us\nhaving outstanding bugs due to past iterations of this having played\nwhack-a-mole in fixing specific edge cases I found, but not gone back\nand added missing test coverage for the series beforehand.\n\nWhich, I'm not saying should hold this series up, but just that having\nreviewed it for a few iterations I'm not comfortable saying we haven't\nmissed something else, and given the nature of the past whack-a-mole\nfixes it looks like you haven't really looked it either.\n\nI'm referring to e.g. the thread ending at [3], where I pointed out that\n\"git -h\" was broken, you apparently tested one of the\nsubcommands and concluded it wasn't broken, but clearly not all of them.\n\nWhich, I'd be less concerned about if as pointed out in [1] we don't\nhave entirte bisect sub-commands that don't have any test coverage at\nall, so whatever coverage we have probably has major gaps.\n\n1. https://lore.kernel.org/git/220627.86mtdxhnwk.gmgdl@evledraar.gmail.com/\n2. https://lore.kernel.org/git/220523.865ylwzgji.gmgdl@evledraar.gmail.com/\n3. https://lore.kernel.org/git/220225.86ilt27uln.gmgdl@evledraar.gmail.com/\n"},{"id":"458988","messageId":"xmqqtu7ldmrz.fsf@gitster.g","threadId":"58142","inReplyTo":"220713.865yk1456z.gmgdl@evledraar.gmail.com","subject":"Re: js/bisect-in-c, was Re: What's cooking in git.git (Jul 2022, #03; Mon, 11)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-07-13T16:01:52Z","receivedAt":"2022-07-13T16:02:19Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ævar Arnfjörð Bjarmason writes:\n\n> I'm not claiming that we always use 129 when we're fed bad options etc.,\n> but rather that that's what parse_options() does, so at this point most\n> commands do that consistently.\n> \t\n> \t./git --blah >/dev/null 2>&1; echo $?\n> \t129\n> \t./git status --blah >/dev/null 2>&1; echo $?\n> \t129\n>\n> But yes, you can find exceptions still, e.g. try that with \"git log\" and\n> it'll return 128.\n\nYup, that was my understanding as well. We may have existing\nbreakage that we shouldn't be actively imitating when we do not have\nto.\n\n> Which, I'm not saying should hold this series up, but just that having\n> reviewed it for a few iterations I'm not comfortable saying we haven't\n> missed something else, and given the nature of the past whack-a-mole\n> fixes it looks like you haven't really looked it either.\n\n\"We haven't missed\" is not something we can comfortably say, ever,\naobut a series with any meaningful size. I am not so worried about\nit, if it is your only worries. Would it make it less likely to\nhave introduced unintended bugs if we find a way to keep using\nparse-options?\n\n> I'm referring to e.g. the thread ending at [3], where I pointed out that\n> \"git -h\" was broken, you apparently tested one of the\n> subcommands and concluded it wasn't broken, but clearly not all of them.\n>\n> Which, I'd be less concerned about if as pointed out in [1] we don't\n> have entirte bisect sub-commands that don't have any test coverage at\n> all, so whatever coverage we have probably has major gaps.\n>\n> 1. https://lore.kernel.org/git/220627.86mtdxhnwk.gmgdl@evledraar.gmail.com/\n> 2. https://lore.kernel.org/git/220523.865ylwzgji.gmgdl@evledraar.gmail.com/\n> 3. https://lore.kernel.org/git/220225.86ilt27uln.gmgdl@evledraar.gmail.com/\n"},{"id":"458991","messageId":"xmqq8roxdlhe.fsf@gitster.g","threadId":"58142","inReplyTo":"kl6lpmia55ys.fsf@chooglen-macbookpro.roam.corp.google.com","subject":"Re: gc/bare-repo-discovery (was Re: What's cooking in git.git (Jul 2022, #03; Mon, 11))","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-07-13T16:29:49Z","receivedAt":"2022-07-13T16:29:57Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Glen Choo writes:\n\n> I also noted your distaste for the `discovery.*` namespace (fair\n> enough). To avoid a reroll-of-the-reroll, I was hoping that we could\n> agree on something on-list (thread here [1]) before I send out the next\n> version.\n\nI found your idea of adding this new one in the safe.* hierarchy\nquite reasonable. \"safe.discoveredBareRepository = yes / no\" may be\nquote a mouthful, but I do not think I can think of anything better.\n"},{"id":"458992","messageId":"xmqq4jzldlel.fsf@gitster.g","threadId":"58142","inReplyTo":"dfe0c1ab-33f8-f13e-71ce-1829bb0d2d7f@iee.email","subject":"Re: What's cooking in git.git (Jul 2022, #03; Mon, 11)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-07-13T16:31:30Z","receivedAt":"2022-07-13T16:31:37Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Philip Oakley writes:\n\n> I'm expecting to do a re-roll for both these, though I'm just recovering\n> from an infection.\n> If you could hold off for a few days that would be great.\n\nBe well soon and take care of yourself.\n\nThanks, will relabel them to \"Expecting a reroll\".\n"},{"id":"458993","messageId":"xmqqzghdc6b4.fsf@gitster.g","threadId":"58142","inReplyTo":"Ys4DjW9JjQFx5Bhb@nand.local","subject":"Re: ac/bitmap-lookup-table","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-07-13T16:42:55Z","receivedAt":"2022-07-13T16:42:59Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Taylor Blau writes:\n\n> Hi Junio,\n>\n> On Tue, Jul 12, 2022 at 10:07:44AM -0700, Junio C Hamano wrote:\n>> * ac/bitmap-lookup-table (2022-07-06) 6 commits\n>> - p5310-pack-bitmaps.sh: remove pack.writeReverseIndex\n>> - bitmap-lookup-table: add performance tests for lookup table\n>> - pack-bitmap: prepare to read lookup table extension\n>> - pack-bitmap-write: learn pack.writeBitmapLookupTable and add tests\n>> - pack-bitmap-write.c: write lookup table extension\n>> - Documentation/technical: describe bitmap lookup table extension\n>>\n>> The pack bitmap file gained a bitmap-lookup table to speed up\n>> locating the necessary bitmap for a given commit.\n>>\n>> Will merge to 'next'?\n>> source: \n>\n> I think that this version is pretty close to being ready, but I haven't\n> had a chance to look it over carefully yet since getting back from my\n> time off last week.\n>\n> I should have time to review this in the next day or two, if neither of\n> you mind waiting.\n\nThanks!\n"},{"id":"459029","messageId":"220714.86fsj4356l.gmgdl@evledraar.gmail.com","threadId":"58142","inReplyTo":"xmqqtu7ldmrz.fsf@gitster.g","subject":"Re: js/bisect-in-c, was Re: What's cooking in git.git (Jul 2022, #03; Mon, 11)","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2022-07-14T00:22:13Z","receivedAt":"2022-07-14T00:32:13Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Wed, Jul 13 2022, Junio C Hamano wrote:\n\n> Ævar Arnfjörð Bjarmason writes:\n>\n>> I'm not claiming that we always use 129 when we're fed bad options etc.,\n>> but rather that that's what parse_options() does, so at this point most\n>> commands do that consistently.\n>> \t\n>> \t./git --blah >/dev/null 2>&1; echo $?\n>> \t129\n>> \t./git status --blah >/dev/null 2>&1; echo $?\n>> \t129\n>>\n>> But yes, you can find exceptions still, e.g. try that with \"git log\" and\n>> it'll return 128.\n>\n> Yup, that was my understanding as well. We may have existing\n> breakage that we shouldn't be actively imitating when we do not have\n> to.\n>\n>> Which, I'm not saying should hold this series up, but just that having\n>> reviewed it for a few iterations I'm not comfortable saying we haven't\n>> missed something else, and given the nature of the past whack-a-mole\n>> fixes it looks like you haven't really looked it either.\n>\n> \"We haven't missed\" is not something we can comfortably say, ever,\n> aobut a series with any meaningful size. I am not so worried about\n> it, if it is your only worries. Would it make it less likely to\n> have introduced unintended bugs if we find a way to keep using\n> parse-options?\n\nI started writing something here, but found myself rewriting the last 3\nparagraphs of [1] seen in the context below, so I'll just refer to that.\n\nFWIW ejecting 11-14/16, i.e. these patches:\n\n\t- Turn `git bisect` into a full built-in\n\t- bisect: move even the command-line parsing to `bisect--helper`\n\t- bisect: teach the `bisect--helper` command to show the correct usage strings\n\t- bisect--helper: return only correct exit codes in `cmd_*()`\n\nYields a result that I've got no concerns about whatsoever, and reduces\nthe diffstat from:\n\n 7 files changed, 110 insertions(+), 207 deletions(-)\n\nTo just:\n\n 4 files changed, 71 insertions(+), 67 deletions(-)\n\nWhich I think might be worth considering, similar to how the submodule\nmigration is happening in multi-step fashion. I.e. advancing the parts\nthat don't migrate it away from parse_options(), since I showed a way to\nkeep using it in [1] (while changing less code).\n\nOr just merge it down, up to you :)\n\n>> I'm referring to e.g. the thread ending at [3], where I pointed out that\n>> \"git -h\" was broken, you apparently tested one of the\n>> subcommands and concluded it wasn't broken, but clearly not all of them.\n>>\n>> Which, I'd be less concerned about if as pointed out in [1] we don't\n>> have entirte bisect sub-commands that don't have any test coverage at\n>> all, so whatever coverage we have probably has major gaps.\n>>\n>> 1. https://lore.kernel.org/git/220627.86mtdxhnwk.gmgdl@evledraar.gmail.com/\n>> 2. https://lore.kernel.org/git/220523.865ylwzgji.gmgdl@evledraar.gmail.com/\n>> 3. https://lore.kernel.org/git/220225.86ilt27uln.gmgdl@evledraar.gmail.com/\n\n"},{"id":"459049","messageId":"5ps2q552-1rr3-7161-4181-31556pp2ns12@tzk.qr","threadId":"58142","inReplyTo":"xmqq8roxdlhe.fsf@gitster.g","subject":"Re: gc/bare-repo-discovery (was Re: What's cooking in git.git (Jul 2022, #03; Mon, 11))","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2022-07-14T16:17:39Z","receivedAt":"2022-07-14T16:17:50Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 13 Jul 2022, Junio C Hamano wrote:\n\n> Glen Choo writes:\n>\n> > I also noted your distaste for the `discovery.*` namespace (fair\n> > enough). To avoid a reroll-of-the-reroll, I was hoping that we could\n> > agree on something on-list (thread here [1]) before I send out the next\n> > version.\n>\n> I found your idea of adding this new one in the safe.* hierarchy\n> quite reasonable. \"safe.discoveredBareRepository = yes / no\" may be\n> quote a mouthful, but I do not think I can think of anything better.\n\nI would find `safe.bareRepository = true` or `false` more intuitive, and\nmore concise.\n\nAnd if there should be an option to ignore bare repositories when\ndiscovering a Git repository, it could be a tristate, with `ignore` being\nthe value to trigger that mode.\n\nThanks,\nDscho\n"},{"id":"459062","messageId":"xmqqmtdb5z3s.fsf@gitster.g","threadId":"58142","inReplyTo":"5ps2q552-1rr3-7161-4181-31556pp2ns12@tzk.qr","subject":"Re: gc/bare-repo-discovery (was Re: What's cooking in git.git (Jul 2022, #03; Mon, 11))","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-07-14T18:27:19Z","receivedAt":"2022-07-14T18:27:29Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> I would find `safe.bareRepository = true` or `false` more intuitive, and\n> more concise.\n\nYup, that is fine by me.\n\n> And if there should be an option to ignore bare repositories when\n> discovering a Git repository, it could be a tristate, with `ignore` being\n> the value to trigger that mode.\n\nSounds good.\n"},{"id":"459068","messageId":"p8srrprq-s23s-711n-n452-34qr856qso29@tzk.qr","threadId":"58142","inReplyTo":"xmqqtu7ldmrz.fsf@gitster.g","subject":"Re: js/bisect-in-c, was Re: What's cooking in git.git (Jul 2022, #03; Mon, 11)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2022-07-14T19:35:20Z","receivedAt":"2022-07-14T19:35:39Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Junio,\n\nOn Wed, 13 Jul 2022, Junio C Hamano wrote:\n\n> Ævar Arnfjörð Bjarmason writes:\n>\n> > I'm not claiming that we always use 129 when we're fed bad options etc.,\n> > but rather that that's what parse_options() does, so at this point most\n> > commands do that consistently.\n> >\n> > \t./git --blah >/dev/null 2>&1; echo $?\n> > \t129\n> > \t./git status --blah >/dev/null 2>&1; echo $?\n> > \t129\n> >\n> > But yes, you can find exceptions still, e.g. try that with \"git log\" and\n> > it'll return 128.\n>\n> Yup, that was my understanding as well. We may have existing\n> breakage that we shouldn't be actively imitating when we do not have\n> to.\n\nThis patch series already implements `git bisect` in the desired way:\n\n\t$ ./git bisect --invalid; echo $?\n\tusage: git bisect [help|start|bad|good|new|old|terms|skip|next|reset|visualize|view|replay|log|run]\n\t129\n\nCiao,\nJohannes\n"},{"id":"459085","messageId":"220714.86mtdb1jmp.gmgdl@evledraar.gmail.com","threadId":"58142","inReplyTo":"p8srrprq-s23s-711n-n452-34qr856qso29@tzk.qr","subject":"Re: js/bisect-in-c, was Re: What's cooking in git.git (Jul 2022, #03; Mon, 11)","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2022-07-14T21:09:53Z","receivedAt":"2022-07-14T21:15:17Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Thu, Jul 14 2022, Johannes Schindelin wrote:\n\n> Hi Junio,\n>\n> On Wed, 13 Jul 2022, Junio C Hamano wrote:\n>\n>> Ævar Arnfjörð Bjarmason writes:\n>>\n>> > I'm not claiming that we always use 129 when we're fed bad options etc.,\n>> > but rather that that's what parse_options() does, so at this point most\n>> > commands do that consistently.\n>> >\n>> > \t./git --blah >/dev/null 2>&1; echo $?\n>> > \t129\n>> > \t./git status --blah >/dev/null 2>&1; echo $?\n>> > \t129\n>> >\n>> > But yes, you can find exceptions still, e.g. try that with \"git log\" and\n>> > it'll return 128.\n>>\n>> Yup, that was my understanding as well. We may have existing\n>> breakage that we shouldn't be actively imitating when we do not have\n>> to.\n>\n> This patch series already implements `git bisect` in the desired way:\n>\n> \t$ ./git bisect --invalid; echo $?\n> \tusage: git bisect [help|start|bad|good|new|old|terms|skip|next|reset|visualize|view|replay|log|run]\n> \t129\n\nIt doesn't, the claim isn't that there's no way to have it return exit\ncode 129 on *some* invalid usage. In this case we do the \"right\" thing.\n\nRather that as noted in [1] there's other cases where we call die() and\nshould call usage_msg_opt().\n\nOf course both of those would be more useful if the new built-in still\nhad the parse_options() usage info we could display. I.e. in this case\nthe conversion to a built-in leaves on the table nice benefits we'd get\nfor free.\n\nCompare that with e.g. how \"git bundle\" handles it, note how we get not\nonly \"don't do that\", but also how valid usage would look like:\n\t\n\t$ git bundle -h\n\tusage: git bundle create [-q | --quiet | --progress | --all-progress] [--all-progress-implied]\n\t [--version=] \n\t or: git bundle verify [-q | --quiet] \n\t or: git bundle fetch [--filter=] \n\t or: git bundle list-heads [...]\n\t or: git bundle unbundle [--progress] [...]\n\t$ git bundle create -h\n\tusage: git bundle create [-q | --quiet | --progress | --all-progress] [--all-progress-implied]\n\t [--version=] \n\t\n\t -q, --quiet do not show progress meter\n\t --progress show progress meter\n\t --all-progress show progress meter during object writing phase\n\t --all-progress-implied\n\t similar to --all-progress when progress meter is shown\n\t --version specify bundle format version\n\n1. https://lore.kernel.org/git/220627.86ilolhnnn.gmgdl@evledraar.gmail.com/\n"},{"id":"461264","messageId":"8o63pp64-4s00-1000-42s1-38so68398337@tzk.qr","threadId":"58142","inReplyTo":"220714.86mtdb1jmp.gmgdl@evledraar.gmail.com","subject":"Re: js/bisect-in-c, was Re: What's cooking in git.git (Jul 2022, #03; Mon, 11)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2022-08-16T08:51:04Z","receivedAt":"2022-08-16T09:58:28Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Ævar,\n\nOn Thu, 14 Jul 2022, Ævar Arnfjörð Bjarmason wrote:\n\n> On Thu, Jul 14 2022, Johannes Schindelin wrote:\n>\n> > On Wed, 13 Jul 2022, Junio C Hamano wrote:\n> >\n> >> Ævar Arnfjörð Bjarmason writes:\n> >>\n> >> > I'm not claiming that we always use 129 when we're fed bad options etc.,\n> >> > but rather that that's what parse_options() does, so at this point most\n> >> > commands do that consistently.\n> >> >\n> >> > \t./git --blah >/dev/null 2>&1; echo $?\n> >> > \t129\n> >> > \t./git status --blah >/dev/null 2>&1; echo $?\n> >> > \t129\n> >> >\n> >> > But yes, you can find exceptions still, e.g. try that with \"git log\" and\n> >> > it'll return 128.\n> >>\n> >> Yup, that was my understanding as well. We may have existing\n> >> breakage that we shouldn't be actively imitating when we do not have\n> >> to.\n> >\n> > This patch series already implements `git bisect` in the desired way:\n> >\n> > \t$ ./git bisect --invalid; echo $?\n> > \tusage: git bisect [help|start|bad|good|new|old|terms|skip|next|reset|visualize|view|replay|log|run]\n> > \t129\n>\n> It doesn't, the claim isn't that there's no way to have it return exit\n> code 129 on *some* invalid usage. In this case we do the \"right\" thing.\n>\n> Rather that as noted in [1] there's other cases where we call die() and\n> should call usage_msg_opt().\n\nIt would have been better to take the time to spell out clearly that you\nare taking offense in `git bisect start -h` not behaving in the way you\nthink is the rule in Git: to print a _subcommand_ usage and exit with code\n129.\n\nHowever, this feedback fails to recognize the scope of this patch series.\n\nThe patch series' intention is not to fix anything that is currently\nbroken. And it is already broken, my patch series does not introduce that\nbreakage (and it would make more sense to address this breakage _after_\nthe conversion, to avoid doubling the effort): The current output of `git\nbisect start -h` shows the usage of `bisect--helper`!\n\nInstead, the scope of the patch series is to finalize converting the\n`bisect` command to a full built-in, implemented in C, and avoiding the\nportability cost of running a POSIX shell script.\n\nNote: I agree with you that it would be nice for `git bisect start -h` to\noutput a proper usage. There will be a time to discuss that, that time is\njust simply not right now.\n\nSince the scope is so different from what your feedback suggests, I have\nto admit that it taxes my patience to see that laser focus on aspects that\nare almost irrelevant compared to the aspects that should concern any\ngood review of this series: the correctness of the conversion, with a\nheavy focus on the non-failure modes.\n\nNo user would care about the exit code of a failure mode (as long as it is\nnon-zero), if there are regressions e.g. in how `git bisect start\n--good=Ævar --bad=Dscho` behaves.\n\nSo this hyper focus on what look like less relevant aspects is not only\nirritating, it actively distracts me, others and even yourself from the\nthorough review I would like to get: There have not been any thorough\nreviews of this patch series so far, and I think it is because of this\nhere distraction.\n\nThe cost of this distraction is quite real: not only is there a\nperformance penalty of running POSIX shell scripts on Windows, there are\nalso problems with anti-malware disliking the way the POSIX emulation\nlayer works that we currently have to use on Windows to run `git bisect`,\nwhich would be fixed by `bisect` being a full built-in. This distracting\nfeedback that prevents a thorough code review delays that fix for those\nusers.\n\nTo understand what I am aiming for, look at the deep analysis of the\nrot13 filter conversion from Perl to C in\nhttps://lore.kernel.org/git/4n20476q-6ssr-osp8-q5o3-p8ns726q4pn3@tzk.qr/,\nwhere I carefully compared the behavior of the scripted code with the C\ncode that was designed to replace it.\n\nAt this point, it is good to recall Parkinson's law of triviality:\n\n\tParkinson observed and illustrated that a committee whose job was\n\tto approve plans for a nuclear power plant spent the majority of\n\tits time with pointless discussions on relatively trivial and\n\tunimportant but easy-to-grasp issues, such as what materials to\n\tuse for the staff bike-shed, while neglecting the less-trivial\n\tproposed design of the nuclear power plant itself, which is far\n\tmore important but also a far more difficult and complex task to\n\tcriticise constructively.\n\nWe've seen quite a few regressions as of recent that would have likely\nbeen prevented by thorough reviews that do not distract themselves with\ntangents, pet peeves and personal taste.\n\nIt would do good if we the reviewers on the Git mailing list took to heart\nthat Git is a software that millions of users depend on, not just our toy\nto play with, and therefore the purpose of our reviews should aim to keep\nGit working and safe. We will achieve that only if we avoid what Parkinson\ncalled pointless discussions and instead put in the effort to provide\nhigh-quality feedback that helps improve the design and the correctness of\nthe code.\n\nIn this instance, the discussion about exit codes and usage messages\nshould be postponed, in favor of focusing on the actual scope of this\npatch series.\n\nCiao,\nJohannes\n"},{"id":"461331","messageId":"220817.86pmgzabv0.gmgdl@evledraar.gmail.com","threadId":"58142","inReplyTo":"8o63pp64-4s00-1000-42s1-38so68398337@tzk.qr","subject":"Re: js/bisect-in-c, was Re: What's cooking in git.git (Jul 2022, #03; Mon, 11)","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2022-08-17T00:49:14Z","receivedAt":"2022-08-17T01:38:04Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Tue, Aug 16 2022, Johannes Schindelin wrote:\n\n> Hi Ævar,\n>\n> On Thu, 14 Jul 2022, Ævar Arnfjörð Bjarmason wrote:\n>\n>> On Thu, Jul 14 2022, Johannes Schindelin wrote:\n>>\n>> > On Wed, 13 Jul 2022, Junio C Hamano wrote:\n>> >\n>> >> Ævar Arnfjörð Bjarmason writes:\n>> >>\n>> >> > I'm not claiming that we always use 129 when we're fed bad options etc.,\n>> >> > but rather that that's what parse_options() does, so at this point most\n>> >> > commands do that consistently.\n>> >> >\n>> >> > \t./git --blah >/dev/null 2>&1; echo $?\n>> >> > \t129\n>> >> > \t./git status --blah >/dev/null 2>&1; echo $?\n>> >> > \t129\n>> >> >\n>> >> > But yes, you can find exceptions still, e.g. try that with \"git log\" and\n>> >> > it'll return 128.\n>> >>\n>> >> Yup, that was my understanding as well. We may have existing\n>> >> breakage that we shouldn't be actively imitating when we do not have\n>> >> to.\n>> >\n>> > This patch series already implements `git bisect` in the desired way:\n>> >\n>> > \t$ ./git bisect --invalid; echo $?\n>> > \tusage: git bisect [help|start|bad|good|new|old|terms|skip|next|reset|visualize|view|replay|log|run]\n>> > \t129\n>>\n>> It doesn't, the claim isn't that there's no way to have it return exit\n>> code 129 on *some* invalid usage. In this case we do the \"right\" thing.\n>>\n>> Rather that as noted in [1] there's other cases where we call die() and\n>> should call usage_msg_opt().\n>\n> It would have been better to take the time to spell out clearly that you\n> are taking offense in `git bisect start -h` not behaving in the way you\n> think is the rule in Git: to print a _subcommand_ usage and exit with code\n> 129.\n>\n> However, this feedback fails to recognize the scope of this patch series.\n\nNo, I'm pointing out that you could *also* get more benefit from moving\nmore towards the way we do things with other sub-commands in\nbuiltin/bisect.c.\n\nBut the core feedback was on your 11/16\n(https://lore.kernel.org/git/ce508583e455a1dbb7620a238edb11dae195f00d.1656354677.git.gitgitgadget@gmail.com/)\nchanging (\"correct[ing\") the return code\n\nIf we're going out of our way to change the behavior of bisect\nwhile-we're-at-it let's change it to the actually correct thing. I think\nJunio concurred with that here:\nhttps://lore.kernel.org/git/xmqqtu7ldmrz.fsf@gitster.g/\n\n> The patch series' intention is not to fix anything that is currently\n> broken. And it is already broken, my patch series does not introduce that\n> breakage.\n\nI think that would be completely fair if it aimed to bug-for-bug\nre-implement the current git-bisect.sh behavior, without the unnecessary\nwhile-we're-at-it changes.\n\n> (and it would make more sense to address this breakage _after_\n> the conversion, to avoid doubling the effort): The current output of `git\n> bisect start -h` shows the usage of `bisect--helper`!\n>\n> Instead, the scope of the patch series is to finalize converting the\n> `bisect` command to a full built-in, implemented in C, and avoiding the\n> portability cost of running a POSIX shell script.\n>\n> Note: I agree with you that it would be nice for `git bisect start -h` to\n> output a proper usage. There will be a time to discuss that, that time is\n> just simply not right now.\n\nI agree with all of that, but that's not what I've been pointing out to\nyou, except to note that your bisect.sh->C conversion is making some\nsubsequent follow-up work harder than it needs to be.\n\n> Since the scope is so different from what your feedback suggests, I have\n> to admit that it taxes my patience to see that laser focus on aspects that\n> are almost irrelevant compared to the aspects that should concern any\n> good review of this series: the correctness of the conversion, with a\n> heavy focus on the non-failure modes.\n\n...\n\n> No user would care about the exit code of a failure mode (as long as it is\n> non-zero), if there are regressions e.g. in how `git bisect start\n> --good=Ævar --bad=Dscho` behaves.\n\nIf users don't care about the specific exit code of failure modes why is\nyour series (the 11/16 noted above) going out of its way to change those\nexit codes?\n\n> So this hyper focus on what look like less relevant aspects is not only\n> irritating, it actively distracts me, others and even yourself from the\n> thorough review I would like to get: There have not been any thorough\n> reviews of this patch series so far, and I think it is because of this\n> here distraction.\n>\n> The cost of this distraction is quite real: not only is there a\n> performance penalty of running POSIX shell scripts on Windows, there are\n> also problems with anti-malware disliking the way the POSIX emulation\n> layer works that we currently have to use on Windows to run `git bisect`,\n> which would be fixed by `bisect` being a full built-in. This distracting\n> feedback that prevents a thorough code review delays that fix for those\n> users.\n>\n> To understand what I am aiming for, look at the deep analysis of the\n> rot13 filter conversion from Perl to C in\n> https://lore.kernel.org/git/4n20476q-6ssr-osp8-q5o3-p8ns726q4pn3@tzk.qr/,\n> where I carefully compared the behavior of the scripted code with the C\n> code that was designed to replace it.\n>\n> At this point, it is good to recall Parkinson's law of triviality:\n>\n> \tParkinson observed and illustrated that a committee whose job was\n> \tto approve plans for a nuclear power plant spent the majority of\n> \tits time with pointless discussions on relatively trivial and\n> \tunimportant but easy-to-grasp issues, such as what materials to\n> \tuse for the staff bike-shed, while neglecting the less-trivial\n> \tproposed design of the nuclear power plant itself, which is far\n> \tmore important but also a far more difficult and complex task to\n> \tcriticise constructively.\n>\n> We've seen quite a few regressions as of recent that would have likely\n> been prevented by thorough reviews that do not distract themselves with\n> tangents, pet peeves and personal taste.\n\nOne way to avoid regressions is to change fewer things, I've given you\nsome feedback about how you can accomplish the same things your series\nis trying to do with much less churn.\n\n> It would do good if we the reviewers on the Git mailing list took to heart\n> that Git is a software that millions of users depend on, not just our toy\n> to play with, and therefore the purpose of our reviews should aim to keep\n> Git working and safe. We will achieve that only if we avoid what Parkinson\n> called pointless discussions and instead put in the effort to provide\n> high-quality feedback that helps improve the design and the correctness of\n> the code.\n>\n> In this instance, the discussion about exit codes and usage messages\n> should be postponed, in favor of focusing on the actual scope of this\n> patch series.\n\nYou're replying downthread of a message where among other things I\npointed out a specific bug that's introduced in your series,\ni.e. exactly the sort of code correctness feedback you claim to be\nasking for.\n\nWhich is also a roundabout way of replying to your larger point\nhere. I.e. you're lamenting that I didn't provide you more feedback on\nthe specifics of your series.\n\nThat's true, but the reason I haven't spent time on doing that is from\npast experience with you routinely ignoring feedback on your patches.\n\nSo as pointed to you (and not for the first time) upthread this is still\nbroken:\n\n\t$ ./git --list-cmds=parseopt | grep -o bisect\n\tbisect\n\t$ ./git bisect --git-completion-helper\n\tusage: git bisect [help|start|bad|good|new|old|terms|skip|next|reset|visualize|view|replay|log|run]\n\nI.e. it should be:\n\n\t$ ./git --list-cmds=parseopt | grep -o bisect\n $\n\nThe fix on top of your series is easy:\n\t\n\tdiff --git a/git.c b/git.c\n\tindex 182ae9474de..ae99630b3c7 100644\n\t--- a/git.c\n\t+++ b/git.c\n\t@@ -492,7 +492,7 @@ static struct cmd_struct commands[] = {\n\t \t{ \"annotate\", cmd_annotate, RUN_SETUP },\n\t \t{ \"apply\", cmd_apply, RUN_SETUP_GENTLY },\n\t \t{ \"archive\", cmd_archive, RUN_SETUP_GENTLY },\n\t-\t{ \"bisect\", cmd_bisect, RUN_SETUP },\n\t+\t{ \"bisect\", cmd_bisect, RUN_SETUP | NO_PARSEOPT },\n\t \t{ \"blame\", cmd_blame, RUN_SETUP },\n\t \t{ \"branch\", cmd_branch, RUN_SETUP | DELAY_PAGER_CONFIG },\n\t \t{ \"bugreport\", cmd_bugreport, RUN_SETUP_GENTLY },\n\nI think your participation in reviews would be much improved if you\nreplied more point-by-point, e.g. the initial report of this specific\nissue in your series has been sitting on-list for 2 months ([1]) without\na follow-up.\n\nWhen you do send something in reply it shows that you either haven't\nread the feedback on your own series, or are deciding to actively ignore\nit (but without really clarifying that that's what you're doing in those\nspecific cases). Or perhps you've just not understood what I've pointed\nout to you (which might be on me). In any case having the discussion on\nthe original thread would be much more productive.\n\n1. https://lore.kernel.org/git/220627.86mtdxhnwk.gmgdl@evledraar.gmail.com/\n"}]}