* What's cooking in git.git (Jul 2022, #03; Mon, 11) @ 2022-07-12 17:07 Junio C Hamano 2022-07-12 22:19 ` gc/bare-repo-discovery (was Re: What's cooking in git.git (Jul 2022, #03; Mon, 11)) Glen Choo ` (3 more replies) 0 siblings, 4 replies; 17+ messages in thread From: Junio C Hamano @ 2022-07-12 17:07 UTC (permalink / raw) To: git Here are the topics that have been cooking in my tree. Commits prefixed with '+' are in 'next' (being in 'next' is a sign that a topic is stable enough to be used and are candidate to be in a future release). Commits prefixed with '-' are only in 'seen', and aren't considered "accepted" at all. Maintenance releases v2.37.1 and others have been tagged. They are to address CVE-2022-29187, a vulnerability related to CVE-2022-24765 that was fixed earlier. Big thanks to Carlo Arenas and Johannes Schindelin for fixing the issue and helping the releases out. Copies of the source code to Git live in many repositories, and the following is a list of the ones I push into or their mirrors. Some repositories have only a subset of branches. With maint, master, next, seen, todo: git://git.kernel.org/pub/scm/git/git.git/ git://repo.or.cz/alt-git.git/ https://kernel.googlesource.com/pub/scm/git/git/ https://github.com/git/git/ https://gitlab.com/git-vcs/git/ With all the integration branches and topics broken out: https://github.com/gitster/git/ Even though the preformatted documentation in HTML and man format are not sources, they are published in these repositories for convenience (replace "htmldocs" with "manpages" for the manual pages): git://git.kernel.org/pub/scm/git/git-htmldocs.git/ https://github.com/gitster/git-htmldocs.git/ Release tarballs are available at: https://www.kernel.org/pub/software/scm/git/ -------------------------------------------------- [Graduated to 'master'] * ac/bitmap-format-doc (2022-06-16) 3 commits (merged to 'next' on 2022-06-16 at 5591d11601) + bitmap-format.txt: add information for trailing checksum + bitmap-format.txt: fix some formatting issues + bitmap-format.txt: feed the file to asciidoc to generate html Adjust technical/bitmap-format to be formatted by AsciiDoc, and add some missing information to the documentation. source: <pull.1246.v4.git.1655355834.gitgitgadget@gmail.com> * cr/setup-bug-typo (2022-06-17) 1 commit (merged to 'next' on 2022-06-17 at 8834ffe0ab) + setup: fix function name in a BUG() message Typofix in a BUG() message. source: <pull.1255.git.1654782920256.gitgitgadget@gmail.com> * ds/branch-checked-out (2022-06-21) 7 commits (merged to 'next' on 2022-06-21 at e42bc4566f) + branch: drop unused worktrees variable + fetch: stop passing around unused worktrees variable (merged to 'next' on 2022-06-17 at c881874257) + branch: fix branch_checked_out() leaks + branch: use branch_checked_out() when deleting refs + fetch: use new branch_checked_out() and add tests + branch: check for bisects and rebases + branch: add branch_checked_out() helper (this branch is used by ds/rebase-update-ref.) Introduce a helper to see if a branch is already being worked on (hence should not be newly checked out in a working tree), which performs much better than the existing find_shared_symref() to replace many uses of the latter. source: <pull.1254.v2.git.1655234853.gitgitgadget@gmail.com> * ds/vscode-settings (2022-06-27) 1 commit (merged to 'next' on 2022-07-02 at fcbd2e7aca) + vscode: improve tab size and wrapping Will merge to 'master'. source: <pull.1271.git.1656354587496.gitgitgadget@gmail.com> * jk/optim-promisor-object-enumeration (2022-06-16) 1 commit (merged to 'next' on 2022-06-16 at ce0712a74c) + is_promisor_object(): walk promisor packs in pack-order Collection of what is referenced by objects in promisor packs have been optimized to inspect these objects in the in-pack order. source: <YqrTsbXbEjx0Pabn@coredump.intra.peff.net> * jk/revisions-doc-markup-fix (2022-06-22) 1 commit (merged to 'next' on 2022-07-02 at e25dbe8cfb) + revisions.txt: escape "..." to avoid asciidoc horizontal ellipsis Documentation mark-up fix. source: <YrOmsA04FZae89be@coredump.intra.peff.net> * pb/diff-doc-raw-format (2022-06-13) 3 commits (merged to 'next' on 2022-07-02 at 198480cbc6) + diff-index.txt: update raw output format in examples + diff-format.txt: correct misleading wording + diff-format.txt: dst can be 0* SHA-1 when path is deleted, too Update "git diff/log --raw" format documentation. source: <pull.1259.git.1655123383.gitgitgadget@gmail.com> * rs/archive-with-internal-gzip (2022-06-15) 6 commits (merged to 'next' on 2022-06-17 at ab5af6acd1) + archive-tar: use internal gzip by default + archive-tar: use OS_CODE 3 (Unix) for internal gzip + archive-tar: add internal gzip implementation + archive-tar: factor out write_block() + archive: rename archiver data field to filter_command + archive: update format documentation Teach "git archive" to (optionally and then by default) avoid spawning an external "gzip" process when creating ".tar.gz" (and ".tgz") archives. source: <9df761c3-355a-ede9-7971-b32687fe9abb@web.de> * rs/combine-diff-with-incompatible-options (2022-06-21) 2 commits (merged to 'next' on 2022-07-02 at 0fe8b80a3e) + combine-diff: abort if --output is given + combine-diff: abort if --ignore-matching-lines is given Certain diff options are currently ignored when combined-diff is shown; mark them as incompatible with the feature. source: <220524.86v8tuvfl1.gmgdl@evledraar.gmail.com> -------------------------------------------------- [New Topics] * po/doc-add-renormalize (2022-07-09) 1 commit - doc add: renormalize is not idempotent for CRCRLF Documentation for "git add --renormalize" has been improved. Will merge to 'next'? source: <d3b8ed97a105ea1d7e656c964b7eee378e11ede6.1657385781.git.gitgitgadget@gmail.com> * po/glossary-around-traversal (2022-07-09) 3 commits - glossary: add reachability bitmap description - glossary: add commit graph description - glossary: add Object DataBase (ODB) abbreviation The glossary entries for "commit-graph file" and "reachability bitmap" have been added. Will merge to 'next'? source: <pull.1282.git.1657385781.gitgitgadget@gmail.com> * rs/cocci-array-copy (2022-07-10) 1 commit - cocci: avoid normalization rules for memcpy A coccinelle rule (in contrib/) to encourage use of COPY_ARRAY macro has been improved. Will merge to 'next'. source: <ded153d4-4aea-d4da-11cb-ec66d181e4c9@web.de> * sg/multi-pack-index-parse-options-fix (2022-07-10) 1 commit (merged to 'next' on 2022-07-11 at 1e14685680) + multi-pack-index: simplify handling of unknown --options The way "git multi-pack" uses parse-options API has been improved. Will merge to 'master'. source: <20220710151645.GA2038@szeder.dev> * jk/ref-filter-discard-commit-buffer (2022-07-11) 1 commit - ref-filter: disable save_commit_buffer while traversing source: <Ysw4JtoHW1vWmqhz@coredump.intra.peff.net> -------------------------------------------------- [Stalled] * ll/curl-accept-language (2022-07-11) 1 commit - remote-curl: send Accept-Language header to server Earlier, HTTP transport clients learned to tell the server side what locale they are in by sending Accept-Language HTTP header, but this was done only for some requests but not others. Will merge to 'next'. source: <pull.1251.v4.git.1657519134336.gitgitgadget@gmail.com> * bc/stash-export (2022-04-08) 4 commits - builtin/stash: provide a way to import stashes from a ref - builtin/stash: provide a way to export stashes to a ref - builtin/stash: factor out revision parsing into a function - object-name: make get_oid quietly return an error A mechanism to export and import stash entries to and from a normal commit to transfer it across repositories has been introduced. Expecting a reroll. cf. <YnL2d4Vr9Vr7W4Hj@camp.crustytoothpaste.net> source: <20220407215352.3491567-1-sandals@crustytoothpaste.net> * cw/remote-object-info (2022-05-06) 11 commits - SQUASH??? coccicheck - SQUASH??? ensure that coccicheck is happy - SQUASH??? compilation fix - cat-file: add --batch-command remote-object-info command - cat-file: move parse_cmd and DEFAULT_FORMAT up - transport: add object-info fallback to fetch - transport: add client side capability to request object-info - object-info: send attribute packet regardless of object ids - object-store: add function to free object_info contents - fetch-pack: move fetch default settings - fetch-pack: refactor packet writing A client component to talk with the object-info endpoint. Expecting a reroll. source: <20220502170904.2770649-1-calvinwan@google.com> -------------------------------------------------- [Cooking] * ab/cocci-unused (2022-07-06) 6 commits (merged to 'next' on 2022-07-11 at 7fa60d2a5b) + cocci: generalize "unused" rule to cover more than "strbuf" + cocci: add and apply a rule to find "unused" strbufs + cocci: have "coccicheck{,-pending}" depend on "coccicheck-test" + cocci: add a "coccicheck-test" target and test *.cocci rules + Makefile & .gitignore: ignore & clean "git.res", not "*.res" + Makefile: remove mandatory "spatch" arguments from SPATCH_FLAGS Add Coccinelle rules to detect the pattern of initializing and then finalizing a structure without using it in between at all, which happens after code restructuring and the compilers fail to recognize as an unused varilable. Will merge to 'master'. source: <cover-v4-0.6-00000000000-20220705T134033Z-avarab@gmail.com> * jk/clone-unborn-confusion (2022-07-11) 4 commits - clone: move unborn head creation to update_head() - clone: use remote branch if it matches default HEAD - clone: propagate empty remote HEAD even with other branches - clone: drop extra newline from warning message "git clone" from a repository with some ref whose HEAD is unborn did not set the HEAD in the resulting repository correctly, which has been corrected. Will merge to 'next'. source: <YsdyLS4UFzj0j/wB@coredump.intra.peff.net> source: <YsvrsOH1jg559yVt@coredump.intra.peff.net> * ac/bitmap-lookup-table (2022-07-06) 6 commits - p5310-pack-bitmaps.sh: remove pack.writeReverseIndex - bitmap-lookup-table: add performance tests for lookup table - pack-bitmap: prepare to read lookup table extension - pack-bitmap-write: learn pack.writeBitmapLookupTable and add tests - pack-bitmap-write.c: write lookup table extension - Documentation/technical: describe bitmap lookup table extension The pack bitmap file gained a bitmap-lookup table to speed up locating the necessary bitmap for a given commit. Will merge to 'next'? source: <pull.1266.v3.git.1656924376.gitgitgadget@gmail.com> * bc/nettle-sha256 (2022-07-10) 1 commit (merged to 'next' on 2022-07-11 at cf9595d8ca) + sha256: add support for Nettle Support for libnettle as SHA256 implementation has been added. Will merge to 'master'. source: <20220710132907.1499365-1-sandals@crustytoothpaste.net> * jc/builtin-mv-move-array (2022-07-09) 1 commit (merged to 'next' on 2022-07-09 at 0d3b3f62e5) + builtin/mv.c: use the MOVE_ARRAY() macro instead of memmove() Apply Coccinelle rule to turn raw memmove() into MOVE_ARRAY() cpp macro, which would improve maintainability and readability. Will merge to 'master'. source: <xmqq4jzpu4xp.fsf_-_@gitster.g> * jd/gpg-interface-trust-level-string (2022-07-10) 1 commit (merged to 'next' on 2022-07-11 at 7b3cca73a8) + gpg-interface: add function for converting trust level to string The code to convert between GPG trust level strings and internal constants we use to represent them have been cleaned up. Will merge to 'master'. source: <pull.1281.v4.git.1657515650587.gitgitgadget@gmail.com> * kk/p4-client-name-encoding-fix (2022-07-08) 1 commit (merged to 'next' on 2022-07-11 at 9c18616f76) + git-p4: fix bug with encoding of p4 client name "git p4" did not handle non-ASCII client name well, which has been corrected. Will merge to 'master'. source: <pull.1285.git.git.1657267260405.gitgitgadget@gmail.com> * sa/cat-file-mailmap (2022-07-09) 4 commits - cat-file: add mailmap support - ident: rename commit_rewrite_person() to apply_mailmap_to_header() - ident: move commit_rewrite_person() to ident.c - revision: improve commit_rewrite_person() "git cat-file" learned an option to use the mailmap when showing commit and tag objects. source: <20220709154149.165524-1-siddharthasthana31@gmail.com> * fr/vimdiff-layout-fix (2022-07-08) 1 commit (merged to 'next' on 2022-07-09 at d8461bd236) + vimdiff: make layout engine more robust against user vim settings Recent update to vimdiff layout code has been made more robust against different end-user vim settings. Will merge to 'master'. source: <20220708181024.45839-1-greenfoo@u92.eu> * ds/git-rebase-doc-markup (2022-06-30) 1 commit (merged to 'next' on 2022-07-08 at 24a0b80b71) + git-rebase.txt: use back-ticks consistently References to commands-to-be-typed-literally in "git rebase" documentation mark-up have been corrected. Will merge to 'master'. source: <pull.1270.v3.git.1656508868146.gitgitgadget@gmail.com> * ds/rebase-update-ref (2022-06-28) 8 commits - rebase: add rebase.updateRefs config option - rebase: update refs from 'update-ref' commands - rebase: add --update-refs option - sequencer: add update-ref command - sequencer: define array with enum values - rebase-interactive: update 'merge' description - branch: consider refs under 'update-refs' - t2407: test branches currently using apply backend "git rebase -i" learns to update branches whose tip appear in the rebased range. Expecting a reroll. cf. <15631ea2-6722-fd24-c8a6-0cee638b0602@github.com> source: <pull.1247.v3.git.1656422759.gitgitgadget@gmail.com> * tb/pack-objects-remove-pahole-comment (2022-06-28) 1 commit (merged to 'next' on 2022-07-06 at d7494fbdef) + pack-objects.h: remove outdated pahole results Comment fix. Will merge to 'master'. source: <1379af2e9d271b501ef3942398e7f159a9c77973.1656440978.git.me@ttaylorr.com> * ab/leakfix (2022-07-01) 11 commits (merged to 'next' on 2022-07-11 at 0b107fffcf) + pull: fix a "struct oid_array" memory leak + cat-file: fix a common "struct object_context" memory leak + gc: fix a memory leak + checkout: avoid "struct unpack_trees_options" leak + merge-file: fix memory leaks on error path + merge-file: refactor for subsequent memory leak fix + cat-file: fix a memory leak in --batch-command mode + revert: free "struct replay_opts" members + submodule.c: free() memory from xgetcwd() + clone: fix memory leak in wanted_peer_refs() + check-ref-format: fix trivial memory leak Plug various memory leaks. Will merge to 'master'. source: <cover-v2-00.11-00000000000-20220701T104017Z-avarab@gmail.com> * ab/test-tool-leakfix (2022-07-01) 9 commits (merged to 'next' on 2022-07-11 at db7a724694) + test-tool delta: fix a memory leak + test-tool ref-store: fix a memory leak + test-tool bloom: fix memory leaks + test-tool json-writer: fix memory leaks + test-tool regex: call regfree(), fix memory leaks + test-tool urlmatch-normalization: fix a memory leak + test-tool {dump,scrap}-cache-tree: fix memory leaks + test-tool path-utils: fix a memory leak + test-tool test-hash: fix a memory leak Plug various memory leaks in test-tool commands. Will merge to 'master'. source: <cover-v2-0.9-00000000000-20220701T103503Z-avarab@gmail.com> * en/t6429-test-must-be-empty-fix (2022-06-30) 1 commit (merged to 'next' on 2022-07-06 at 627c51773c) + t6429: fix use of non-existent function A test fix. Will merge to 'master'. source: <pull.1276.git.1656652799863.gitgitgadget@gmail.com> * gc/submodule-use-super-prefix (2022-06-30) 8 commits (merged to 'next' on 2022-07-11 at 0d9cf172f9) + submodule--helper: remove display path helper + submodule--helper update: use --super-prefix + submodule--helper: remove unused SUPPORT_SUPER_PREFIX flags + submodule--helper: use correct display path helper + submodule--helper: don't recreate recursive prefix + submodule--helper update: use display path helper + submodule--helper tests: add missing "display path" coverage + Merge branch 'ab/submodule-cleanup' into gc/submodule-use-super-prefix (this branch uses ab/submodule-cleanup.) Another step to rewrite more parts of "git submodule" in C. Will merge to 'master'. source: <20220701021157.88858-1-chooglen@google.com> * hx/lookup-commit-in-graph-fix (2022-06-30) 1 commit (merged to 'next' on 2022-07-08 at cef32db0b6) + commit-graph.c: no lazy fetch in lookup_commit_in_graph() A corner case bug where lazily fetching objects from a promisor remote resulted in infinite recursion has been corrected. Will merge to 'master'. source: <96d4bb71505d87ed501c058bbd89bfc13d08b24a.1656593279.git.hanxin.hx@bytedance.com> * ll/ls-files-tests-update (2022-07-06) 1 commit (merged to 'next' on 2022-07-06 at 444d1eabd0) + ls-files: update test style Test update. Will merge to 'master'. source: <pull.1269.v6.git.1656863349926.gitgitgadget@gmail.com> * pw/xdiff-alloc (2022-07-08) 4 commits - xdiff: introduce XDL_ALLOC_GROW() - xdiff: introduce XDL_CALLOC_ARRAY() - xdiff: introduce xdl_calloc - xdiff: introduce XDL_ALLOC_ARRAY() Add a level of redirection to array allocation API in xdiff part, to make it easier to share with the libgit2 project. Will merge to 'next'? source: <pull.1272.v2.git.1657297519.gitgitgadget@gmail.com> * sy/mv-out-of-cone (2022-07-01) 8 commits (merged to 'next' on 2022-07-08 at 654970fdb7) + mv: add check_dir_in_index() and solve general dir check issue + mv: use flags mode for update_mode + mv: check if <destination> exists in index to handle overwriting + mv: check if out-of-cone file exists in index with SKIP_WORKTREE bit + mv: decouple if/else-if checks using goto + mv: update sparsity after moving from out-of-cone to in-cone + t1092: mv directory from out-of-cone to in-cone + t7002: add tests for moving out-of-cone file/directory "git mv A B" in a sparsely populated working tree can be asked to move a path between directories that are "in cone" (i.e. expected to be materialized in the working tree) and "out of cone" (i.e. expected to be hidden). The handling of such cases has been improved. Will merge to 'master'. source: <20220630023737.473690-1-shaoxuan.yuan02@gmail.com> * ab/squelch-empty-fsync-traces (2022-06-30) 1 commit . trace2: don't include "fsync" events in all trace2 logs Omit fsync-related trace2 entries when their values are all zero. Breaks tests in hx/unpack-streaming with an interesting interaction. source: <patch-v2-1.1-a1fc37de947-20220630T084607Z-avarab@gmail.com> * cl/grep-max-count (2022-06-22) 1 commit (merged to 'next' on 2022-07-08 at 646199ab4c) + grep: add --max-count command line option "git grep -m<max-hits>" is a way to limit the hits shown per file. Will merge to 'master'. source: <pull.1278.v4.git.git.1655927252899.gitgitgadget@gmail.com> * tk/rev-parse-doc-clarify-at-u (2022-06-23) 1 commit (merged to 'next' on 2022-07-08 at 1075452f32) + rev-parse: documentation adjustment - mention remote tracking with @{u} Doc update. Will merge to 'master'. source: <pull.1265.v2.git.1655960512385.gitgitgadget@gmail.com> * en/merge-tree (2022-06-22) 17 commits (merged to 'next' on 2022-07-08 at a29b4896ab) + git-merge-tree.txt: add a section on potentional usage mistakes + merge-tree: add a --allow-unrelated-histories flag + merge-tree: allow `ls-files -u` style info to be NUL terminated + merge-ort: optionally produce machine-readable output + merge-ort: store more specific conflict information + merge-ort: make `path_messages` a strmap to a string_list + merge-ort: store messages in a list, not in a single strbuf + merge-tree: provide easy access to `ls-files -u` style info + merge-tree: provide a list of which files have conflicts + merge-ort: remove command-line-centric submodule message from merge-ort + merge-ort: provide a merge_get_conflicted_files() helper function + merge-tree: support including merge messages in output + merge-ort: split out a separate display_update_messages() function + merge-tree: implement real merges + merge-tree: add option parsing and initial shell for real merge function + merge-tree: move logic for existing merge into new function + merge-tree: rename merge_trees() to trivial_merge_trees() A new command is introduced that takes two commits and computes a tree that would be contained in the resulting merge commit, if the histories leading to these two commits were to be merged, and is added as a new mode of "git merge-tree" subcommand. Will merge to 'master'. source: <pull.1122.v7.git.1655511660.gitgitgadget@gmail.com> * dr/i18n-die-warn-error-usage (2022-06-21) 1 commit (merged to 'next' on 2022-07-08 at 6f639750a1) + i18n: mark message helpers prefix for translation Give _() markings to fatal/warning/usage: labels that are shown in front of these messages. Will merge to 'master'. source: <pull.1279.v2.git.git.1655819877758.gitgitgadget@gmail.com> * ds/t5510-brokequote (2022-06-21) 1 commit (merged to 'next' on 2022-07-06 at 2776bed385) + t5510: replace 'origin' with URL more carefully Test fix. Will merge to 'master'. source: <484a330e-0902-6e1b-8189-63c72dcea494@github.com> * en/merge-restore-to-pristine (2022-06-21) 6 commits - merge: do not exit restore_state() prematurely - merge: ensure we can actually restore pre-merge state - merge: make restore_state() restore staged state too - merge: fix save_state() to work when there are racy-dirty files - merge: remove unused variable - t6424: make sure a failed merge preserves local changes When "git merge" finds that it cannot perform a merge, it should restore the working tree to the state before the command was initiated, but in some corner cases it didn't. Needs review. source: <pull.1231.v2.git.1655621424.gitgitgadget@gmail.com> * tk/apply-case-insensitive (2022-06-21) 3 commits - apply: support case-only renames in case-insensitive filesystems - reset: new failing test for reset of case-insensitive duplicate in index - t4141: test "git apply" with core.ignorecase "git apply" barfed on a patch that makes a case-only rename on a case-insensitive filesystem. Needs review. source: <pull.1257.v2.git.1655655027.gitgitgadget@gmail.com> * zh/ls-files-format (2022-07-11) 1 commit - ls-files: introduce "--format" option "git ls-files" learns the "--format" option to tweak its output. Getting closer to finish? cf. <xmqqleszl2p0.fsf@gitster.g> source: <pull.1262.v6.git.1657558435532.gitgitgadget@gmail.com> * ab/test-quoting-fix (2022-06-30) 3 commits (merged to 'next' on 2022-07-06 at 0aa78fd9db) + config tests: fix harmless but broken "rm -r" cleanup + test-lib.sh: fix prepend_var() quoting issue + tests: add missing double quotes to included library paths Fixes for tests when the source directory has unusual characters in its path, e.g. whitespaces, double-quotes, etc. Will merge to 'master'. source: <cover-v2-0.3-00000000000-20220630T101646Z-avarab@gmail.com> * en/merge-dual-dir-renames-fix (2022-07-06) 5 commits (merged to 'next' on 2022-07-11 at 5f8dadf87b) + merge-ort: fix issue with dual rename and add/add conflict + merge-ort: shuffle the computation and cleanup of potential collisions + merge-ort: make a separate function for freeing struct collisions + merge-ort: small cleanups of check_for_directory_rename + t6423: add tests of dual directory rename plus add/add conflict Fixes a long-standing corner case bug around directory renames in the merge-ort strategy. Will merge to 'master'. source: <pull.1268.v4.git.1656984823.gitgitgadget@gmail.com> * zk/push-use-bitmaps (2022-06-17) 1 commit (merged to 'next' on 2022-07-08 at 8aa1f94fad) + send-pack.c: add config push.useBitmaps "git push" sometimes perform poorly when reachability bitmaps are used, even in a repository where other operations are helped by bitmaps. The push.useBitmaps configuration variable is introduced to allow disabling use of reachability bitmaps only for "git push". Will merge to 'master'. source: <pull.1263.v4.git.1655492779228.gitgitgadget@gmail.com> * jk/remote-show-with-negative-refspecs (2022-06-17) 1 commit (merged to 'next' on 2022-07-08 at d4e49ad22a) + remote: handle negative refspecs in git remote show (this branch is used by jk/t5505-restructure.) "git remote show [-n] frotz" now pays attention to negative pathspecs. Will merge to 'master'. source: <20220617002036.1577-2-jacob.keller@gmail.com> * js/commit-graph-parsing-without-repo-settings (2022-06-15) 1 commit - commit-graph: refactor to avoid prepare_repo_settings Expecting a reroll. source: <9b56496b0809cc8a25af877ea97042e2cb7f2af6.1655246092.git.steadmon@google.com> * ro/mktree-allow-missing-fix (2022-06-21) 1 commit (merged to 'next' on 2022-07-08 at 599ed6fb84) + mktree: do not check type of remote objects "git mktree --missing" lazily fetched objects that are missing from the local object store, which was totally unnecessary for the purpose of creating the tree object(s) from its input. Will merge to 'master'. source: <748f39a9-65aa-2110-cf92-7ddf81b5f507@roku.com> * jt/connected-show-missing-from-which-side (2022-06-10) 1 commit - fetch,fetch-pack: clarify connectivity check error We may find an object missing after a "git fetch" stores the objects it obtained from the other side, but it is not necessarily because the remote failed to send necessary objects. Reword the messages in an attempt to help users explore other possibilities when they hit this error. Expecting a reroll. source: <20220610195247.1177549-1-jonathantanmy@google.com> * ab/submodule-cleanup (2022-06-28) 12 commits (merged to 'next' on 2022-07-08 at 6f3886aa03) + git-sh-setup.sh: remove "say" function, change last users + git-submodule.sh: use "$quiet", not "$GIT_QUIET" + submodule--helper: eliminate internal "--update" option + submodule--helper: understand --checkout, --merge and --rebase synonyms + submodule--helper: report "submodule" as our name in some "-h" output + submodule--helper: rename "absorb-git-dirs" to "absorbgitdirs" + submodule update: remove "-v" option + submodule--helper: have --require-init imply --init + git-submodule.sh: remove unused top-level "--branch" argument + git-submodule.sh: make the "$cached" variable a boolean + git-submodule.sh: remove unused $prefix variable + git-submodule.sh: remove unused sanitize_submodule_env() (this branch is used by gc/submodule-use-super-prefix.) Further preparation to turn git-submodule.sh into a builtin. Will merge to 'master'. source: <cover-v4-00.12-00000000000-20220628T095914Z-avarab@gmail.com> * jc/resolve-undo (2022-07-11) 2 commits - fsck: do not dereference NULL while checking resolve-undo data (merged to 'next' on 2022-06-15 at c195e5a2d9) + revision: mark blobs needed for resolve-undo as reachable The resolve-undo information in the index was not protected against GC, which has been corrected. Will merge to 'next'. source: <xmqqfskdieqz.fsf@gitster.g> * ab/build-gitweb (2022-06-28) 8 commits (merged to 'next' on 2022-07-11 at 731e354ff0) + gitweb/Makefile: add a "NO_GITWEB" parameter + Makefile: build 'gitweb' in the default target + gitweb/Makefile: include in top-level Makefile + gitweb: remove "test" and "test-installed" targets + gitweb/Makefile: prepare to merge into top-level Makefile + gitweb/Makefile: clear up and de-duplicate the gitweb.{css,js} vars + gitweb/Makefile: add a $(GITWEB_ALL) variable + gitweb/Makefile: define all .PHONY prerequisites inline Teach "make all" to build gitweb as well. Will merge to 'master'. source: <cover-v3-0.8-00000000000-20220628T100936Z-avarab@gmail.com> * ab/test-without-templates (2022-06-06) 7 commits (merged to 'next' on 2022-07-11 at afab6c1918) + tests: don't assume a .git/info for .git/info/sparse-checkout + tests: don't assume a .git/info for .git/info/exclude + tests: don't assume a .git/info for .git/info/refs + tests: don't assume a .git/info for .git/info/attributes + tests: don't assume a .git/info for .git/info/grafts + tests: don't depend on template-created .git/branches + t0008: don't rely on default ".git/info/exclude" Tweak tests so that they still work when the "git init" template did not create .git/info directory. Will merge to 'master'. source: <cover-v2-0.7-00000000000-20220603T110506Z-avarab@gmail.com> * hx/unpack-streaming (2022-06-13) 6 commits (merged to 'next' on 2022-07-08 at 4eb375ec2f) + unpack-objects: use stream_loose_object() to unpack large objects + core doc: modernize core.bigFileThreshold documentation + object-file.c: add "stream_loose_object()" to handle large object + object-file.c: factor out deflate part of write_loose_object() + object-file.c: refactor write_loose_object() to several steps + unpack-objects: low memory footprint for get_data() in dry_run mode Allow large objects read from a packstream to be streamed into a loose object file straight, without having to keep it in-core as a whole. Will merge to 'master'. source: <cover.1654914555.git.chiyutianyi@gmail.com> * tb/show-ref-count (2022-06-06) 2 commits - builtin/show-ref.c: limit output with `--count` - builtin/show-ref.c: rename `found_match` to `matches_nr` "git show-ref" learned to stop after emitting N refs with the new "--count=N" option. Expecting a reroll. cf. <xmqqczfl4ce1.fsf@gitster.g> source: <cover.1654552560.git.me@ttaylorr.com> * ds/bundle-uri-more (2022-06-06) 6 commits - fetch: add 'refs/bundle/' to log.excludeDecoration - bundle-uri: add support for http(s):// and file:// - fetch: add --bundle-uri option - bundle-uri: create basic file-copy logic - remote-curl: add 'get' capability - docs: document bundle URI standard The "bundle URI" topic. Needs review. source: <pull.1248.git.1654545325.gitgitgadget@gmail.com> * js/bisect-in-c (2022-06-27) 16 commits - bisect: no longer try to clean up left-over `.git/head-name` files - bisect: remove Cogito-related code - Turn `git bisect` into a full built-in - bisect: move even the command-line parsing to `bisect--helper` - bisect: teach the `bisect--helper` command to show the correct usage strings - bisect--helper: return only correct exit codes in `cmd_*()` - bisect--helper: move the `BISECT_STATE` case to the end - bisect--helper: make `--bisect-state` optional - bisect--helper: align the sub-command order with git-bisect.sh - bisect--helper: using `--bisect-state` without an argument is a bug - bisect--helper: really retire `--bisect-autostart` - bisect--helper: really retire --bisect-next-check - bisect--helper: retire the --no-log option - bisect: avoid double-quoting when printing the failed command - bisect run: fix the error message - bisect: verify that a bogus option won't try to start a bisection Final bits of "git bisect.sh" have been rewritten in C. Expecting a (hopefully final) reroll. cf. <20627.86ilolhnnn.gmgdl@evledraar.gmail.com> source: <pull.1132.v4.git.1656354677.gitgitgadget@gmail.com> * gc/bare-repo-discovery (2022-07-07) 5 commits - setup.c: create `discovery.bare` - safe.directory: use git_protected_config() - config: learn `git_protected_config()` - Documentation: define protected configuration - Documentation/git-config.txt: add SCOPES section Introduce a discovery.barerepository configuration variable that allows users to forbid discovery of bare repositories. Will merge to 'next'? source: <pull.1261.v7.git.git.1657234914.gitgitgadget@gmail.com> * gg/worktree-from-the-above (2022-06-21) 2 commits (merged to 'next' on 2022-07-08 at fa0e71ba39) + dir: minor refactoring / clean-up + dir: traverse into repository In a non-bare repository, the behavior of Git when the core.worktree configuration variable points at a directory that has a repository as its subdirectory, regressed in Git 2.27 days. Will merge to 'master'. source: <20220616234433.225-1-gg.oss@outlook.com> source: <20220616231956.154-1-gg.oss@outlook.com> -------------------------------------------------- [Discarded] * ar/send-email-confirm-by-default (2022-04-22) 1 commit . send-email: always confirm by default "git send-email" is changed so that by default it asks for confirmation before sending each message out. Discarded. I wanted to like this, and had it in the version of Git I use myself for daily work, but the prompting turned out to be somewhat distracting. source: <20220422083629.1404989-1-hi@alyssa.is> ^ permalink raw reply [flat|nested] 17+ messages in thread
* gc/bare-repo-discovery (was Re: What's cooking in git.git (Jul 2022, #03; Mon, 11)) 2022-07-12 17:07 What's cooking in git.git (Jul 2022, #03; Mon, 11) Junio C Hamano @ 2022-07-12 22:19 ` Glen Choo 2022-07-13 16:29 ` Junio C Hamano 2022-07-12 22:29 ` What's cooking in git.git (Jul 2022, #03; Mon, 11) Philip Oakley ` (2 subsequent siblings) 3 siblings, 1 reply; 17+ messages in thread From: Glen Choo @ 2022-07-12 22:19 UTC (permalink / raw) To: Junio C Hamano, git Junio C Hamano <gitster@pobox.com> writes: > Maintenance releases v2.37.1 and others have been tagged. They are > to address CVE-2022-29187, a vulnerability related to CVE-2022-24765 > that was fixed earlier. Big thanks to Carlo Arenas and Johannes > Schindelin for fixing the issue and helping the releases out. \o/ thanks everyone! > * gc/bare-repo-discovery (2022-07-07) 5 commits > - setup.c: create `discovery.bare` > - safe.directory: use git_protected_config() > - config: learn `git_protected_config()` > - Documentation: define protected configuration > - Documentation/git-config.txt: add SCOPES section > > Introduce a discovery.barerepository configuration variable that > allows users to forbid discovery of bare repositories. > > Will merge to 'next'? > source: <pull.1261.v7.git.git.1657234914.gitgitgadget@gmail.com> I have a (hopefully final) reroll planned that takes your documentation suggestions. I think it reads a lot better with those, so thanks! I also noted your distaste for the `discovery.*` namespace (fair enough). To avoid a reroll-of-the-reroll, I was hoping that we could agree on something on-list (thread here [1]) before I send out the next version. [1] https://lore.kernel.org/git/kl6lsfn656cw.fsf@chooglen-macbookpro.roam.corp.google.com ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: gc/bare-repo-discovery (was Re: What's cooking in git.git (Jul 2022, #03; Mon, 11)) 2022-07-12 22:19 ` gc/bare-repo-discovery (was Re: What's cooking in git.git (Jul 2022, #03; Mon, 11)) Glen Choo @ 2022-07-13 16:29 ` Junio C Hamano 2022-07-14 16:17 ` Johannes Schindelin 0 siblings, 1 reply; 17+ messages in thread From: Junio C Hamano @ 2022-07-13 16:29 UTC (permalink / raw) To: Glen Choo; +Cc: git Glen Choo <chooglen@google.com> writes: > I also noted your distaste for the `discovery.*` namespace (fair > enough). To avoid a reroll-of-the-reroll, I was hoping that we could > agree on something on-list (thread here [1]) before I send out the next > version. I found your idea of adding this new one in the safe.* hierarchy quite reasonable. "safe.discoveredBareRepository = yes / no" may be quote a mouthful, but I do not think I can think of anything better. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: gc/bare-repo-discovery (was Re: What's cooking in git.git (Jul 2022, #03; Mon, 11)) 2022-07-13 16:29 ` Junio C Hamano @ 2022-07-14 16:17 ` Johannes Schindelin 2022-07-14 18:27 ` Junio C Hamano 0 siblings, 1 reply; 17+ messages in thread From: Johannes Schindelin @ 2022-07-14 16:17 UTC (permalink / raw) To: Junio C Hamano; +Cc: Glen Choo, git Hi, On Wed, 13 Jul 2022, Junio C Hamano wrote: > Glen Choo <chooglen@google.com> writes: > > > I also noted your distaste for the `discovery.*` namespace (fair > > enough). To avoid a reroll-of-the-reroll, I was hoping that we could > > agree on something on-list (thread here [1]) before I send out the next > > version. > > I found your idea of adding this new one in the safe.* hierarchy > quite reasonable. "safe.discoveredBareRepository = yes / no" may be > quote a mouthful, but I do not think I can think of anything better. I would find `safe.bareRepository = true` or `false` more intuitive, and more concise. And if there should be an option to ignore bare repositories when discovering a Git repository, it could be a tristate, with `ignore` being the value to trigger that mode. Thanks, Dscho ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: gc/bare-repo-discovery (was Re: What's cooking in git.git (Jul 2022, #03; Mon, 11)) 2022-07-14 16:17 ` Johannes Schindelin @ 2022-07-14 18:27 ` Junio C Hamano 0 siblings, 0 replies; 17+ messages in thread From: Junio C Hamano @ 2022-07-14 18:27 UTC (permalink / raw) To: Johannes Schindelin; +Cc: Glen Choo, git Johannes Schindelin <Johannes.Schindelin@gmx.de> writes: > I would find `safe.bareRepository = true` or `false` more intuitive, and > more concise. Yup, that is fine by me. > And if there should be an option to ignore bare repositories when > discovering a Git repository, it could be a tristate, with `ignore` being > the value to trigger that mode. Sounds good. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: What's cooking in git.git (Jul 2022, #03; Mon, 11) 2022-07-12 17:07 What's cooking in git.git (Jul 2022, #03; Mon, 11) Junio C Hamano 2022-07-12 22:19 ` gc/bare-repo-discovery (was Re: What's cooking in git.git (Jul 2022, #03; Mon, 11)) Glen Choo @ 2022-07-12 22:29 ` Philip Oakley 2022-07-13 16:31 ` Junio C Hamano 2022-07-12 23:28 ` ac/bitmap-lookup-table (was: Re: What's cooking in git.git (Jul 2022, #03; Mon, 11)) Taylor Blau 2022-07-13 11:10 ` js/bisect-in-c, was Re: What's cooking in git.git (Jul 2022, #03; Mon, 11) Johannes Schindelin 3 siblings, 1 reply; 17+ messages in thread From: Philip Oakley @ 2022-07-12 22:29 UTC (permalink / raw) To: Junio C Hamano, git On 12/07/2022 18:07, Junio C Hamano wrote: > [New Topics] > > * po/doc-add-renormalize (2022-07-09) 1 commit > - doc add: renormalize is not idempotent for CRCRLF > > Documentation for "git add --renormalize" has been improved. > > Will merge to 'next'? > source: <d3b8ed97a105ea1d7e656c964b7eee378e11ede6.1657385781.git.gitgitgadget@gmail.com> > > > * po/glossary-around-traversal (2022-07-09) 3 commits > - glossary: add reachability bitmap description > - glossary: add commit graph description > - glossary: add Object DataBase (ODB) abbreviation > > The glossary entries for "commit-graph file" and "reachability > bitmap" have been added. > > Will merge to 'next'? > source: <pull.1282.git.1657385781.gitgitgadget@gmail.com> I'm expecting to do a re-roll for both these, though I'm just recovering from an infection. If you could hold off for a few days that would be great. -- Philip ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: What's cooking in git.git (Jul 2022, #03; Mon, 11) 2022-07-12 22:29 ` What's cooking in git.git (Jul 2022, #03; Mon, 11) Philip Oakley @ 2022-07-13 16:31 ` Junio C Hamano 0 siblings, 0 replies; 17+ messages in thread From: Junio C Hamano @ 2022-07-13 16:31 UTC (permalink / raw) To: Philip Oakley; +Cc: git Philip Oakley <philipoakley@iee.email> writes: > I'm expecting to do a re-roll for both these, though I'm just recovering > from an infection. > If you could hold off for a few days that would be great. Be well soon and take care of yourself. Thanks, will relabel them to "Expecting a reroll". ^ permalink raw reply [flat|nested] 17+ messages in thread
* ac/bitmap-lookup-table (was: Re: What's cooking in git.git (Jul 2022, #03; Mon, 11)) 2022-07-12 17:07 What's cooking in git.git (Jul 2022, #03; Mon, 11) Junio C Hamano 2022-07-12 22:19 ` gc/bare-repo-discovery (was Re: What's cooking in git.git (Jul 2022, #03; Mon, 11)) Glen Choo 2022-07-12 22:29 ` What's cooking in git.git (Jul 2022, #03; Mon, 11) Philip Oakley @ 2022-07-12 23:28 ` Taylor Blau 2022-07-13 16:42 ` ac/bitmap-lookup-table Junio C Hamano 2022-07-13 11:10 ` js/bisect-in-c, was Re: What's cooking in git.git (Jul 2022, #03; Mon, 11) Johannes Schindelin 3 siblings, 1 reply; 17+ messages in thread From: Taylor Blau @ 2022-07-12 23:28 UTC (permalink / raw) To: Junio C Hamano; +Cc: git, Abhradeep Chakraborty Hi Junio, On Tue, Jul 12, 2022 at 10:07:44AM -0700, Junio C Hamano wrote: > * ac/bitmap-lookup-table (2022-07-06) 6 commits > - p5310-pack-bitmaps.sh: remove pack.writeReverseIndex > - bitmap-lookup-table: add performance tests for lookup table > - pack-bitmap: prepare to read lookup table extension > - pack-bitmap-write: learn pack.writeBitmapLookupTable and add tests > - pack-bitmap-write.c: write lookup table extension > - Documentation/technical: describe bitmap lookup table extension > > The pack bitmap file gained a bitmap-lookup table to speed up > locating the necessary bitmap for a given commit. > > Will merge to 'next'? > source: <pull.1266.v3.git.1656924376.gitgitgadget@gmail.com> I think that this version is pretty close to being ready, but I haven't had a chance to look it over carefully yet since getting back from my time off last week. I should have time to review this in the next day or two, if neither of you mind waiting. Thanks, Taylor ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: ac/bitmap-lookup-table 2022-07-12 23:28 ` ac/bitmap-lookup-table (was: Re: What's cooking in git.git (Jul 2022, #03; Mon, 11)) Taylor Blau @ 2022-07-13 16:42 ` Junio C Hamano 0 siblings, 0 replies; 17+ messages in thread From: Junio C Hamano @ 2022-07-13 16:42 UTC (permalink / raw) To: Taylor Blau; +Cc: git, Abhradeep Chakraborty Taylor Blau <me@ttaylorr.com> writes: > Hi Junio, > > On Tue, Jul 12, 2022 at 10:07:44AM -0700, Junio C Hamano wrote: >> * ac/bitmap-lookup-table (2022-07-06) 6 commits >> - p5310-pack-bitmaps.sh: remove pack.writeReverseIndex >> - bitmap-lookup-table: add performance tests for lookup table >> - pack-bitmap: prepare to read lookup table extension >> - pack-bitmap-write: learn pack.writeBitmapLookupTable and add tests >> - pack-bitmap-write.c: write lookup table extension >> - Documentation/technical: describe bitmap lookup table extension >> >> The pack bitmap file gained a bitmap-lookup table to speed up >> locating the necessary bitmap for a given commit. >> >> Will merge to 'next'? >> source: <pull.1266.v3.git.1656924376.gitgitgadget@gmail.com> > > I think that this version is pretty close to being ready, but I haven't > had a chance to look it over carefully yet since getting back from my > time off last week. > > I should have time to review this in the next day or two, if neither of > you mind waiting. Thanks! ^ permalink raw reply [flat|nested] 17+ messages in thread
* js/bisect-in-c, was Re: What's cooking in git.git (Jul 2022, #03; Mon, 11) 2022-07-12 17:07 What's cooking in git.git (Jul 2022, #03; Mon, 11) Junio C Hamano ` (2 preceding siblings ...) 2022-07-12 23:28 ` ac/bitmap-lookup-table (was: Re: What's cooking in git.git (Jul 2022, #03; Mon, 11)) Taylor Blau @ 2022-07-13 11:10 ` Johannes Schindelin 2022-07-13 11:18 ` Ævar Arnfjörð Bjarmason 3 siblings, 1 reply; 17+ messages in thread From: Johannes Schindelin @ 2022-07-13 11:10 UTC (permalink / raw) To: Junio C Hamano; +Cc: git Hi Junio, On Tue, 12 Jul 2022, Junio C Hamano wrote: > * js/bisect-in-c (2022-06-27) 16 commits > - bisect: no longer try to clean up left-over `.git/head-name` files > - bisect: remove Cogito-related code > - Turn `git bisect` into a full built-in > - bisect: move even the command-line parsing to `bisect--helper` > - bisect: teach the `bisect--helper` command to show the correct usage strings > - bisect--helper: return only correct exit codes in `cmd_*()` > - bisect--helper: move the `BISECT_STATE` case to the end > - bisect--helper: make `--bisect-state` optional > - bisect--helper: align the sub-command order with git-bisect.sh > - bisect--helper: using `--bisect-state` without an argument is a bug > - bisect--helper: really retire `--bisect-autostart` > - bisect--helper: really retire --bisect-next-check > - bisect--helper: retire the --no-log option > - bisect: avoid double-quoting when printing the failed command > - bisect run: fix the error message > - bisect: verify that a bogus option won't try to start a bisection > > Final bits of "git bisect.sh" have been rewritten in C. > > Expecting a (hopefully final) reroll. > cf. <20627.86ilolhnnn.gmgdl@evledraar.gmail.com> I did not find that one, but I found https://lore.kernel.org/git/220627.86ilolhnnn.gmgdl@evledraar.gmail.com/ And that claims that Git has a convention to universally exit with code 129 when options are passed with incorrect values. That claim does not survive even minimal contact with Git's source code, though. If I find some time, I will respond to that mail, but a reroll is actually unnecessary. > source: <pull.1132.v4.git.1656354677.gitgitgadget@gmail.com> Thanks, Dscho ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: js/bisect-in-c, was Re: What's cooking in git.git (Jul 2022, #03; Mon, 11) 2022-07-13 11:10 ` js/bisect-in-c, was Re: What's cooking in git.git (Jul 2022, #03; Mon, 11) Johannes Schindelin @ 2022-07-13 11:18 ` Ævar Arnfjörð Bjarmason 2022-07-13 16:01 ` Junio C Hamano 0 siblings, 1 reply; 17+ messages in thread From: Ævar Arnfjörð Bjarmason @ 2022-07-13 11:18 UTC (permalink / raw) To: Johannes Schindelin; +Cc: Junio C Hamano, git On Wed, Jul 13 2022, Johannes Schindelin wrote: > Hi Junio, > > On Tue, 12 Jul 2022, Junio C Hamano wrote: > >> * js/bisect-in-c (2022-06-27) 16 commits >> - bisect: no longer try to clean up left-over `.git/head-name` files >> - bisect: remove Cogito-related code >> - Turn `git bisect` into a full built-in >> - bisect: move even the command-line parsing to `bisect--helper` >> - bisect: teach the `bisect--helper` command to show the correct usage strings >> - bisect--helper: return only correct exit codes in `cmd_*()` >> - bisect--helper: move the `BISECT_STATE` case to the end >> - bisect--helper: make `--bisect-state` optional >> - bisect--helper: align the sub-command order with git-bisect.sh >> - bisect--helper: using `--bisect-state` without an argument is a bug >> - bisect--helper: really retire `--bisect-autostart` >> - bisect--helper: really retire --bisect-next-check >> - bisect--helper: retire the --no-log option >> - bisect: avoid double-quoting when printing the failed command >> - bisect run: fix the error message >> - bisect: verify that a bogus option won't try to start a bisection >> >> Final bits of "git bisect.sh" have been rewritten in C. >> >> Expecting a (hopefully final) reroll. >> cf. <20627.86ilolhnnn.gmgdl@evledraar.gmail.com> > > I did not find that one, but I found > https://lore.kernel.org/git/220627.86ilolhnnn.gmgdl@evledraar.gmail.com/ > > And that claims that Git has a convention to universally exit with code > 129 when options are passed with incorrect values. > > That claim does not survive even minimal contact with Git's source > code, though. I'm not claiming that we always use 129 when we're fed bad options etc., but rather that that's what parse_options() does, so at this point most commands do that consistently. ./git --blah >/dev/null 2>&1; echo $? 129 ./git status --blah >/dev/null 2>&1; echo $? 129 But yes, you can find exceptions still, e.g. try that with "git log" and it'll return 128. Your series migrates the bisect--helper.c away from parse_options() in a a way that I don't think is necessary, but leaving that aside mimicking the exit codes we'd get from parse_options() for those cases you're handling in your custom parsing seems like a good thing. > If I find some time, I will respond to that mail, but a reroll is actually > unnecessary. There's some more in [1], but there's at least one outstanding bug in this series, i.e. that you're moving away from parse_options(), but forgot to change the corresponding flag in git.c for the built-in. That's then used by the completion mechanism. But as noted in [2] and more recently in [1] I'm most concerned about us having outstanding bugs due to past iterations of this having played whack-a-mole in fixing specific edge cases I found, but not gone back and added missing test coverage for the series beforehand. Which, I'm not saying should hold this series up, but just that having reviewed it for a few iterations I'm not comfortable saying we haven't missed something else, and given the nature of the past whack-a-mole fixes it looks like you haven't really looked it either. I'm referring to e.g. the thread ending at [3], where I pointed out that "git <subcommand> -h" was broken, you apparently tested one of the subcommands and concluded it wasn't broken, but clearly not all of them. Which, I'd be less concerned about if as pointed out in [1] we don't have entirte bisect sub-commands that don't have any test coverage at all, so whatever coverage we have probably has major gaps. 1. https://lore.kernel.org/git/220627.86mtdxhnwk.gmgdl@evledraar.gmail.com/ 2. https://lore.kernel.org/git/220523.865ylwzgji.gmgdl@evledraar.gmail.com/ 3. https://lore.kernel.org/git/220225.86ilt27uln.gmgdl@evledraar.gmail.com/ ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: js/bisect-in-c, was Re: What's cooking in git.git (Jul 2022, #03; Mon, 11) 2022-07-13 11:18 ` Ævar Arnfjörð Bjarmason @ 2022-07-13 16:01 ` Junio C Hamano 2022-07-14 0:22 ` Ævar Arnfjörð Bjarmason 2022-07-14 19:35 ` Johannes Schindelin 0 siblings, 2 replies; 17+ messages in thread From: Junio C Hamano @ 2022-07-13 16:01 UTC (permalink / raw) To: Ævar Arnfjörð Bjarmason; +Cc: Johannes Schindelin, git Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes: > I'm not claiming that we always use 129 when we're fed bad options etc., > but rather that that's what parse_options() does, so at this point most > commands do that consistently. > > ./git --blah >/dev/null 2>&1; echo $? > 129 > ./git status --blah >/dev/null 2>&1; echo $? > 129 > > But yes, you can find exceptions still, e.g. try that with "git log" and > it'll return 128. Yup, that was my understanding as well. We may have existing breakage that we shouldn't be actively imitating when we do not have to. > Which, I'm not saying should hold this series up, but just that having > reviewed it for a few iterations I'm not comfortable saying we haven't > missed something else, and given the nature of the past whack-a-mole > fixes it looks like you haven't really looked it either. "We haven't missed" is not something we can comfortably say, ever, aobut a series with any meaningful size. I am not so worried about it, if it is your only worries. Would it make it less likely to have introduced unintended bugs if we find a way to keep using parse-options? > I'm referring to e.g. the thread ending at [3], where I pointed out that > "git <subcommand> -h" was broken, you apparently tested one of the > subcommands and concluded it wasn't broken, but clearly not all of them. > > Which, I'd be less concerned about if as pointed out in [1] we don't > have entirte bisect sub-commands that don't have any test coverage at > all, so whatever coverage we have probably has major gaps. > > 1. https://lore.kernel.org/git/220627.86mtdxhnwk.gmgdl@evledraar.gmail.com/ > 2. https://lore.kernel.org/git/220523.865ylwzgji.gmgdl@evledraar.gmail.com/ > 3. https://lore.kernel.org/git/220225.86ilt27uln.gmgdl@evledraar.gmail.com/ ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: js/bisect-in-c, was Re: What's cooking in git.git (Jul 2022, #03; Mon, 11) 2022-07-13 16:01 ` Junio C Hamano @ 2022-07-14 0:22 ` Ævar Arnfjörð Bjarmason 2022-07-14 19:35 ` Johannes Schindelin 1 sibling, 0 replies; 17+ messages in thread From: Ævar Arnfjörð Bjarmason @ 2022-07-14 0:22 UTC (permalink / raw) To: Junio C Hamano; +Cc: Johannes Schindelin, git On Wed, Jul 13 2022, Junio C Hamano wrote: > Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes: > >> I'm not claiming that we always use 129 when we're fed bad options etc., >> but rather that that's what parse_options() does, so at this point most >> commands do that consistently. >> >> ./git --blah >/dev/null 2>&1; echo $? >> 129 >> ./git status --blah >/dev/null 2>&1; echo $? >> 129 >> >> But yes, you can find exceptions still, e.g. try that with "git log" and >> it'll return 128. > > Yup, that was my understanding as well. We may have existing > breakage that we shouldn't be actively imitating when we do not have > to. > >> Which, I'm not saying should hold this series up, but just that having >> reviewed it for a few iterations I'm not comfortable saying we haven't >> missed something else, and given the nature of the past whack-a-mole >> fixes it looks like you haven't really looked it either. > > "We haven't missed" is not something we can comfortably say, ever, > aobut a series with any meaningful size. I am not so worried about > it, if it is your only worries. Would it make it less likely to > have introduced unintended bugs if we find a way to keep using > parse-options? I started writing something here, but found myself rewriting the last 3 paragraphs of [1] seen in the context below, so I'll just refer to that. FWIW ejecting 11-14/16, i.e. these patches: - Turn `git bisect` into a full built-in - bisect: move even the command-line parsing to `bisect--helper` - bisect: teach the `bisect--helper` command to show the correct usage strings - bisect--helper: return only correct exit codes in `cmd_*()` Yields a result that I've got no concerns about whatsoever, and reduces the diffstat from: 7 files changed, 110 insertions(+), 207 deletions(-) To just: 4 files changed, 71 insertions(+), 67 deletions(-) Which I think might be worth considering, similar to how the submodule migration is happening in multi-step fashion. I.e. advancing the parts that don't migrate it away from parse_options(), since I showed a way to keep using it in [1] (while changing less code). Or just merge it down, up to you :) >> I'm referring to e.g. the thread ending at [3], where I pointed out that >> "git <subcommand> -h" was broken, you apparently tested one of the >> subcommands and concluded it wasn't broken, but clearly not all of them. >> >> Which, I'd be less concerned about if as pointed out in [1] we don't >> have entirte bisect sub-commands that don't have any test coverage at >> all, so whatever coverage we have probably has major gaps. >> >> 1. https://lore.kernel.org/git/220627.86mtdxhnwk.gmgdl@evledraar.gmail.com/ >> 2. https://lore.kernel.org/git/220523.865ylwzgji.gmgdl@evledraar.gmail.com/ >> 3. https://lore.kernel.org/git/220225.86ilt27uln.gmgdl@evledraar.gmail.com/ ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: js/bisect-in-c, was Re: What's cooking in git.git (Jul 2022, #03; Mon, 11) 2022-07-13 16:01 ` Junio C Hamano 2022-07-14 0:22 ` Ævar Arnfjörð Bjarmason @ 2022-07-14 19:35 ` Johannes Schindelin 2022-07-14 21:09 ` Ævar Arnfjörð Bjarmason 1 sibling, 1 reply; 17+ messages in thread From: Johannes Schindelin @ 2022-07-14 19:35 UTC (permalink / raw) To: Junio C Hamano; +Cc: Ævar Arnfjörð Bjarmason, git [-- Attachment #1: Type: text/plain, Size: 921 bytes --] Hi Junio, On Wed, 13 Jul 2022, Junio C Hamano wrote: > Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes: > > > I'm not claiming that we always use 129 when we're fed bad options etc., > > but rather that that's what parse_options() does, so at this point most > > commands do that consistently. > > > > ./git --blah >/dev/null 2>&1; echo $? > > 129 > > ./git status --blah >/dev/null 2>&1; echo $? > > 129 > > > > But yes, you can find exceptions still, e.g. try that with "git log" and > > it'll return 128. > > Yup, that was my understanding as well. We may have existing > breakage that we shouldn't be actively imitating when we do not have > to. This patch series already implements `git bisect` in the desired way: $ ./git bisect --invalid; echo $? usage: git bisect [help|start|bad|good|new|old|terms|skip|next|reset|visualize|view|replay|log|run] 129 Ciao, Johannes ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: js/bisect-in-c, was Re: What's cooking in git.git (Jul 2022, #03; Mon, 11) 2022-07-14 19:35 ` Johannes Schindelin @ 2022-07-14 21:09 ` Ævar Arnfjörð Bjarmason 2022-08-16 8:51 ` Johannes Schindelin 0 siblings, 1 reply; 17+ messages in thread From: Ævar Arnfjörð Bjarmason @ 2022-07-14 21:09 UTC (permalink / raw) To: Johannes Schindelin; +Cc: Junio C Hamano, git On Thu, Jul 14 2022, Johannes Schindelin wrote: > Hi Junio, > > On Wed, 13 Jul 2022, Junio C Hamano wrote: > >> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes: >> >> > I'm not claiming that we always use 129 when we're fed bad options etc., >> > but rather that that's what parse_options() does, so at this point most >> > commands do that consistently. >> > >> > ./git --blah >/dev/null 2>&1; echo $? >> > 129 >> > ./git status --blah >/dev/null 2>&1; echo $? >> > 129 >> > >> > But yes, you can find exceptions still, e.g. try that with "git log" and >> > it'll return 128. >> >> Yup, that was my understanding as well. We may have existing >> breakage that we shouldn't be actively imitating when we do not have >> to. > > This patch series already implements `git bisect` in the desired way: > > $ ./git bisect --invalid; echo $? > usage: git bisect [help|start|bad|good|new|old|terms|skip|next|reset|visualize|view|replay|log|run] > 129 It doesn't, the claim isn't that there's no way to have it return exit code 129 on *some* invalid usage. In this case we do the "right" thing. Rather that as noted in [1] there's other cases where we call die() and should call usage_msg_opt(). Of course both of those would be more useful if the new built-in still had the parse_options() usage info we could display. I.e. in this case the conversion to a built-in leaves on the table nice benefits we'd get for free. Compare that with e.g. how "git bundle" handles it, note how we get not only "don't do that", but also how valid usage would look like: $ git bundle -h usage: git bundle create [-q | --quiet | --progress | --all-progress] [--all-progress-implied] [--version=<version>] <file> <git-rev-list-args> or: git bundle verify [-q | --quiet] <file> or: git bundle fetch [--filter=<spec>] <uri> or: git bundle list-heads <file> [<refname>...] or: git bundle unbundle [--progress] <file> [<refname>...] $ git bundle create -h usage: git bundle create [-q | --quiet | --progress | --all-progress] [--all-progress-implied] [--version=<version>] <file> <git-rev-list-args> -q, --quiet do not show progress meter --progress show progress meter --all-progress show progress meter during object writing phase --all-progress-implied similar to --all-progress when progress meter is shown --version <n> specify bundle format version 1. https://lore.kernel.org/git/220627.86ilolhnnn.gmgdl@evledraar.gmail.com/ ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: js/bisect-in-c, was Re: What's cooking in git.git (Jul 2022, #03; Mon, 11) 2022-07-14 21:09 ` Ævar Arnfjörð Bjarmason @ 2022-08-16 8:51 ` Johannes Schindelin 2022-08-17 0:49 ` Ævar Arnfjörð Bjarmason 0 siblings, 1 reply; 17+ messages in thread From: Johannes Schindelin @ 2022-08-16 8:51 UTC (permalink / raw) To: Ævar Arnfjörð Bjarmason; +Cc: Junio C Hamano, git [-- Attachment #1: Type: text/plain, Size: 5349 bytes --] Hi Ævar, On Thu, 14 Jul 2022, Ævar Arnfjörð Bjarmason wrote: > On Thu, Jul 14 2022, Johannes Schindelin wrote: > > > On Wed, 13 Jul 2022, Junio C Hamano wrote: > > > >> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes: > >> > >> > I'm not claiming that we always use 129 when we're fed bad options etc., > >> > but rather that that's what parse_options() does, so at this point most > >> > commands do that consistently. > >> > > >> > ./git --blah >/dev/null 2>&1; echo $? > >> > 129 > >> > ./git status --blah >/dev/null 2>&1; echo $? > >> > 129 > >> > > >> > But yes, you can find exceptions still, e.g. try that with "git log" and > >> > it'll return 128. > >> > >> Yup, that was my understanding as well. We may have existing > >> breakage that we shouldn't be actively imitating when we do not have > >> to. > > > > This patch series already implements `git bisect` in the desired way: > > > > $ ./git bisect --invalid; echo $? > > usage: git bisect [help|start|bad|good|new|old|terms|skip|next|reset|visualize|view|replay|log|run] > > 129 > > It doesn't, the claim isn't that there's no way to have it return exit > code 129 on *some* invalid usage. In this case we do the "right" thing. > > Rather that as noted in [1] there's other cases where we call die() and > should call usage_msg_opt(). It would have been better to take the time to spell out clearly that you are taking offense in `git bisect start -h` not behaving in the way you think is the rule in Git: to print a _subcommand_ usage and exit with code 129. However, this feedback fails to recognize the scope of this patch series. The patch series' intention is not to fix anything that is currently broken. And it is already broken, my patch series does not introduce that breakage (and it would make more sense to address this breakage _after_ the conversion, to avoid doubling the effort): The current output of `git bisect start -h` shows the usage of `bisect--helper`! Instead, the scope of the patch series is to finalize converting the `bisect` command to a full built-in, implemented in C, and avoiding the portability cost of running a POSIX shell script. Note: I agree with you that it would be nice for `git bisect start -h` to output a proper usage. There will be a time to discuss that, that time is just simply not right now. Since the scope is so different from what your feedback suggests, I have to admit that it taxes my patience to see that laser focus on aspects that are almost irrelevant compared to the aspects that should concern any good review of this series: the correctness of the conversion, with a heavy focus on the non-failure modes. No user would care about the exit code of a failure mode (as long as it is non-zero), if there are regressions e.g. in how `git bisect start --good=Ævar --bad=Dscho` behaves. So this hyper focus on what look like less relevant aspects is not only irritating, it actively distracts me, others and even yourself from the thorough review I would like to get: There have not been any thorough reviews of this patch series so far, and I think it is because of this here distraction. The cost of this distraction is quite real: not only is there a performance penalty of running POSIX shell scripts on Windows, there are also problems with anti-malware disliking the way the POSIX emulation layer works that we currently have to use on Windows to run `git bisect`, which would be fixed by `bisect` being a full built-in. This distracting feedback that prevents a thorough code review delays that fix for those users. To understand what I am aiming for, look at the deep analysis of the rot13 filter conversion from Perl to C in https://lore.kernel.org/git/4n20476q-6ssr-osp8-q5o3-p8ns726q4pn3@tzk.qr/, where I carefully compared the behavior of the scripted code with the C code that was designed to replace it. At this point, it is good to recall Parkinson's law of triviality: Parkinson observed and illustrated that a committee whose job was to approve plans for a nuclear power plant spent the majority of its time with pointless discussions on relatively trivial and unimportant but easy-to-grasp issues, such as what materials to use for the staff bike-shed, while neglecting the less-trivial proposed design of the nuclear power plant itself, which is far more important but also a far more difficult and complex task to criticise constructively. We've seen quite a few regressions as of recent that would have likely been prevented by thorough reviews that do not distract themselves with tangents, pet peeves and personal taste. It would do good if we the reviewers on the Git mailing list took to heart that Git is a software that millions of users depend on, not just our toy to play with, and therefore the purpose of our reviews should aim to keep Git working and safe. We will achieve that only if we avoid what Parkinson called pointless discussions and instead put in the effort to provide high-quality feedback that helps improve the design and the correctness of the code. In this instance, the discussion about exit codes and usage messages should be postponed, in favor of focusing on the actual scope of this patch series. Ciao, Johannes ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: js/bisect-in-c, was Re: What's cooking in git.git (Jul 2022, #03; Mon, 11) 2022-08-16 8:51 ` Johannes Schindelin @ 2022-08-17 0:49 ` Ævar Arnfjörð Bjarmason 0 siblings, 0 replies; 17+ messages in thread From: Ævar Arnfjörð Bjarmason @ 2022-08-17 0:49 UTC (permalink / raw) To: Johannes Schindelin; +Cc: Junio C Hamano, git On Tue, Aug 16 2022, Johannes Schindelin wrote: > Hi Ævar, > > On Thu, 14 Jul 2022, Ævar Arnfjörð Bjarmason wrote: > >> On Thu, Jul 14 2022, Johannes Schindelin wrote: >> >> > On Wed, 13 Jul 2022, Junio C Hamano wrote: >> > >> >> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes: >> >> >> >> > I'm not claiming that we always use 129 when we're fed bad options etc., >> >> > but rather that that's what parse_options() does, so at this point most >> >> > commands do that consistently. >> >> > >> >> > ./git --blah >/dev/null 2>&1; echo $? >> >> > 129 >> >> > ./git status --blah >/dev/null 2>&1; echo $? >> >> > 129 >> >> > >> >> > But yes, you can find exceptions still, e.g. try that with "git log" and >> >> > it'll return 128. >> >> >> >> Yup, that was my understanding as well. We may have existing >> >> breakage that we shouldn't be actively imitating when we do not have >> >> to. >> > >> > This patch series already implements `git bisect` in the desired way: >> > >> > $ ./git bisect --invalid; echo $? >> > usage: git bisect [help|start|bad|good|new|old|terms|skip|next|reset|visualize|view|replay|log|run] >> > 129 >> >> It doesn't, the claim isn't that there's no way to have it return exit >> code 129 on *some* invalid usage. In this case we do the "right" thing. >> >> Rather that as noted in [1] there's other cases where we call die() and >> should call usage_msg_opt(). > > It would have been better to take the time to spell out clearly that you > are taking offense in `git bisect start -h` not behaving in the way you > think is the rule in Git: to print a _subcommand_ usage and exit with code > 129. > > However, this feedback fails to recognize the scope of this patch series. No, I'm pointing out that you could *also* get more benefit from moving more towards the way we do things with other sub-commands in builtin/bisect.c. But the core feedback was on your 11/16 (https://lore.kernel.org/git/ce508583e455a1dbb7620a238edb11dae195f00d.1656354677.git.gitgitgadget@gmail.com/) changing ("correct[ing") the return code If we're going out of our way to change the behavior of bisect while-we're-at-it let's change it to the actually correct thing. I think Junio concurred with that here: https://lore.kernel.org/git/xmqqtu7ldmrz.fsf@gitster.g/ > The patch series' intention is not to fix anything that is currently > broken. And it is already broken, my patch series does not introduce that > breakage. I think that would be completely fair if it aimed to bug-for-bug re-implement the current git-bisect.sh behavior, without the unnecessary while-we're-at-it changes. > (and it would make more sense to address this breakage _after_ > the conversion, to avoid doubling the effort): The current output of `git > bisect start -h` shows the usage of `bisect--helper`! > > Instead, the scope of the patch series is to finalize converting the > `bisect` command to a full built-in, implemented in C, and avoiding the > portability cost of running a POSIX shell script. > > Note: I agree with you that it would be nice for `git bisect start -h` to > output a proper usage. There will be a time to discuss that, that time is > just simply not right now. I agree with all of that, but that's not what I've been pointing out to you, except to note that your bisect.sh->C conversion is making some subsequent follow-up work harder than it needs to be. > Since the scope is so different from what your feedback suggests, I have > to admit that it taxes my patience to see that laser focus on aspects that > are almost irrelevant compared to the aspects that should concern any > good review of this series: the correctness of the conversion, with a > heavy focus on the non-failure modes. ... > No user would care about the exit code of a failure mode (as long as it is > non-zero), if there are regressions e.g. in how `git bisect start > --good=Ævar --bad=Dscho` behaves. If users don't care about the specific exit code of failure modes why is your series (the 11/16 noted above) going out of its way to change those exit codes? > So this hyper focus on what look like less relevant aspects is not only > irritating, it actively distracts me, others and even yourself from the > thorough review I would like to get: There have not been any thorough > reviews of this patch series so far, and I think it is because of this > here distraction. > > The cost of this distraction is quite real: not only is there a > performance penalty of running POSIX shell scripts on Windows, there are > also problems with anti-malware disliking the way the POSIX emulation > layer works that we currently have to use on Windows to run `git bisect`, > which would be fixed by `bisect` being a full built-in. This distracting > feedback that prevents a thorough code review delays that fix for those > users. > > To understand what I am aiming for, look at the deep analysis of the > rot13 filter conversion from Perl to C in > https://lore.kernel.org/git/4n20476q-6ssr-osp8-q5o3-p8ns726q4pn3@tzk.qr/, > where I carefully compared the behavior of the scripted code with the C > code that was designed to replace it. > > At this point, it is good to recall Parkinson's law of triviality: > > Parkinson observed and illustrated that a committee whose job was > to approve plans for a nuclear power plant spent the majority of > its time with pointless discussions on relatively trivial and > unimportant but easy-to-grasp issues, such as what materials to > use for the staff bike-shed, while neglecting the less-trivial > proposed design of the nuclear power plant itself, which is far > more important but also a far more difficult and complex task to > criticise constructively. > > We've seen quite a few regressions as of recent that would have likely > been prevented by thorough reviews that do not distract themselves with > tangents, pet peeves and personal taste. One way to avoid regressions is to change fewer things, I've given you some feedback about how you can accomplish the same things your series is trying to do with much less churn. > It would do good if we the reviewers on the Git mailing list took to heart > that Git is a software that millions of users depend on, not just our toy > to play with, and therefore the purpose of our reviews should aim to keep > Git working and safe. We will achieve that only if we avoid what Parkinson > called pointless discussions and instead put in the effort to provide > high-quality feedback that helps improve the design and the correctness of > the code. > > In this instance, the discussion about exit codes and usage messages > should be postponed, in favor of focusing on the actual scope of this > patch series. You're replying downthread of a message where among other things I pointed out a specific bug that's introduced in your series, i.e. exactly the sort of code correctness feedback you claim to be asking for. Which is also a roundabout way of replying to your larger point here. I.e. you're lamenting that I didn't provide you more feedback on the specifics of your series. That's true, but the reason I haven't spent time on doing that is from past experience with you routinely ignoring feedback on your patches. So as pointed to you (and not for the first time) upthread this is still broken: $ ./git --list-cmds=parseopt | grep -o bisect bisect $ ./git bisect --git-completion-helper usage: git bisect [help|start|bad|good|new|old|terms|skip|next|reset|visualize|view|replay|log|run] I.e. it should be: $ ./git --list-cmds=parseopt | grep -o bisect $ The fix on top of your series is easy: diff --git a/git.c b/git.c index 182ae9474de..ae99630b3c7 100644 --- a/git.c +++ b/git.c @@ -492,7 +492,7 @@ static struct cmd_struct commands[] = { { "annotate", cmd_annotate, RUN_SETUP }, { "apply", cmd_apply, RUN_SETUP_GENTLY }, { "archive", cmd_archive, RUN_SETUP_GENTLY }, - { "bisect", cmd_bisect, RUN_SETUP }, + { "bisect", cmd_bisect, RUN_SETUP | NO_PARSEOPT }, { "blame", cmd_blame, RUN_SETUP }, { "branch", cmd_branch, RUN_SETUP | DELAY_PAGER_CONFIG }, { "bugreport", cmd_bugreport, RUN_SETUP_GENTLY }, I think your participation in reviews would be much improved if you replied more point-by-point, e.g. the initial report of this specific issue in your series has been sitting on-list for 2 months ([1]) without a follow-up. When you do send something in reply it shows that you either haven't read the feedback on your own series, or are deciding to actively ignore it (but without really clarifying that that's what you're doing in those specific cases). Or perhps you've just not understood what I've pointed out to you (which might be on me). In any case having the discussion on the original thread would be much more productive. 1. https://lore.kernel.org/git/220627.86mtdxhnwk.gmgdl@evledraar.gmail.com/ ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2022-08-17 1:38 UTC | newest] Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-07-12 17:07 What's cooking in git.git (Jul 2022, #03; Mon, 11) Junio C Hamano 2022-07-12 22:19 ` gc/bare-repo-discovery (was Re: What's cooking in git.git (Jul 2022, #03; Mon, 11)) Glen Choo 2022-07-13 16:29 ` Junio C Hamano 2022-07-14 16:17 ` Johannes Schindelin 2022-07-14 18:27 ` Junio C Hamano 2022-07-12 22:29 ` What's cooking in git.git (Jul 2022, #03; Mon, 11) Philip Oakley 2022-07-13 16:31 ` Junio C Hamano 2022-07-12 23:28 ` ac/bitmap-lookup-table (was: Re: What's cooking in git.git (Jul 2022, #03; Mon, 11)) Taylor Blau 2022-07-13 16:42 ` ac/bitmap-lookup-table Junio C Hamano 2022-07-13 11:10 ` js/bisect-in-c, was Re: What's cooking in git.git (Jul 2022, #03; Mon, 11) Johannes Schindelin 2022-07-13 11:18 ` Ævar Arnfjörð Bjarmason 2022-07-13 16:01 ` Junio C Hamano 2022-07-14 0:22 ` Ævar Arnfjörð Bjarmason 2022-07-14 19:35 ` Johannes Schindelin 2022-07-14 21:09 ` Ævar Arnfjörð Bjarmason 2022-08-16 8:51 ` Johannes Schindelin 2022-08-17 0:49 ` Ævar Arnfjörð Bjarmason
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).