{"thread":{"id":"58310","subject":"What's cooking in git.git (Aug 2022, #05; Mon, 15)","startedAt":"2022-08-16T01:34:32Z","lastAt":"2022-08-19T15:10:31Z","messageCount":13,"participants":["Junio C Hamano","Johannes Schindelin","Victoria Dye","Elijah Newren","Shaoxuan Yuan","Ævar Arnfjörð Bjarmason"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"461257","messageId":"xmqq5yityzcu.fsf@gitster.g","threadId":"58310","inReplyTo":null,"subject":"What's cooking in git.git (Aug 2022, #05; Mon, 15)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-08-15T21:24:17Z","receivedAt":"2022-08-16T01:34:32Z","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 future\nrelease). Commits prefixed with '-' are only in 'seen', and aren't\nconsidered \"accepted\" at all. A topic without enough support may be\ndiscarded after a long period of no activity.\n\nWe are at the beginning of the week #6 of a 12-week cycle (cf.\nhttps://tinyurl.com/gitCal).\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* ab/hooks-regression-fix (2022-08-05) 1 commit\n (merged to 'next' on 2022-08-08 at f5a3f88983)\n + hook API: don't segfault on strbuf_addf() to NULL \"out\"\n\n A follow-up fix to a fix for a regression in 2.36.\n source: \n\n\n* ab/leak-check (2022-07-27) 15 commits\n (merged to 'next' on 2022-08-05 at 2a6b9c8432)\n + CI: use \"GIT_TEST_SANITIZE_LEAK_LOG=true\" in linux-leaks\n + upload-pack: fix a memory leak in create_pack_file()\n + leak tests: mark passing SANITIZE=leak tests as leak-free\n + leak tests: don't skip some tests under SANITIZE=leak\n + test-lib: have the \"check\" mode for SANITIZE=leak consider leak logs\n + test-lib: add a GIT_TEST_PASSING_SANITIZE_LEAK=check mode\n + test-lib: simplify by removing test_external\n + tests: move copy/pasted PERL + Test::More checks to a lib-perl.sh\n + t/Makefile: don't remove test-results in \"clean-except-prove-cache\"\n + test-lib: add a SANITIZE=leak logging mode\n + t/README: reword the \"GIT_TEST_PASSING_SANITIZE_LEAK\" description\n + test-lib: add a --invert-exit-code switch\n + test-lib: fix GIT_EXIT_OK logic errors, use BAIL_OUT\n + test-lib: don't set GIT_EXIT_OK before calling test_atexit_handler\n + test-lib: use $1, not $@ in test_known_broken_{ok,failure}_\n\n Extend SANITIZE=leak checking and declare more tests \"currently leak-free\".\n source: \n\n\n* ab/plug-revisions-leak (2022-08-03) 6 commits\n (merged to 'next' on 2022-08-05 at d1ca88976f)\n + revisions API: don't leak memory on argv elements that need free()-ing\n + bisect.c: partially fix bisect_rev_setup() memory leak\n + log: refactor \"rev.pending\" code in cmd_show()\n + log: fix a memory leak in \"git show ...\"\n + test-fast-rebase helper: use release_revisions() (again)\n + bisect.c: add missing \"goto\" for release_revisions()\n\n Plug a bit more leaks in the revisions API.\n source: \n\n\n* ab/tech-docs-to-help (2022-08-04) 12 commits\n (merged to 'next' on 2022-08-08 at 65c9ec7308)\n + docs: move http-protocol docs to man section 5\n + docs: move cruft pack docs to gitformat-pack\n + docs: move pack format docs to man section 5\n + docs: move signature docs to man section 5\n + docs: move index format docs to man section 5\n + docs: move protocol-related docs to man section 5\n + docs: move commit-graph format docs to man section 5\n + git docs: add a category for file formats, protocols and interfaces\n + git docs: add a category for user-facing file, repo and command UX\n + git help doc: use \"\" instead of \"\"\n + help.c: remove common category behavior from drop_prefix() behavior\n + help.c: refactor drop_prefix() to use a \"switch\" statement\"\n\n Expose a lot of \"tech docs\" via \"git help\" interface.\n source: \n\n\n* gc/git-reflog-doc-markup (2022-08-01) 1 commit\n (merged to 'next' on 2022-08-05 at f2d8721ab2)\n + Documentation/git-reflog: remove unneeded \\ from \\{\n\n Doc mark-up fix.\n source: \n\n\n* jc/rerere-autoupdate-doc (2022-08-03) 2 commits\n (merged to 'next' on 2022-08-08 at 6407091d13)\n + doc: clarify rerere-autoupdate\n + doc: consolidate --rerere-autoupdate description\n\n Update documentation on the \"--[no-]rerere-autoupdate\" option.\n source: \n\n\n* js/safe-directory-plus (2022-08-08) 5 commits\n (merged to 'next' on 2022-08-10 at 3d32a87210)\n + mingw: handle a file owned by the Administrators group correctly\n + mingw: be more informative when ownership check fails on FAT32\n + mingw: provide details about unsafe directories' ownership\n + setup: prepare for more detailed \"dubious ownership\" messages\n + setup: fix some formatting\n\n Platform-specific code that determines if a directory is OK to use\n as a repository has been taught to report more details, especially\n on Windows.\n source: \n\n\n* lt/symbolic-ref-sanity (2022-08-01) 1 commit\n (merged to 'next' on 2022-08-03 at 443647b94a)\n + symbolic-ref: refuse to set syntactically invalid target\n\n \"git symbolic-ref symref non..sen..se\" is now diagnosed as an error.\n source: \n\n\n* pw/use-glibc-tunable-for-malloc-optim (2022-08-04) 1 commit\n (merged to 'next' on 2022-08-08 at 1300f84dc4)\n + tests: cache glibc version check\n\n Avoid repeatedly running getconf to ask libc version in the test\n suite, and instead just as it once per script.\n source: \n\n--------------------------------------------------\n[New Topics]\n\n* ll/disk-usage-humanise (2022-08-11) 1 commit\n (merged to 'next' on 2022-08-14 at 3873a83f90)\n + rev-list: support human-readable output for `--disk-usage`\n\n \"git rev-list --disk-usage\" learned to take an optional value\n \"human\" to show the reported value in human-readable format, like\n \"3.40MiB\".\n\n Will merge to 'master'.\n source: \n\n\n* ed/fsmonitor-on-network-disk (2022-08-11) 1 commit\n (merged to 'next' on 2022-08-14 at 637d458d9c)\n + fsmonitor: option to allow fsmonitor to run against network-mounted repos\n\n The built-in fsmonitor refuses to work on a network mounted\n repositories; a configuration knob for users to override this has\n been introduced.\n\n Will merge to 'master'.\n source: \n\n\n* jk/is-promisor-object-keep-tree-in-use (2022-08-14) 1 commit\n - is_promisor_object(): fix use-after-free of tree buffer\n\n An earlier optimization discarded a tree-object buffer that is\n still in use, which has been corrected.\n\n Will merge to 'next'.\n source: \n\n\n* js/fetch-negotiation-trace (2022-08-15) 1 commit\n - fetch-pack: add tracing for negotiation rounds\n\n The common ancestor negotiation exchange during a \"git fetch\"\n session now leaves trace log.\n\n Will merge to 'next'.\n source: <4390677ec75d51487142adf7c2ab821cbd24a53e.1659477669.git.steadmon@google.com>\n\n\n* pw/rebase-keep-base-fixes (2022-08-15) 5 commits\n - rebase --keep-base: imply --no-fork-point\n - rebase --keep-base: imply --reapply-cherry-picks\n - rebase: factor out merge_base calculation\n - rebase: store orig_head as a commit\n - t3416: set $EDITOR in subshell\n\n \"git rebase --keep-base\" used to discard the commits that are\n already cherry-picked to the upstream, even when \"keep-base\" meant\n that the base, on top of which the history is being rebuilt, does\n not yet include these cherry-picked commits. The --keep-base\n option now implies --reapply-cherry-picks and --no-fork-point\n options.\n\n Needs review.\n source: \n\n--------------------------------------------------\n[Cooking]\n\n* fc/vimdiff-layout-vimdiff3-fix (2022-08-10) 7 commits\n (merged to 'next' on 2022-08-11 at a14fec292f)\n + mergetools: vimdiff: simplify tabfirst\n + mergetools: vimdiff: fix single window layouts\n + mergetools: vimdiff: rework tab logic\n + mergetools: vimdiff: fix for diffopt\n + mergetools: vimdiff: silence annoying messages\n + mergetools: vimdiff: make vimdiff3 actually work\n + mergetools: vimdiff: fix comment\n\n \"vimdiff3\" regression fix.\n\n Will merge to 'master'.\n source: <20220810154618.307275-1-felipe.contreras@gmail.com>\n\n\n* jk/fsck-tree-mode-bits-fix (2022-08-10) 3 commits\n (merged to 'next' on 2022-08-11 at 219fe53025)\n + fsck: downgrade tree badFilemode to \"info\"\n + fsck: actually detect bad file modes in trees\n + tree-walk: add a mechanism for getting non-canonicalized modes\n\n \"git fsck\" reads mode from tree objects but canonicalizes the mode\n before passing it to the logic to check object sanity, which has\n hid broken tree objects from the checking logic. This has been\n corrected, but to help exiting projects with broken tree objects\n that they cannot fix retroactively, the severity of anomalies this\n code detects has been demoted to \"info\" for now.\n\n Will merge to 'master'.\n source: \n\n\n* ag/merge-strategies-in-c (2022-08-10) 14 commits\n - sequencer: use the \"octopus\" strategy without forking\n - sequencer: use the \"resolve\" strategy without forking\n - merge: use the \"octopus\" strategy without forking\n - merge: use the \"resolve\" strategy without forking\n - merge-octopus: rewrite in C\n - merge-recursive: move better_branch_name() to merge.c\n - merge-resolve: rewrite in C\n - merge-one-file: rewrite in C\n - update-index: move add_cacheinfo() to read-cache.c\n - merge-index: add a new way to invoke `git-merge-one-file'\n - merge-index: drop the index\n - merge-index: libify merge_one_path() and merge_all()\n - t6060: add tests for removed files\n - t6060: modify multiple files to expose a possible issue with merge-index\n\n An attempt to rewrite remaining merge strategies from shell to C.\n source: <20220809185429.20098-1-alban.gruin@gmail.com>\n\n\n* sy/mv-out-of-cone (2022-08-10) 9 commits\n - mv: check overwrite for in-to-out move\n - advice.h: add advise_on_moving_dirty_path()\n - mv: cleanup empty WORKING_DIRECTORY\n - mv: from in-cone to out-of-cone\n - mv: remove BOTH from enum update_mode\n - mv: check if is a SKIP_WORKTREE_DIR\n - mv: free the with_slash in check_dir_in_index()\n - mv: rename check_dir_in_index() to empty_dir_has_sparse_contents()\n - t7002: add tests for moving from in-cone to out-of-cone\n\n \"git mv A B\" in a sparsely populated working tree can be asked to\n move a path from a directory that is \"in cone\" to another directory\n that is \"out of cone\". Handling of such a case has been improved.\n\n Will merge to 'next'?\n source: <20220809120910.2021413-1-shaoxuan.yuan02@gmail.com>\n\n\n* sy/sparse-rm (2022-08-08) 5 commits\n (merged to 'next' on 2022-08-12 at 5bf10965fb)\n + rm: integrate with sparse-index\n + rm: expand the index only when necessary\n + pathspec.h: move pathspec_needs_expanded_index() from reset.c to here\n + t1092: add tests for `git-rm`\n + Merge branch 'vd/sparse-reset-checkout-fixes' into sy/sparse-rm\n (this branch uses vd/sparse-reset-checkout-fixes.)\n\n \"git rm\" has become more aware of the sparse-index feature.\n\n Will merge to 'master'.\n source: <20220807041335.1790658-1-shaoxuan.yuan02@gmail.com>\n\n\n* vd/scalar-generalize-diagnose (2022-08-12) 11 commits\n - scalar: update technical doc roadmap\n - scalar-diagnose: use 'git diagnose --mode=all'\n - builtin/bugreport.c: create '--diagnose' option\n - builtin/diagnose.c: add '--mode' option\n - builtin/diagnose.c: create 'git diagnose' builtin\n - diagnose.c: add option to configure archive contents\n - scalar-diagnose: move functionality to common location\n - scalar-diagnose: move 'get_disk_info()' to 'compat/'\n - scalar-diagnose: add directory to archiver more gently\n - scalar-diagnose: avoid 32-bit overflow of size_t\n - scalar-diagnose: use \"$GIT_UNZIP\" in test\n\n The \"diagnose\" feature to create a zip archive for diagnostic\n material has been lifted from \"scalar\" and made into a feature of\n \"git bugreport\".\n\n Will merge to 'next'?\n source: \n\n\n* jk/pipe-command-nonblock (2022-08-03) 1 commit\n - pipe_command(): mark stdin descriptor as non-blocking\n\n Fix deadlocks between main Git process and subprocess spawned via\n the pipe_command() API, that can kill \"git add -p\" that was\n reimplemented in C recently.\n\n Needs waiting for corresponding change to Windows to put the pipe\n into nonblock mode.\n cf. \n source: \n\n\n* es/mark-gc-cruft-as-experimental (2022-08-03) 2 commits\n - config: let feature.experimental imply gc.cruftPacks=true\n - gc: add tests for --cruft and friends\n\n Enable gc.cruftpacks by default for those who opt into\n feature.experimental setting.\n\n Expecting a reroll.\n cf. <220804.86a68ke9d5.gmgdl@evledraar.gmail.com>\n cf. <6803b725-526e-a1c8-f15c-a9ed4a144d4c@github.com>\n source: <20220803205721.3686361-1-emilyshaffer@google.com>\n\n\n* vd/sparse-reset-checkout-fixes (2022-08-08) 4 commits\n (merged to 'next' on 2022-08-12 at 755d6ecdb8)\n + unpack-trees: unpack new trees as sparse directories\n + cache.h: create 'index_name_pos_sparse()'\n + oneway_diff: handle removed sparse directories\n + checkout: fix nested sparse directory diff in sparse index\n (this branch is used by sy/sparse-rm.)\n\n Fixes to sparse index compatibility work for \"reset\" and \"checkout\"\n commands.\n\n Will merge to 'master'.\n source: \n\n\n* sg/parse-options-subcommand (2022-07-25) 20 commits\n - builtin/worktree.c: let parse-options parse subcommands\n - builtin/stash.c: let parse-options parse subcommands\n - builtin/sparse-checkout.c: let parse-options parse subcommands\n - builtin/remote.c: let parse-options parse subcommands\n - builtin/reflog.c: let parse-options parse subcommands\n - builtin/notes.c: let parse-options parse subcommands\n - builtin/multi-pack-index.c: let parse-options parse subcommands\n - builtin/hook.c: let parse-option parse subcommands\n - builtin/gc.c: let parse-options parse 'git maintenance's subcommands\n - builtin/commit-graph.c: let parse-options parse subcommands\n - builtin/bundle.c: let parse-options parse subcommands\n - parse-options: add support for parsing subcommands\n - parse-options: drop leading space from '--git-completion-helper' output\n - parse-options: clarify the limitations of PARSE_OPT_NODASH\n - parse-options: PARSE_OPT_KEEP_UNKNOWN only applies to --options\n - api-parse-options.txt: fix description of OPT_CMDMODE\n - t0040-parse-options: test parse_options() with various 'parse_opt_flags'\n - t5505-remote.sh: check the behavior without a subcommand\n - t3301-notes.sh: check that default operation mode doesn't take arguments\n - git.c: update NO_PARSEOPT markings\n\n Introduce the \"subcommand\" mode to parse-options API and update the\n command line parser of Git commands with subcommands.\n\n Expecting a reroll.\n cf. <20220812152837.GC3790@szeder.dev>\n source: <20220725123857.2773963-1-szeder.dev@gmail.com>\n\n\n* ds/bundle-uri-clone (2022-08-10) 5 commits\n - clone: --bundle-uri cannot be combined with --depth\n - bundle-uri: add support for http(s):// and file://\n - clone: add --bundle-uri option\n - bundle-uri: create basic file-copy logic\n - remote-curl: add 'get' capability\n\n Implement \"git clone --bundle-uri\".\n source: \n\n\n* ds/decorate-filter-tweak (2022-08-05) 11 commits\n - fetch: use ref_namespaces during prefetch\n - maintenance: stop writing log.excludeDecoration\n - log: create log.initialDecorationSet=all\n - log: add --clear-decorations option\n - log: add default decoration filter\n - log-tree: use ref_namespaces instead of if/else-if\n - refs: use ref_namespaces for replace refs base\n - refs: add array of ref namespaces\n - t4207: test coloring of grafted decorations\n - t4207: modernize test\n - refs: allow \"HEAD\" as decoration filter\n\n The namespaces used by \"log --decorate\" from \"refs/\" hierarchy by\n default has been tightened.\n\n Will merge to 'next'?\n source: \n\n\n* es/doc-creation-factor-fix (2022-07-28) 2 commits\n - range-diff: clarify --creation-factor=\n - format-patch: clarify --creation-factor=\n\n Expecting a reroll.\n source: <7229p500-p2r4-on87-6802-8o90s36rr3s4@tzk.qr>\n\n\n* ab/submodule-helper-prep (2022-08-03) 28 commits\n - submodule--helper: fix bad config API usage\n - submodule--helper: libify \"must_die_on_failure\" code paths (for die)\n - submodule--helper: libify \"must_die_on_failure\" code paths\n - submodule--helper: libify determine_submodule_update_strategy()\n - submodule--helper: don't exit() on failure, return\n - submodule--helper: use \"code\" in run_update_command()\n - submodule--helper: move submodule_strategy_to_string() to only user\n - submodule--helper: don't call submodule_strategy_to_string() in BUG()\n - submodule--helper: add missing braces to \"else\" arm\n - submodule--helper: return \"ret\", not \"1\" from update_submodule()\n - submodule--helper: rename \"int res\" to \"int ret\"\n - submodule--helper: don't redundantly check \"else if (res)\"\n - submodule--helper: refactor \"errmsg_str\" to be a \"struct strbuf\"\n - submodule--helper: add \"const\" to copy of \"update_data\"\n - submodule--helper: pass a \"const struct module_clone_data\" to clone_submodule()\n - submodule--helper: move \"sb\" in clone_submodule() to its own scope\n - submodule--helper: use xstrfmt() in clone_submodule()\n - submodule--helper: replace memset() with { 0 }-initialization\n - submodule--helper style: add \\n\\n after variable declarations\n - submodule--helper style: don't separate declared variables with \\n\\n\n - submodule--helper: move \"resolve-relative-url-test\" to a test-tool\n - submodule--helper: move \"check-name\" to a test-tool\n - submodule--helper: move \"is-active\" to a test-tool\n - test-tool submodule-config: remove unused \"--url\" handling\n - submodule--helper: remove unused \"list\" helper\n - submodule--helper: remove unused \"name\" helper\n - submodule tests: test for \"add \"\n - submodule tests: test usage behavior\n (this branch is used by ab/submodule-helper-leakfix.)\n\n Code clean-up of \"git submodule--helper\".\n\n Expecting a (hopefully final?) reroll.\n cf. <220803.86h72tfpcc.gmgdl@evledraar.gmail.com>\n source: \n\n\n* ab/dedup-config-and-command-docs (2022-07-29) 9 commits\n - docs: add CONFIGURATION sections that fuzzy map to built-ins\n - docs: add CONFIGURATION sections that map to a built-in\n - log docs: de-duplicate configuration sections\n - difftool docs: de-duplicate configuration sections\n - notes docs: de-duplicate configuration sections\n - apply docs: de-duplicate configuration sections\n - send-email docs: de-duplicate configuration sections\n - grep docs: de-duplicate configuration sections\n - docs: add and use include template for config/* includes\n\n Share the text used to explain configuration variables used by \"git\n \" in \"git help \" with the text from \"git help config\".\n\n Expecting a reroll.\n cf. \n cf. \n cf. \n source: \n\n\n* cw/remote-object-info (2022-08-13) 7 commits\n - SQUASH???\n - cat-file: add remote-object-info to batch-command\n - transport: add client support for object-info\n - serve: advertise object-info feature\n - protocol-caps: initialization bug fix\n - fetch-pack: move fetch initialization\n - fetch-pack: refactor packet writing\n\n A client component to talk with the object-info endpoint.\n\n Expecting a reroll.\n cf. <20220728230210.2952731-1-calvinwan@google.com>\n cf. \n source: <20220728230210.2952731-1-calvinwan@google.com>\n\n\n* mt/rot13-in-c (2022-08-14) 4 commits\n - tests: use the new C rot13-filter helper to avoid PERL prereq\n - t0021: implementation the rot13-filter.pl script in C\n - t0021: avoid grepping for a Perl-specific string at filter output\n - Merge branch 'mt/checkout-count-fix' into mt/rot13-in-c\n\n Test portability improvements.\n\n Will merge to 'next'?\n source: \n\n\n* tl/trace2-config-scope (2022-08-11) 2 commits\n - tr2: shows scope unconditionally in addition to key-value pair\n - api-trace2.txt: print config key-value pair\n\n Tweak trace2 output about configuration variables.\n source: \n\n\n* ab/submodule-helper-leakfix (2022-08-03) 18 commits\n - submodule--helper: fix a configure_added_submodule() leak\n - submodule--helper: free rest of \"displaypath\" in \"struct update_data\"\n - submodule--helper: free some \"displaypath\" in \"struct update_data\"\n - submodule--helper: fix a memory leak in print_status()\n - submodule--helper: fix a leak in module_add()\n - submodule--helper: fix obscure leak in module_add()\n - submodule--helper: fix \"reference\" leak\n - submodule--helper: fix a memory leak in get_default_remote_submodule()\n - submodule--helper: fix a leak with repo_clear()\n - submodule--helper: fix \"sm_path\" and other \"module_cb_list\" leaks\n - submodule--helper: fix \"errmsg_str\" memory leak\n - submodule--helper: add and use *_release() functions\n - submodule--helper: don't leak {run,capture}_command() cp.dir argument\n - submodule--helper: \"struct pathspec\" memory leak in module_update()\n - submodule--helper: fix most \"struct pathspec\" memory leaks\n - submodule--helper: fix trivial get_default_remote_submodule() leak\n - submodule--helper: fix a leak in \"clone_submodule\"\n - Merge branch 'ab/submodule-helper-prep' into ab/submodule-helper-leakfix\n (this branch uses ab/submodule-helper-prep.)\n\n Plugging leaks in submodule--helper.\n\n Getting there.\n source: \n\n\n* cw/submodule-merge-messages (2022-08-04) 1 commit\n (merged to 'next' on 2022-08-12 at ede0890319)\n + submodule merge: update conflict error message\n\n Update the message given when \"git merge\" sees conflicts at a path\n with a submodule while merging a superproject.\n\n Will merge to 'master'.\n source: <20220804195105.1303455-1-calvinwan@google.com>\n\n\n* po/doc-add-renormalize (2022-08-10) 1 commit\n (merged to 'next' on 2022-08-11 at 53851663eb)\n + doc add: renormalize is not idempotent for CRCRLF\n\n Documentation for \"git add --renormalize\" has been improved.\n\n Will merge to 'master'.\n source: <20220810144450.470-2-philipoakley@iee.email>\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 Expecting a reroll.\n cf. \n source: \n\n\n* ac/bitmap-lookup-table (2022-08-14) 6 commits\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 - bitmap: move `get commit positions` code to `bitmap_writer_finish`\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 source: \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* 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-08-10) 2 commits\n (merged to 'next' on 2022-08-12 at 4f445a058d)\n + bundle-uri: add example bundle organization\n + docs: document bundle URI standard\n\n The \"bundle URI\" design gets documented.\n\n Will merge to 'master'.\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[Discarded]\n\n* mb/doc-rerere-autoupdate (2022-07-15) 1 commit\n . cherry-pick doc: clarify no-rerere-autoupdate still allows rerere\n\n Clarifies that the \"--no-rerere-autoupdate\" option does not disable\n the \"rerere\" mechanism (nor does \"--rerere-autoupdate\" enable it).\n\n Superseded by jc/rerere-autoupdate-doc\n source: <20220715092527.1567837-1-mail@beyermatthias.de>\n\n\n* fr/vimdiff-layout-colors-fix (2022-08-07) 3 commits\n . mergetools: vimdiff: update unit tests\n . mergetools: vimdiff: fix single tab mode, single window mode and colors\n . mergetools: vimdiff: fix comment\n\n \"vimdiff3\" regression fix.\n\n Superseded by fc/vimdiff-layout-vimdiff3-fix\n source: <20220808053459.184367-1-greenfoo@u92.eu>\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 In stalled state for too long.\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 In stalled state for too long.\n cf. \n source: <20220407215352.3491567-1-sandals@crustytoothpaste.net>\n"},{"id":"461267","messageId":"p053rrpq-17q7-pnrs-3794-o04ro1445s5s@tzk.qr","threadId":"58310","inReplyTo":"xmqq5yityzcu.fsf@gitster.g","subject":"js/bisect-in-c, was Re: What's cooking in git.git (Aug 2022, #05; Mon, 15)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2022-08-16T08:56:58Z","receivedAt":"2022-08-16T10:19:48Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Junio,\n\nOn Mon, 15 Aug 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> source: \n\nI had another look at the thread and did not see any feedback that focuses\non the actual scope of the patch series. Conversions from scripted parts\nof Git to built-ins are always a bit finicky (and hard to review, I\nadmit).\n\nTherefore I would like to move the status to \"needs review\".\n\nI do not think that there are any major issues with it (Ævar's feedback\nnotwithstanding, it focuses on tangents that should be addressed after the\nconversion, to avoid losing focus), but I would love to see a thorough\nreview of the conversion to avoid obvious regressions like the one in the\nbuilt-in interactive `add` I had to fix recently.\n\nCiao,\nDscho\n"},{"id":"461292","messageId":"2b19b57b-b6b1-8214-d1fd-3ffe9eac2d9d@github.com","threadId":"58310","inReplyTo":"xmqq5yityzcu.fsf@gitster.g","subject":"sy/mv-out-of-cone (was Re: What's cooking in git.git (Aug 2022, #05; Mon, 15))","fromName":"Victoria Dye","fromEmail":"vdye@github.com","sentAt":"2022-08-16T16:00:59Z","receivedAt":"2022-08-16T16:04:41Z","isPatch":false,"sender":{"key":"vdye@github.com","avatar":"https://avatars.githubusercontent.com/u/3619353?v=4"},"body":"Junio C Hamano wrote:\n> * sy/mv-out-of-cone (2022-08-10) 9 commits\n> - mv: check overwrite for in-to-out move\n> - advice.h: add advise_on_moving_dirty_path()\n> - mv: cleanup empty WORKING_DIRECTORY\n> - mv: from in-cone to out-of-cone\n> - mv: remove BOTH from enum update_mode\n> - mv: check if is a SKIP_WORKTREE_DIR\n> - mv: free the with_slash in check_dir_in_index()\n> - mv: rename check_dir_in_index() to empty_dir_has_sparse_contents()\n> - t7002: add tests for moving from in-cone to out-of-cone\n> \n> \"git mv A B\" in a sparsely populated working tree can be asked to\n> move a path from a directory that is \"in cone\" to another directory\n> that is \"out of cone\". Handling of such a case has been improved.\n> \n> Will merge to 'next'?\n> source: <20220809120910.2021413-1-shaoxuan.yuan02@gmail.com>\n> \n\nAfter reviewing the latest version [1], I think this is ready for 'next'.\n\n[1] https://lore.kernel.org/git/52b67242-5d91-5406-9c95-9d8ddc49c079@github.com/\n"},{"id":"461293","messageId":"xmqq8rnoxiyi.fsf@gitster.g","threadId":"58310","inReplyTo":"2b19b57b-b6b1-8214-d1fd-3ffe9eac2d9d@github.com","subject":"Re: sy/mv-out-of-cone (was Re: What's cooking in git.git (Aug 2022, #05; Mon, 15))","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-08-16T16:16:05Z","receivedAt":"2022-08-16T16:16:13Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Victoria Dye writes:\n\n> Junio C Hamano wrote:\n>> * sy/mv-out-of-cone (2022-08-10) 9 commits\n>> - mv: check overwrite for in-to-out move\n>> - advice.h: add advise_on_moving_dirty_path()\n>> - mv: cleanup empty WORKING_DIRECTORY\n>> - mv: from in-cone to out-of-cone\n>> - mv: remove BOTH from enum update_mode\n>> - mv: check if is a SKIP_WORKTREE_DIR\n>> - mv: free the with_slash in check_dir_in_index()\n>> - mv: rename check_dir_in_index() to empty_dir_has_sparse_contents()\n>> - t7002: add tests for moving from in-cone to out-of-cone\n>> \n>> \"git mv A B\" in a sparsely populated working tree can be asked to\n>> move a path from a directory that is \"in cone\" to another directory\n>> that is \"out of cone\". Handling of such a case has been improved.\n>> \n>> Will merge to 'next'?\n>> source: <20220809120910.2021413-1-shaoxuan.yuan02@gmail.com>\n>\n> After reviewing the latest version [1], I think this is ready for 'next'.\n>\n> [1] https://lore.kernel.org/git/52b67242-5d91-5406-9c95-9d8ddc49c079@github.com/\n\nThanks, both.\n"},{"id":"461328","messageId":"CABPp-BFUSPWhx5GN0KrMzPiLWq+djhfaZQTz0y=r2MeASVrMRw@mail.gmail.com","threadId":"58310","inReplyTo":"xmqq5yityzcu.fsf@gitster.g","subject":"cw/submodule-merge-messages (Was: Re: What's cooking in git.git (Aug 2022, #05; Mon, 15))","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2022-08-17T00:36:12Z","receivedAt":"2022-08-17T00:36:35Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Mon, Aug 15, 2022 at 6:50 PM Junio C Hamano wrote:\n>\n> * cw/submodule-merge-messages (2022-08-04) 1 commit\n> (merged to 'next' on 2022-08-12 at ede0890319)\n> + submodule merge: update conflict error message\n>\n> Update the message given when \"git merge\" sees conflicts at a path\n> with a submodule while merging a superproject.\n>\n> Will merge to 'master'.\n> source: <20220804195105.1303455-1-calvinwan@google.com>\n\nI apologize for being away and not reviewing again before this merged\nto next (vacation followed by coming down with Covid). I noticed a\nfew issues with v8, so I submitted a few patches meant to go on top:\n https://lore.kernel.org/git/pull.1325.git.1660696081.gitgitgadget@gmail.com/\n"},{"id":"461330","messageId":"CABPp-BFAERLt_z-D=7gbXWVA9JgsqTP_2iW9BLe5S=YbsQ1V6w@mail.gmail.com","threadId":"58310","inReplyTo":"p053rrpq-17q7-pnrs-3794-o04ro1445s5s@tzk.qr","subject":"Re: js/bisect-in-c, was Re: What's cooking in git.git (Aug 2022, #05; Mon, 15)","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2022-08-17T01:26:51Z","receivedAt":"2022-08-17T01:28:05Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"Hi,\n\nOn Tue, Aug 16, 2022 at 3:49 AM Johannes Schindelin\n wrote:\n>\n> Hi Junio,\n>\n> On Mon, 15 Aug 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\nJunio: This link came up dead for me; I think the intended link was\n220627.86ilolhnnn.gmgdl@evledraar.gmail.com ?\n\n> > source: \n>\n> I had another look at the thread and did not see any feedback that focuses\n> on the actual scope of the patch series. Conversions from scripted parts\n> of Git to built-ins are always a bit finicky (and hard to review, I\n> admit).\n>\n> Therefore I would like to move the status to \"needs review\".\n>\n> I do not think that there are any major issues with it (Ævar's feedback\n> notwithstanding, it focuses on tangents that should be addressed after the\n> conversion, to avoid losing focus), but I would love to see a thorough\n> review of the conversion to avoid obvious regressions like the one in the\n> built-in interactive `add` I had to fix recently.\n\nI reviewed it --\nhttps://lore.kernel.org/git/CABPp-BEOX+zxR9-yyx-EaiOV-Z9yD0YP_Kwvu4iGB8enz40XXQ@mail.gmail.com/.\nI looked over the subsequent iterations too, and they still look good\nto me.\n\nCould I vote for just merging it down, as-is? As far as I can tell,\nthis series was stalled for 6-7 months over \"doesn't use\nparse_options() API\", even though Dscho addressed that directly in v1\nin one of his commit messages stating he had already investigated that\nroute and found it wanting, at least in its current state[1]. It\nappears, from my reading, that using parse_options() API was insisted\nupon...though it turns out that making parse_options() capable of\nhandling such things is at least another 20-patch series[2] (which may\nnot be enough either[3]). Further, such changes, while likely\ndesirable for consistency among Git commands, would likely move us\naway from \"faithful conversion from shell to C\", and thus is likely\nbetter to be done as a separate step on top of the existing series\nanyway[4].\n\nIf we merge down, as-is, then Ævar can go to town on it, possibly\nusing SZEDER's changes[2], and convert the new bisect code over to\nusing parse_options(), and show Dscho what he meant by how it could be\ndone. Maybe Ævar will even demonstrate that it is quite simple to do.\nOr, perhaps, Ævar will discover what Dscho did and agree that\nparse_options() really can't handle that case. I wouldn't be\nsurprised by either outcome. Either way, I think it'd resolve the\nissue much faster than going round and round in discussions.\n\nAnd I think the result would be more to everyone's liking -- Dscho\ngets to concentrate on the stuff he cares about (user experience,\nconverting shell to C faithfully), and Ævar gets to concentrate on the\nstuff he cares about (internal code consistency, tree-wide\nrefactorings). And in the meantime, the rest of us get to enjoy the\nfruits of three separate GSoC projects plus Dscho's attempt to tie it\nall together. I think Dscho's Dscho's submission improves upon\ncurrent Git and is good enough to merge, even if there may be ways to\nmake it even better.\n\nAnyway, just my $0.02.\n\n[1] https://lore.kernel.org/git/515e86e20758ed7f5b4a8ce8f38bfbbac27ec42a.1643328752.git.gitgitgadget@gmail.com/\n[2] https://lore.kernel.org/git/20220812150420.GA3790@szeder.dev/\n[3] https://lore.kernel.org/git/1p04q351-9938-r0r7-snr6-9s8237s27459@tzk.qr/\n[4] https://lore.kernel.org/git/8o63pp64-4s00-1000-42s1-38so68398337@tzk.qr/\n"},{"id":"461332","messageId":"1c8ffd85-2398-6910-b7ad-0555962e76e2@gmail.com","threadId":"58310","inReplyTo":"2b19b57b-b6b1-8214-d1fd-3ffe9eac2d9d@github.com","subject":"Re: sy/mv-out-of-cone (was Re: What's cooking in git.git (Aug 2022, #05; Mon, 15))","fromName":"Shaoxuan Yuan","fromEmail":"shaoxuan.yuan02@gmail.com","sentAt":"2022-08-17T02:03:32Z","receivedAt":"2022-08-17T02:03:59Z","isPatch":false,"sender":{"key":"shaoxuan.yuan02@gmail.com","avatar":"https://avatars.githubusercontent.com/u/46557895?v=4"},"body":"On 8/17/2022 12:00 AM, Victoria Dye wrote:\n> Junio C Hamano wrote:\n>> * sy/mv-out-of-cone (2022-08-10) 9 commits\n>> - mv: check overwrite for in-to-out move\n>> - advice.h: add advise_on_moving_dirty_path()\n>> - mv: cleanup empty WORKING_DIRECTORY\n>> - mv: from in-cone to out-of-cone\n>> - mv: remove BOTH from enum update_mode\n>> - mv: check if is a SKIP_WORKTREE_DIR\n>> - mv: free the with_slash in check_dir_in_index()\n>> - mv: rename check_dir_in_index() to empty_dir_has_sparse_contents()\n>> - t7002: add tests for moving from in-cone to out-of-cone\n>>\n>> \"git mv A B\" in a sparsely populated working tree can be asked to\n>> move a path from a directory that is \"in cone\" to another directory\n>> that is \"out of cone\". Handling of such a case has been improved.\n>>\n>> Will merge to 'next'?\n>> source: <20220809120910.2021413-1-shaoxuan.yuan02@gmail.com>\n>>\n> After reviewing the latest version [1], I think this is ready for 'next'.\n>\n> [1] https://lore.kernel.org/git/52b67242-5d91-5406-9c95-9d8ddc49c079@github.com/\nThanks!\n\n\n"},{"id":"461348","messageId":"p941o26q-op57-n2q9-1646-oops0300n837@tzk.qr","threadId":"58310","inReplyTo":"CABPp-BFAERLt_z-D=7gbXWVA9JgsqTP_2iW9BLe5S=YbsQ1V6w@mail.gmail.com","subject":"Re: js/bisect-in-c, was Re: What's cooking in git.git (Aug 2022, #05; Mon, 15)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2022-08-17T06:27:59Z","receivedAt":"2022-08-17T06:28:16Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Elijah,\n\nOn Tue, 16 Aug 2022, Elijah Newren wrote:\n\n> On Tue, Aug 16, 2022 at 3:49 AM Johannes Schindelin\n> wrote:\n> >\n> > On Mon, 15 Aug 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> Junio: This link came up dead for me; I think the intended link was\n> 220627.86ilolhnnn.gmgdl@evledraar.gmail.com ?\n\nI had mentioned this in\nhttps://lore.kernel.org/git/s3726r9p-r96o-7793-0qrq-o54rs4npr972@tzk.qr/\nbut failed to ask Junio to change it in the What's cooking mails. Thank\nyou for pointing it out, too.\n\n> > > source: \n> >\n> > I had another look at the thread and did not see any feedback that focuses\n> > on the actual scope of the patch series. Conversions from scripted parts\n> > of Git to built-ins are always a bit finicky (and hard to review, I\n> > admit).\n> >\n> > Therefore I would like to move the status to \"needs review\".\n> >\n> > I do not think that there are any major issues with it (Ævar's feedback\n> > notwithstanding, it focuses on tangents that should be addressed after the\n> > conversion, to avoid losing focus), but I would love to see a thorough\n> > review of the conversion to avoid obvious regressions like the one in the\n> > built-in interactive `add` I had to fix recently.\n>\n> I reviewed it --\n> https://lore.kernel.org/git/CABPp-BEOX+zxR9-yyx-EaiOV-Z9yD0YP_Kwvu4iGB8enz40XXQ@mail.gmail.com/.\n> I looked over the subsequent iterations too, and they still look good\n> to me.\n\nOoops. I am sorry for misrepresenting the situation. I honestly had\nforgotten that the patch series did, in fact, receive a good and thorough\nreview.\n\nMy apologies and thank you so much for all your help!\nDscho\n"},{"id":"461378","messageId":"xmqqtu6avgub.fsf@gitster.g","threadId":"58310","inReplyTo":"CABPp-BFAERLt_z-D=7gbXWVA9JgsqTP_2iW9BLe5S=YbsQ1V6w@mail.gmail.com","subject":"Re: js/bisect-in-c, was Re: What's cooking in git.git (Aug 2022, #05; Mon, 15)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-08-17T18:57:00Z","receivedAt":"2022-08-17T18:57:16Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Elijah Newren writes:\n\n>> > Expecting a (hopefully final) reroll.\n>> ...\n>\n> Could I vote for just merging it down, as-is? As far as I can tell,\n> ... Further, such changes, while likely\n> desirable for consistency among Git commands, would likely move us\n> away from \"faithful conversion from shell to C\", and thus is likely\n> better to be done as a separate step on top of the existing series\n> anyway[4].\n\nIf this were a faithful conversion, yes, merging it right now can be\none good approach; add a faithful but not very C-like convesion\nfirst and then make it \"more like C code\" later.\n\nI however got an impression from the review discussion that it\nsubtly changes behaviour (IIRC, one thing pointed out was that exit\ncodes are now different from the original---there may or may not be\nothers, but my impression was they were all minor like the \"exit\ncode\" one).\n\nMy \"hopefully final\" comment was not about a big rearchitecting\nchange like use of parse-options API but about adjusting such minor\nbehaviour diversion so that we can say \"This may not be very C-like,\nand does not use much of our established API, but it is a fairly\nfaithful bug-to-bug compatible translation. Let's take it and make\nit more like C incrementally\". And of course, what was implied in\n\"hopefully final\" was that such adjustments would be tiny, trivial\nand can be done without much controversy. After all, I was aware\nthat the series was otherwise reviewed and received extensive\ncomments (sorry, I forgot that it was by you).\n\nThanks.\n"},{"id":"461383","messageId":"CABPp-BHBOqnU7DSLkYPig=c6+emWGaE1vdzaPk0D90yQdof+6A@mail.gmail.com","threadId":"58310","inReplyTo":"xmqqtu6avgub.fsf@gitster.g","subject":"Re: js/bisect-in-c, was Re: What's cooking in git.git (Aug 2022, #05; Mon, 15)","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2022-08-17T19:24:57Z","receivedAt":"2022-08-17T19:25:12Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Wed, Aug 17, 2022 at 11:57 AM Junio C Hamano wrote:\n>\n> Elijah Newren writes:\n>\n> >> > Expecting a (hopefully final) reroll.\n> >> ...\n> >\n> > Could I vote for just merging it down, as-is? As far as I can tell,\n> > ... Further, such changes, while likely\n> > desirable for consistency among Git commands, would likely move us\n> > away from \"faithful conversion from shell to C\", and thus is likely\n> > better to be done as a separate step on top of the existing series\n> > anyway[4].\n>\n> If this were a faithful conversion, yes, merging it right now can be\n> one good approach; add a faithful but not very C-like convesion\n> first and then make it \"more like C code\" later.\n>\n> I however got an impression from the review discussion that it\n> subtly changes behaviour (IIRC, one thing pointed out was that exit\n> codes are now different from the original---there may or may not be\n> others, but my impression was they were all minor like the \"exit\n> code\" one).\n>\n> My \"hopefully final\" comment was not about a big rearchitecting\n> change like use of parse-options API but about adjusting such minor\n> behaviour diversion so that we can say \"This may not be very C-like,\n> and does not use much of our established API, but it is a fairly\n> faithful bug-to-bug compatible translation. Let's take it and make\n> it more like C incrementally\". And of course, what was implied in\n> \"hopefully final\" was that such adjustments would be tiny, trivial\n> and can be done without much controversy. After all, I was aware\n> that the series was otherwise reviewed and received extensive\n> comments (sorry, I forgot that it was by you).\n>\n> Thanks.\n\nAh, gotcha. My impression was that the exit codes did match what the\nprevious shell code had done, but didn't match what other builtins\nusually return. Perhaps I misread those discussion comments.\n\nThanks for the clarification.\n"},{"id":"461385","messageId":"xmqq35duvdow.fsf@gitster.g","threadId":"58310","inReplyTo":"CABPp-BHBOqnU7DSLkYPig=c6+emWGaE1vdzaPk0D90yQdof+6A@mail.gmail.com","subject":"Re: js/bisect-in-c, was Re: What's cooking in git.git (Aug 2022, #05; Mon, 15)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-08-17T20:05:03Z","receivedAt":"2022-08-17T20:05:16Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Elijah Newren writes:\n\n> Ah, gotcha. My impression was that the exit codes did match what the\n> previous shell code had done, but didn't match what other builtins\n> usually return. Perhaps I misread those discussion comments.\n\nOr perhaps I did ;-)\n\nThe topic has been waiting for the finishing polish for so long that\nI do not remember the details of the discussion offhand, certainly\nnot better than I did when I left the note in the \"What's cooking\"\nreport.\n\n"},{"id":"461541","messageId":"snn8r5pn-rr6n-376r-s663-92s81pos077p@tzk.qr","threadId":"58310","inReplyTo":"xmqq35duvdow.fsf@gitster.g","subject":"Re: js/bisect-in-c, was Re: What's cooking in git.git (Aug 2022, #05; Mon, 15)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2022-08-19T11:04:45Z","receivedAt":"2022-08-19T11:05:37Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Junio,\n\nOn Wed, 17 Aug 2022, Junio C Hamano wrote:\n\n> Elijah Newren writes:\n>\n> > Ah, gotcha. My impression was that the exit codes did match what the\n> > previous shell code had done, but didn't match what other builtins\n> > usually return. Perhaps I misread those discussion comments.\n>\n> Or perhaps I did ;-)\n\nThe exit codes before and after this patch series are a red herring. The\n_current_ code prints this when calling `git bisect start -h`:\n\n\t$ git bisect start -h\n\tusage: git bisect--helper --bisect-reset []\n\t or: git bisect--helper --bisect-terms [--term-good | --term-old | --term-bad | --term-new]\n\t or: git bisect--helper --bisect-start [--term-{new,bad}= --term-{old,good}=] [--no-checkout] [--first-parent] [ [...]] [--] [...]\n\t or: git bisect--helper --bisect-next\n\t or: git bisect--helper --bisect-state (bad|new) []\n\t or: git bisect--helper --bisect-state (good|old) [...]\n\t or: git bisect--helper --bisect-replay \n\t or: git bisect--helper --bisect-skip [(|)...]\n\t or: git bisect--helper --bisect-visualize\n\t or: git bisect--helper --bisect-run ...\n\n\t --bisect-reset reset the bisection state\n\t --bisect-next-check check whether bad or good terms exist\n\t --bisect-terms print out the bisect terms\n\t --bisect-start start the bisect session\n\t --bisect-next find the next bisection commit\n\t --bisect-state mark the state of ref (or refs)\n\t --bisect-log list the bisection steps so far\n\t --bisect-replay replay the bisection process from the given file\n\t --bisect-skip skip some commits for checkout\n\t --bisect-visualize visualize the bisection\n\t --bisect-run use ... to automatically bisect\n\t --no-log no log for BISECT_WRITE\n\nNotice how this talks about `bisect--helper` and about `--bisect-reset`.\n\nAlso, the _current_ code exits with code 0 when calling `git bisect -h`.\n\nThis has been the case even as far back as v2.25.1, and possibly even\nlonger.\n\nGiven these issues, I was mistakenly assuming that it would be okay to\npostpone these problems that are exclusively related to incorrect\ninvocation of `git bisect`, and that it would make sense to focus on the\nconversion from shell code to C in _this_ patch series, and take care of\nthese problems afterwards, instead of hodgepodging fixes for them into the\nsame patch series as the conversion to C, the latter being hard enough to\nreview as it stands, so much so that it received only a single high\nquality review.\n\nBut I see that you somehow got the idea that the review that lacked\nattention to the common code path somehow was a valid review and you\nsomehow got it in your mind that this was valid feedback and that the\npatch series needs to be reworked so that it _also_ addresses issues that\nhave been broken _before_ it.\n\nFine.\n\nI'll try to get to it next week. It does leave a foul taste that we're not\nseparating concerns properly in the Git project, but block a patch series\nthat has a specific, already large scope, just because one reviewer wants\nit to have another scope and for some reason that now must be the scope of\nthe patch series.\n\nCiao,\nDscho\n"},{"id":"461555","messageId":"220819.86sfls6zhh.gmgdl@evledraar.gmail.com","threadId":"58310","inReplyTo":"snn8r5pn-rr6n-376r-s663-92s81pos077p@tzk.qr","subject":"Re: js/bisect-in-c, was Re: What's cooking in git.git (Aug 2022, #05; Mon, 15)","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2022-08-19T14:40:04Z","receivedAt":"2022-08-19T15:10:31Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Fri, Aug 19 2022, Johannes Schindelin wrote:\n\n> Hi Junio,\n>\n> On Wed, 17 Aug 2022, Junio C Hamano wrote:\n>\n>> Elijah Newren writes:\n>>\n>> > Ah, gotcha. My impression was that the exit codes did match what the\n>> > previous shell code had done, but didn't match what other builtins\n>> > usually return. Perhaps I misread those discussion comments.\n>>\n>> Or perhaps I did ;-)\n>\n> The exit codes before and after this patch series are a red herring. The\n> _current_ code prints this when calling `git bisect start -h`:\n>\n> \t$ git bisect start -h\n> \tusage: git bisect--helper --bisect-reset []\n> \t or: git bisect--helper --bisect-terms [--term-good | --term-old | --term-bad | --term-new]\n> \t or: git bisect--helper --bisect-start [--term-{new,bad}= --term-{old,good}=] [--no-checkout] [--first-parent] [ [...]] [--] [...]\n> \t or: git bisect--helper --bisect-next\n> \t or: git bisect--helper --bisect-state (bad|new) []\n> \t or: git bisect--helper --bisect-state (good|old) [...]\n> \t or: git bisect--helper --bisect-replay \n> \t or: git bisect--helper --bisect-skip [(|)...]\n> \t or: git bisect--helper --bisect-visualize\n> \t or: git bisect--helper --bisect-run ...\n>\n> \t --bisect-reset reset the bisection state\n> \t --bisect-next-check check whether bad or good terms exist\n> \t --bisect-terms print out the bisect terms\n> \t --bisect-start start the bisect session\n> \t --bisect-next find the next bisection commit\n> \t --bisect-state mark the state of ref (or refs)\n> \t --bisect-log list the bisection steps so far\n> \t --bisect-replay replay the bisection process from the given file\n> \t --bisect-skip skip some commits for checkout\n> \t --bisect-visualize visualize the bisection\n> \t --bisect-run use ... to automatically bisect\n> \t --no-log no log for BISECT_WRITE\n>\n> Notice how this talks about `bisect--helper` and about `--bisect-reset`.\n>\n> Also, the _current_ code exits with code 0 when calling `git bisect -h`.\n>\n> This has been the case even as far back as v2.25.1, and possibly even\n> longer.\n>\n> Given these issues, I was mistakenly assuming that it would be okay to\n> postpone these problems that are exclusively related to incorrect\n> invocation of `git bisect`, and that it would make sense to focus on the\n> conversion from shell code to C in _this_ patch series, and take care of\n> these problems afterwards, instead of hodgepodging fixes for them into the\n> same patch series as the conversion to C, the latter being hard enough to\n> review as it stands, so much so that it received only a single high\n> quality review.\n>\n> But I see that you somehow got the idea that the review that lacked\n> attention to the common code path somehow was a valid review and you\n> somehow got it in your mind that this was valid feedback and that the\n> patch series needs to be reworked so that it _also_ addresses issues that\n> have been broken _before_ it.\n\nI really think these remarks about \"high quality review\" and \"the review\nthat lacked attention\" are overly snide and don't contribute to a\nfriendly ML atmosphere.\n\nWe can all be wrong about stuff, e.g. [1] is one very recent case where\nI just plain misread something in a review. But can we just ask for a\nclarification etc?\n\nIn this case I fully agree with you that any existing issues in the\nconversion of bisect to C should be out of scope for your series, but\nthat's not what your series is doing.\n\nI've specifically been pointing out issues where the behavior is changed\nas a result.\n\nFor example, on \"master\" (and there's a lot more of these):\n\n\t$ ./git --exec-path=$PWD bisect terms a b c; echo $?\n\terror: --bisect-terms requires 0 or 1 argument\n\t255\n\nOn \"seen\", with your series:\n\n\t$ ./git --exec-path=$PWD bisect terms a b c; echo $?\n\tfatal: 'terms' requires 0 or 1 argument\n 128\n\nThat's one of the things I pointed out to you, and clearly a behavior\nchange in both the exit code emitted, and the message emitted.\n\nI don't think it's unacceptable to have some behavior change as we\nmigrate to the C version.\n\nI'd just pointed out cases where that either seemed unnecessary, or\nmigrated to some unusual pattern. E.g in the case of exiting with code\n128 instead of 129 on usage errors, as we usually do.\n\n> I'll try to get to it next week. It does leave a foul taste that we're not\n> separating concerns properly in the Git project, but block a patch series\n> that has a specific, already large scope, just because one reviewer wants\n> it to have another scope and for some reason that now must be the scope of\n> the patch series.\n\nI'd really like you to find and quote back to me somewhere I've\nattempted to \"block\" these patches, or anything of the kind. That's\nsimply not true.\n\nIf you had actually asked: Aside from any outstanding issues with your\nseries, I think as it stands that it's a net improvement on \"master\". I\nwould not mind it advanced in its current state. We can fix any\noutstanding issues with it later, particularly due to what seem like\ntime constraints on your end, and how unproductive reviewing it seems to\nbe getting.\n\nI think the only thing I've said which could be construed as \"blocking\"\nthis series has been:\n\n * In\n https://lore.kernel.org/git/220627.86mtdxhnwk.gmgdl@evledraar.gmail.com/\n noting (and I'm paraphrasing here) that I couldn't in good conscience\n give it something like my Reviewed-by due to the various behavior\n changes it introduces, *and* the fact that large parts of the bisect\n interface it touches are completely untested.\n\n Now, of course \"untested\" is an existing issue, but I think it's fair\n to point that out when a series proposes to refactor some code that\n it's doing so on an interface that's not well tested, to the point\n that you can remove at least one \"bisect\" sub-command entirely and\n have the test suite still pass.\n\n * Pointing out specific bugs etc, as above.\n\n * In these \"js/bisect-in-c\" threads noting the outstanding issues with\n it, particularly as I think your own summaries have been.\n\n I don't see how you your remark that you \"did not see any feedback\n that focuses on the actual scope of the patch series\" in [2] with\n e.g. claim above that this behavior was \"broken _before_ it\" as\n anything except contradictory.\n\nIf your own summaries were something to the effect that no major issues\nhad been raised, that you didn't have time to re-roll it, and could it\neither be picked up as-is or could others propose fix-ups on top I\nreally wouldn't mind, or see any reason to comment in these threads.\n\n1. https://lore.kernel.org/git/220819.86a6817xyw.gmgdl@evledraar.gmail.com/\n2. https://lore.kernel.org/git/p053rrpq-17q7-pnrs-3794-o04ro1445s5s@tzk.qr/\n"}]}