threads / discuss / 58310

What's cooking in git.git (Aug 2022, #05; Mon, 15)

Subject: What's cooking in git.git (Aug 2022, #05; Mon, 15)

## tl;dr

13 messages between Aug 16, 2022 and Aug 19, 2022.

replies: 12people: 6as markdown or json

Junio C Hamano· Aug 15, 2022, 21:24 UTC · lore

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. A topic without enough support may be discarded after a long period of no activity.

We are at the beginning of the week #6 of a 12-week cycle (cf. https://tinyurl.com/gitCal).

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']

* ab/hooks-regression-fix (2022-08-05) 1 commit
  (merged to 'next' on 2022-08-08 at f5a3f88983)
 + hook API: don't segfault on strbuf_addf() to NULL "out"
 A follow-up fix to a fix for a regression in 2.36.
 source: <patch-1.1-2450e3e65cf-20220805T141402Z-avarab@gmail.com>
* ab/leak-check (2022-07-27) 15 commits
  (merged to 'next' on 2022-08-05 at 2a6b9c8432)
 + CI: use "GIT_TEST_SANITIZE_LEAK_LOG=true" in linux-leaks
 + upload-pack: fix a memory leak in create_pack_file()
 + leak tests: mark passing SANITIZE=leak tests as leak-free
 + leak tests: don't skip some tests under SANITIZE=leak
 + test-lib: have the "check" mode for SANITIZE=leak consider leak logs
 + test-lib: add a GIT_TEST_PASSING_SANITIZE_LEAK=check mode
 + test-lib: simplify by removing test_external
 + tests: move copy/pasted PERL + Test::More checks to a lib-perl.sh
 + t/Makefile: don't remove test-results in "clean-except-prove-cache"
 + test-lib: add a SANITIZE=leak logging mode
 + t/README: reword the "GIT_TEST_PASSING_SANITIZE_LEAK" description
 + test-lib: add a --invert-exit-code switch
 + test-lib: fix GIT_EXIT_OK logic errors, use BAIL_OUT
 + test-lib: don't set GIT_EXIT_OK before calling test_atexit_handler
 + test-lib: use $1, not $@ in test_known_broken_{ok,failure}_
 Extend SANITIZE=leak checking and declare more tests "currently leak-free".
 source: <cover-v3-00.15-00000000000-20220727T230800Z-avarab@gmail.com>
* ab/plug-revisions-leak (2022-08-03) 6 commits
  (merged to 'next' on 2022-08-05 at d1ca88976f)
 + revisions API: don't leak memory on argv elements that need free()-ing
 + bisect.c: partially fix bisect_rev_setup() memory leak
 + log: refactor "rev.pending" code in cmd_show()
 + log: fix a memory leak in "git show <revision>..."
 + test-fast-rebase helper: use release_revisions() (again)
 + bisect.c: add missing "goto" for release_revisions()
 Plug a bit more leaks in the revisions API.
 source: <cover-v3-0.6-00000000000-20220802T152925Z-avarab@gmail.com>
* ab/tech-docs-to-help (2022-08-04) 12 commits
  (merged to 'next' on 2022-08-08 at 65c9ec7308)
 + docs: move http-protocol docs to man section 5
 + docs: move cruft pack docs to gitformat-pack
 + docs: move pack format docs to man section 5
 + docs: move signature docs to man section 5
 + docs: move index format docs to man section 5
 + docs: move protocol-related docs to man section 5
 + docs: move commit-graph format docs to man section 5
 + git docs: add a category for file formats, protocols and interfaces
 + git docs: add a category for user-facing file, repo and command UX
 + git help doc: use "<doc>" instead of "<guide>"
 + help.c: remove common category behavior from drop_prefix() behavior
 + help.c: refactor drop_prefix() to use a "switch" statement"
 Expose a lot of "tech docs" via "git help" interface.
 source: <cover-v8-00.12-00000000000-20220804T162138Z-avarab@gmail.com>
* gc/git-reflog-doc-markup (2022-08-01) 1 commit
  (merged to 'next' on 2022-08-05 at f2d8721ab2)
 + Documentation/git-reflog: remove unneeded \ from \{
 Doc mark-up fix.
 source: <pull.1304.git.git.1659387885711.gitgitgadget@gmail.com>
* jc/rerere-autoupdate-doc (2022-08-03) 2 commits
  (merged to 'next' on 2022-08-08 at 6407091d13)
 + doc: clarify rerere-autoupdate
 + doc: consolidate --rerere-autoupdate description
 Update documentation on the "--[no-]rerere-autoupdate" option.
 source: <xmqq35f2ysd9.fsf@gitster.g>
* js/safe-directory-plus (2022-08-08) 5 commits
  (merged to 'next' on 2022-08-10 at 3d32a87210)
 + mingw: handle a file owned by the Administrators group correctly
 + mingw: be more informative when ownership check fails on FAT32
 + mingw: provide details about unsafe directories' ownership
 + setup: prepare for more detailed "dubious ownership" messages
 + setup: fix some formatting
 Platform-specific code that determines if a directory is OK to use
 as a repository has been taught to report more details, especially
 on Windows.
 source: <pull.1286.v2.git.1659965270.gitgitgadget@gmail.com>
* lt/symbolic-ref-sanity (2022-08-01) 1 commit
  (merged to 'next' on 2022-08-03 at 443647b94a)
 + symbolic-ref: refuse to set syntactically invalid target
 "git symbolic-ref symref non..sen..se" is now diagnosed as an error.
 source: <YugYNzQYWqDCmOqN@coredump.intra.peff.net>
* pw/use-glibc-tunable-for-malloc-optim (2022-08-04) 1 commit
  (merged to 'next' on 2022-08-08 at 1300f84dc4)
 + tests: cache glibc version check
 Avoid repeatedly running getconf to ask libc version in the test
 suite, and instead just as it once per script.
 source: <pull.1311.git.1659620305757.gitgitgadget@gmail.com>

-------------------------------------------------- [New Topics]

* ll/disk-usage-humanise (2022-08-11) 1 commit
  (merged to 'next' on 2022-08-14 at 3873a83f90)
 + rev-list: support human-readable output for `--disk-usage`
 "git rev-list --disk-usage" learned to take an optional value
 "human" to show the reported value in human-readable format, like
 "3.40MiB".
 Will merge to 'master'.
 source: <pull.1313.v5.git.1660193274336.gitgitgadget@gmail.com>
* ed/fsmonitor-on-network-disk (2022-08-11) 1 commit
  (merged to 'next' on 2022-08-14 at 637d458d9c)
 + fsmonitor: option to allow fsmonitor to run against network-mounted repos
 The built-in fsmonitor refuses to work on a network mounted
 repositories; a configuration knob for users to override this has
 been introduced.
 Will merge to 'master'.
 source: <pull.1317.v4.git.1660262231357.gitgitgadget@gmail.com>
* jk/is-promisor-object-keep-tree-in-use (2022-08-14) 1 commit
 - is_promisor_object(): fix use-after-free of tree buffer
 An earlier optimization discarded a tree-object buffer that is
 still in use, which has been corrected.
 Will merge to 'next'.
 source: <YviWO9Bhz5PU1HaL@coredump.intra.peff.net>
* js/fetch-negotiation-trace (2022-08-15) 1 commit
 - fetch-pack: add tracing for negotiation rounds
 The common ancestor negotiation exchange during a "git fetch"
 session now leaves trace log.
 Will merge to 'next'.
 source: <4390677ec75d51487142adf7c2ab821cbd24a53e.1659477669.git.steadmon@google.com>
* pw/rebase-keep-base-fixes (2022-08-15) 5 commits
 - rebase --keep-base: imply --no-fork-point
 - rebase --keep-base: imply --reapply-cherry-picks
 - rebase: factor out merge_base calculation
 - rebase: store orig_head as a commit
 - t3416: set $EDITOR in subshell
 "git rebase --keep-base" used to discard the commits that are
 already cherry-picked to the upstream, even when "keep-base" meant
 that the base, on top of which the history is being rebuilt, does
 not yet include these cherry-picked commits.  The --keep-base
 option now implies --reapply-cherry-picks and --no-fork-point
 options.
 Needs review.
 source: <pull.1323.git.1660576283.gitgitgadget@gmail.com>

-------------------------------------------------- [Cooking]

* fc/vimdiff-layout-vimdiff3-fix (2022-08-10) 7 commits
  (merged to 'next' on 2022-08-11 at a14fec292f)
 + mergetools: vimdiff: simplify tabfirst
 + mergetools: vimdiff: fix single window layouts
 + mergetools: vimdiff: rework tab logic
 + mergetools: vimdiff: fix for diffopt
 + mergetools: vimdiff: silence annoying messages
 + mergetools: vimdiff: make vimdiff3 actually work
 + mergetools: vimdiff: fix comment
 "vimdiff3" regression fix.
 Will merge to 'master'.
 source: <20220810154618.307275-1-felipe.contreras@gmail.com>
* jk/fsck-tree-mode-bits-fix (2022-08-10) 3 commits
  (merged to 'next' on 2022-08-11 at 219fe53025)
 + fsck: downgrade tree badFilemode to "info"
 + fsck: actually detect bad file modes in trees
 + tree-walk: add a mechanism for getting non-canonicalized modes
 "git fsck" reads mode from tree objects but canonicalizes the mode
 before passing it to the logic to check object sanity, which has
 hid broken tree objects from the checking logic.  This has been
 corrected, but to help exiting projects with broken tree objects
 that they cannot fix retroactively, the severity of anomalies this
 code detects has been demoted to "info" for now.
 Will merge to 'master'.
 source: <YvQcNpizy9uOZiAz@coredump.intra.peff.net>
* ag/merge-strategies-in-c (2022-08-10) 14 commits
 - sequencer: use the "octopus" strategy without forking
 - sequencer: use the "resolve" strategy without forking
 - merge: use the "octopus" strategy without forking
 - merge: use the "resolve" strategy without forking
 - merge-octopus: rewrite in C
 - merge-recursive: move better_branch_name() to merge.c
 - merge-resolve: rewrite in C
 - merge-one-file: rewrite in C
 - update-index: move add_cacheinfo() to read-cache.c
 - merge-index: add a new way to invoke `git-merge-one-file'
 - merge-index: drop the index
 - merge-index: libify merge_one_path() and merge_all()
 - t6060: add tests for removed files
 - t6060: modify multiple files to expose a possible issue with merge-index
 An attempt to rewrite remaining merge strategies from shell to C.
 source: <20220809185429.20098-1-alban.gruin@gmail.com>
* sy/mv-out-of-cone (2022-08-10) 9 commits
 - mv: check overwrite for in-to-out move
 - advice.h: add advise_on_moving_dirty_path()
 - mv: cleanup empty WORKING_DIRECTORY
 - mv: from in-cone to out-of-cone
 - mv: remove BOTH from enum update_mode
 - mv: check if <destination> is a SKIP_WORKTREE_DIR
 - mv: free the with_slash in check_dir_in_index()
 - mv: rename check_dir_in_index() to empty_dir_has_sparse_contents()
 - t7002: add tests for moving from in-cone to out-of-cone
 "git mv A B" in a sparsely populated working tree can be asked to
 move a path from a directory that is "in cone" to another directory
 that is "out of cone".  Handling of such a case has been improved.
 Will merge to 'next'?
 source: <20220809120910.2021413-1-shaoxuan.yuan02@gmail.com>
* sy/sparse-rm (2022-08-08) 5 commits
  (merged to 'next' on 2022-08-12 at 5bf10965fb)
 + rm: integrate with sparse-index
 + rm: expand the index only when necessary
 + pathspec.h: move pathspec_needs_expanded_index() from reset.c to here
 + t1092: add tests for `git-rm`
 + Merge branch 'vd/sparse-reset-checkout-fixes' into sy/sparse-rm
 (this branch uses vd/sparse-reset-checkout-fixes.)
 "git rm" has become more aware of the sparse-index feature.
 Will merge to 'master'.
 source: <20220807041335.1790658-1-shaoxuan.yuan02@gmail.com>
* vd/scalar-generalize-diagnose (2022-08-12) 11 commits
 - scalar: update technical doc roadmap
 - scalar-diagnose: use 'git diagnose --mode=all'
 - builtin/bugreport.c: create '--diagnose' option
 - builtin/diagnose.c: add '--mode' option
 - builtin/diagnose.c: create 'git diagnose' builtin
 - diagnose.c: add option to configure archive contents
 - scalar-diagnose: move functionality to common location
 - scalar-diagnose: move 'get_disk_info()' to 'compat/'
 - scalar-diagnose: add directory to archiver more gently
 - scalar-diagnose: avoid 32-bit overflow of size_t
 - scalar-diagnose: use "$GIT_UNZIP" in test
 The "diagnose" feature to create a zip archive for diagnostic
 material has been lifted from "scalar" and made into a feature of
 "git bugreport".
 Will merge to 'next'?
 source: <pull.1310.v4.git.1660335019.gitgitgadget@gmail.com>
* jk/pipe-command-nonblock (2022-08-03) 1 commit
 - pipe_command(): mark stdin descriptor as non-blocking
 Fix deadlocks between main Git process and subprocess spawned via
 the pipe_command() API, that can kill "git add -p" that was
 reimplemented in C recently.
 Needs waiting for corresponding change to Windows to put the pipe
 into nonblock mode.
 cf. <YulFTSTbVaTwuQtt@coredump.intra.peff.net>
 source: <YunxHOa2sJeEpJxd@coredump.intra.peff.net>
* es/mark-gc-cruft-as-experimental (2022-08-03) 2 commits
 - config: let feature.experimental imply gc.cruftPacks=true
 - gc: add tests for --cruft and friends
 Enable gc.cruftpacks by default for those who opt into
 feature.experimental setting.
 Expecting a reroll.
 cf. <220804.86a68ke9d5.gmgdl@evledraar.gmail.com>
 cf. <6803b725-526e-a1c8-f15c-a9ed4a144d4c@github.com>
 source: <20220803205721.3686361-1-emilyshaffer@google.com>
* vd/sparse-reset-checkout-fixes (2022-08-08) 4 commits
  (merged to 'next' on 2022-08-12 at 755d6ecdb8)
 + unpack-trees: unpack new trees as sparse directories
 + cache.h: create 'index_name_pos_sparse()'
 + oneway_diff: handle removed sparse directories
 + checkout: fix nested sparse directory diff in sparse index
 (this branch is used by sy/sparse-rm.)
 Fixes to sparse index compatibility work for "reset" and "checkout"
 commands.
 Will merge to 'master'.
 source: <pull.1312.v3.git.1659985672.gitgitgadget@gmail.com>
* sg/parse-options-subcommand (2022-07-25) 20 commits
 - builtin/worktree.c: let parse-options parse subcommands
 - builtin/stash.c: let parse-options parse subcommands
 - builtin/sparse-checkout.c: let parse-options parse subcommands
 - builtin/remote.c: let parse-options parse subcommands
 - builtin/reflog.c: let parse-options parse subcommands
 - builtin/notes.c: let parse-options parse subcommands
 - builtin/multi-pack-index.c: let parse-options parse subcommands
 - builtin/hook.c: let parse-option parse subcommands
 - builtin/gc.c: let parse-options parse 'git maintenance's subcommands
 - builtin/commit-graph.c: let parse-options parse subcommands
 - builtin/bundle.c: let parse-options parse subcommands
 - parse-options: add support for parsing subcommands
 - parse-options: drop leading space from '--git-completion-helper' output
 - parse-options: clarify the limitations of PARSE_OPT_NODASH
 - parse-options: PARSE_OPT_KEEP_UNKNOWN only applies to --options
 - api-parse-options.txt: fix description of OPT_CMDMODE
 - t0040-parse-options: test parse_options() with various 'parse_opt_flags'
 - t5505-remote.sh: check the behavior without a subcommand
 - t3301-notes.sh: check that default operation mode doesn't take arguments
 - git.c: update NO_PARSEOPT markings
 Introduce the "subcommand" mode to parse-options API and update the
 command line parser of Git commands with subcommands.
 Expecting a reroll.
 cf. <20220812152837.GC3790@szeder.dev>
 source: <20220725123857.2773963-1-szeder.dev@gmail.com>
* ds/bundle-uri-clone (2022-08-10) 5 commits
 - clone: --bundle-uri cannot be combined with --depth
 - bundle-uri: add support for http(s):// and file://
 - clone: add --bundle-uri option
 - bundle-uri: create basic file-copy logic
 - remote-curl: add 'get' capability
 Implement "git clone --bundle-uri".
 source: <pull.1300.v3.git.1660050703.gitgitgadget@gmail.com>
* ds/decorate-filter-tweak (2022-08-05) 11 commits
 - fetch: use ref_namespaces during prefetch
 - maintenance: stop writing log.excludeDecoration
 - log: create log.initialDecorationSet=all
 - log: add --clear-decorations option
 - log: add default decoration filter
 - log-tree: use ref_namespaces instead of if/else-if
 - refs: use ref_namespaces for replace refs base
 - refs: add array of ref namespaces
 - t4207: test coloring of grafted decorations
 - t4207: modernize test
 - refs: allow "HEAD" as decoration filter
 The namespaces used by "log --decorate" from "refs/" hierarchy by
 default has been tightened.
 Will merge to 'next'?
 source: <pull.1301.v3.git.1659722323.gitgitgadget@gmail.com>
* es/doc-creation-factor-fix (2022-07-28) 2 commits
 - range-diff: clarify --creation-factor=<factor>
 - format-patch: clarify --creation-factor=<factor>
 Expecting a reroll.
 source: <7229p500-p2r4-on87-6802-8o90s36rr3s4@tzk.qr>
* ab/submodule-helper-prep (2022-08-03) 28 commits
 - submodule--helper: fix bad config API usage
 - submodule--helper: libify "must_die_on_failure" code paths (for die)
 - submodule--helper: libify "must_die_on_failure" code paths
 - submodule--helper: libify determine_submodule_update_strategy()
 - submodule--helper: don't exit() on failure, return
 - submodule--helper: use "code" in run_update_command()
 - submodule--helper: move submodule_strategy_to_string() to only user
 - submodule--helper: don't call submodule_strategy_to_string() in BUG()
 - submodule--helper: add missing braces to "else" arm
 - submodule--helper: return "ret", not "1" from update_submodule()
 - submodule--helper: rename "int res" to "int ret"
 - submodule--helper: don't redundantly check "else if (res)"
 - submodule--helper: refactor "errmsg_str" to be a "struct strbuf"
 - submodule--helper: add "const" to copy of "update_data"
 - submodule--helper: pass a "const struct module_clone_data" to clone_submodule()
 - submodule--helper: move "sb" in clone_submodule() to its own scope
 - submodule--helper: use xstrfmt() in clone_submodule()
 - submodule--helper: replace memset() with { 0 }-initialization
 - submodule--helper style: add \n\n after variable declarations
 - submodule--helper style: don't separate declared variables with \n\n
 - submodule--helper: move "resolve-relative-url-test" to a test-tool
 - submodule--helper: move "check-name" to a test-tool
 - submodule--helper: move "is-active" to a test-tool
 - test-tool submodule-config: remove unused "--url" handling
 - submodule--helper: remove unused "list" helper
 - submodule--helper: remove unused "name" helper
 - submodule tests: test for "add <repository> <abs-path>"
 - submodule tests: test usage behavior
 (this branch is used by ab/submodule-helper-leakfix.)
 Code clean-up of "git submodule--helper".
 Expecting a (hopefully final?) reroll.
 cf. <220803.86h72tfpcc.gmgdl@evledraar.gmail.com>
 source: <cover-v2-00.28-00000000000-20220802T154036Z-avarab@gmail.com>
* ab/dedup-config-and-command-docs (2022-07-29) 9 commits
 - docs: add CONFIGURATION sections that fuzzy map to built-ins
 - docs: add CONFIGURATION sections that map to a built-in
 - log docs: de-duplicate configuration sections
 - difftool docs: de-duplicate configuration sections
 - notes docs: de-duplicate configuration sections
 - apply docs: de-duplicate configuration sections
 - send-email docs: de-duplicate configuration sections
 - grep docs: de-duplicate configuration sections
 - docs: add and use include template for config/* includes
 Share the text used to explain configuration variables used by "git
 <subcmd>" in "git help <subcmd>" with the text from "git help config".
 Expecting a reroll.
 cf. <CAHd-oW5mD-H1kvuF9VEVb8KjaSkUSUpBH-WAkpCn6_Ci8o888w@mail.gmail.com>
 cf. <CAHd-oW7s6Hu24uTjCW9ROBbJkA5+7TCu32a4L_BXVLhcvw5kSw@mail.gmail.com>
 cf. <xmqqlesb4lwh.fsf@gitster.g>
 source: <cover-v2-0.9-00000000000-20220729T081959Z-avarab@gmail.com>
* cw/remote-object-info (2022-08-13) 7 commits
 - SQUASH???
 - cat-file: add remote-object-info to batch-command
 - transport: add client support for object-info
 - serve: advertise object-info feature
 - protocol-caps: initialization bug fix
 - fetch-pack: move fetch initialization
 - fetch-pack: refactor packet writing
 A client component to talk with the object-info endpoint.
 Expecting a reroll.
 cf. <20220728230210.2952731-1-calvinwan@google.com>
 cf. <CAFySSZDvgwbbHCHfyuaqX3tKsr-GjJ9iihygg6rNNe46Ys7_EA@mail.gmail.com>
 source: <20220728230210.2952731-1-calvinwan@google.com>
* mt/rot13-in-c (2022-08-14) 4 commits
 - tests: use the new C rot13-filter helper to avoid PERL prereq
 - t0021: implementation the rot13-filter.pl script in C
 - t0021: avoid grepping for a Perl-specific string at filter output
 - Merge branch 'mt/checkout-count-fix' into mt/rot13-in-c
 Test portability improvements.
 Will merge to 'next'?
 source: <cover.1660522524.git.matheus.bernardino@usp.br>
* tl/trace2-config-scope (2022-08-11) 2 commits
 - tr2: shows scope unconditionally in addition to key-value pair
 - api-trace2.txt: print config key-value pair
 Tweak trace2 output about configuration variables.
 source: <cover.1660272404.git.dyroneteng@gmail.com>
* ab/submodule-helper-leakfix (2022-08-03) 18 commits
 - submodule--helper: fix a configure_added_submodule() leak
 - submodule--helper: free rest of "displaypath" in "struct update_data"
 - submodule--helper: free some "displaypath" in "struct update_data"
 - submodule--helper: fix a memory leak in print_status()
 - submodule--helper: fix a leak in module_add()
 - submodule--helper: fix obscure leak in module_add()
 - submodule--helper: fix "reference" leak
 - submodule--helper: fix a memory leak in get_default_remote_submodule()
 - submodule--helper: fix a leak with repo_clear()
 - submodule--helper: fix "sm_path" and other "module_cb_list" leaks
 - submodule--helper: fix "errmsg_str" memory leak
 - submodule--helper: add and use *_release() functions
 - submodule--helper: don't leak {run,capture}_command() cp.dir argument
 - submodule--helper: "struct pathspec" memory leak in module_update()
 - submodule--helper: fix most "struct pathspec" memory leaks
 - submodule--helper: fix trivial get_default_remote_submodule() leak
 - submodule--helper: fix a leak in "clone_submodule"
 - Merge branch 'ab/submodule-helper-prep' into ab/submodule-helper-leakfix
 (this branch uses ab/submodule-helper-prep.)
 Plugging leaks in submodule--helper.
 Getting there.
 source: <cover-v5-00.17-00000000000-20220802T155002Z-avarab@gmail.com>
* cw/submodule-merge-messages (2022-08-04) 1 commit
  (merged to 'next' on 2022-08-12 at ede0890319)
 + submodule merge: update conflict error message
 Update the message given when "git merge" sees conflicts at a path
 with a submodule while merging a superproject.
 Will merge to 'master'.
 source: <20220804195105.1303455-1-calvinwan@google.com>
* po/doc-add-renormalize (2022-08-10) 1 commit
  (merged to 'next' on 2022-08-11 at 53851663eb)
 + doc add: renormalize is not idempotent for CRCRLF
 Documentation for "git add --renormalize" has been improved.
 Will merge to 'master'.
 source: <20220810144450.470-2-philipoakley@iee.email>
* 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.
 Expecting a reroll.
 cf. <dfe0c1ab-33f8-f13e-71ce-1829bb0d2d7f@iee.email>
 source: <pull.1282.git.1657385781.gitgitgadget@gmail.com>
* ac/bitmap-lookup-table (2022-08-14) 6 commits
 - 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
 - bitmap: move `get commit positions` code to `bitmap_writer_finish`
 - 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.
 source: <pull.1266.v6.git.1660496112.gitgitgadget@gmail.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>
* 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-08-10) 2 commits
  (merged to 'next' on 2022-08-12 at 4f445a058d)
 + bundle-uri: add example bundle organization
 + docs: document bundle URI standard
 The "bundle URI" design gets documented.
 Will merge to 'master'.
 source: <pull.1248.v4.git.1660050761.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>

-------------------------------------------------- [Discarded]

* mb/doc-rerere-autoupdate (2022-07-15) 1 commit
 . cherry-pick doc: clarify no-rerere-autoupdate still allows rerere
 Clarifies that the "--no-rerere-autoupdate" option does not disable
 the "rerere" mechanism (nor does "--rerere-autoupdate" enable it).
 Superseded by jc/rerere-autoupdate-doc
 source: <20220715092527.1567837-1-mail@beyermatthias.de>
* fr/vimdiff-layout-colors-fix (2022-08-07) 3 commits
 . mergetools: vimdiff: update unit tests
 . mergetools: vimdiff: fix single tab mode, single window mode and colors
 . mergetools: vimdiff: fix comment
 "vimdiff3" regression fix.
 Superseded by fc/vimdiff-layout-vimdiff3-fix
 source: <20220808053459.184367-1-greenfoo@u92.eu>
* 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.
 In stalled state for too long.
 source: <pull.1257.v2.git.1655655027.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.
 In stalled state for too long.
 cf. <YnL2d4Vr9Vr7W4Hj@camp.crustytoothpaste.net>
 source: <20220407215352.3491567-1-sandals@crustytoothpaste.net>
Johannes Schindelin· Aug 16, 2022, 08:56 UTC · re: Junio C Hamano · lore

js/bisect-in-c, was Re: What's cooking in git.git (Aug 2022, #05; Mon, 15)

Hi Junio,
On Mon, 15 Aug 2022, Junio C Hamano wrote:
Show 23 quoted lines
> * 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>

I had another look at the thread and did not see any feedback that focuses on the actual scope of the patch series. Conversions from scripted parts of Git to built-ins are always a bit finicky (and hard to review, I admit).

Therefore I would like to move the status to "needs review".

I do not think that there are any major issues with it (Ævar's feedback notwithstanding, it focuses on tangents that should be addressed after the conversion, to avoid losing focus), but I would love to see a thorough review of the conversion to avoid obvious regressions like the one in the built-in interactive `add` I had to fix recently.

Ciao, Dscho

Elijah Newren· Aug 17, 2022, 01:26 UTC · re: Johannes Schindelin · lore

Re: js/bisect-in-c, was Re: What's cooking in git.git (Aug 2022, #05; Mon, 15)

Hi,

On Tue, Aug 16, 2022 at 3:49 AM Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:

Show 27 quoted lines
>
> Hi Junio,
>
> On Mon, 15 Aug 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>
Junio: This link came up dead for me; I think the intended link was
220627.86ilolhnnn.gmgdl@evledraar.gmail.com ?
Show 14 quoted lines
> >  source: <pull.1132.v4.git.1656354677.gitgitgadget@gmail.com>
>
> I had another look at the thread and did not see any feedback that focuses
> on the actual scope of the patch series. Conversions from scripted parts
> of Git to built-ins are always a bit finicky (and hard to review, I
> admit).
>
> Therefore I would like to move the status to "needs review".
>
> I do not think that there are any major issues with it (Ævar's feedback
> notwithstanding, it focuses on tangents that should be addressed after the
> conversion, to avoid losing focus), but I would love to see a thorough
> review of the conversion to avoid obvious regressions like the one in the
> built-in interactive `add` I had to fix recently.

I reviewed it -- https://lore.kernel.org/git/CABPp-BEOX+zxR9-yyx-EaiOV-Z9yD0YP_Kwvu4iGB8enz40XXQ@mail.gmail.com/. I looked over the subsequent iterations too, and they still look good to me.

Could I vote for just merging it down, as-is? As far as I can tell, this series was stalled for 6-7 months over "doesn't use parse_options() API", even though Dscho addressed that directly in v1 in one of his commit messages stating he had already investigated that route and found it wanting, at least in its current state[1]. It appears, from my reading, that using parse_options() API was insisted upon...though it turns out that making parse_options() capable of handling such things is at least another 20-patch series[2] (which may not be enough either[3]). Further, such changes, while likely desirable for consistency among Git commands, would likely move us away from "faithful conversion from shell to C", and thus is likely better to be done as a separate step on top of the existing series anyway[4].

If we merge down, as-is, then Ævar can go to town on it, possibly using SZEDER's changes[2], and convert the new bisect code over to using parse_options(), and show Dscho what he meant by how it could be done. Maybe Ævar will even demonstrate that it is quite simple to do. Or, perhaps, Ævar will discover what Dscho did and agree that parse_options() really can't handle that case. I wouldn't be surprised by either outcome. Either way, I think it'd resolve the issue much faster than going round and round in discussions.

And I think the result would be more to everyone's liking -- Dscho gets to concentrate on the stuff he cares about (user experience, converting shell to C faithfully), and Ævar gets to concentrate on the stuff he cares about (internal code consistency, tree-wide refactorings). And in the meantime, the rest of us get to enjoy the fruits of three separate GSoC projects plus Dscho's attempt to tie it all together. I think Dscho's Dscho's submission improves upon current Git and is good enough to merge, even if there may be ways to make it even better.

Anyway, just my $0.02.

[1] https://lore.kernel.org/git/515e86e20758ed7f5b4a8ce8f38bfbbac27ec42a.1643328752.git.gitgitgadget@gmail.com/ [2] https://lore.kernel.org/git/20220812150420.GA3790@szeder.dev/ [3] https://lore.kernel.org/git/1p04q351-9938-r0r7-snr6-9s8237s27459@tzk.qr/ [4] https://lore.kernel.org/git/8o63pp64-4s00-1000-42s1-38so68398337@tzk.qr/

Johannes Schindelin· Aug 17, 2022, 06:27 UTC · re: Elijah Newren · lore

Re: js/bisect-in-c, was Re: What's cooking in git.git (Aug 2022, #05; Mon, 15)

Hi Elijah,
On Tue, 16 Aug 2022, Elijah Newren wrote:
Show 30 quoted lines
> On Tue, Aug 16, 2022 at 3:49 AM Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
> >
> > On Mon, 15 Aug 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>
>
> Junio: This link came up dead for me; I think the intended link was
> 220627.86ilolhnnn.gmgdl@evledraar.gmail.com ?

I had mentioned this in https://lore.kernel.org/git/s3726r9p-r96o-7793-0qrq-o54rs4npr972@tzk.qr/ but failed to ask Junio to change it in the What's cooking mails. Thank you for pointing it out, too.

Show 19 quoted lines
> > >  source: <pull.1132.v4.git.1656354677.gitgitgadget@gmail.com>
> >
> > I had another look at the thread and did not see any feedback that focuses
> > on the actual scope of the patch series. Conversions from scripted parts
> > of Git to built-ins are always a bit finicky (and hard to review, I
> > admit).
> >
> > Therefore I would like to move the status to "needs review".
> >
> > I do not think that there are any major issues with it (Ævar's feedback
> > notwithstanding, it focuses on tangents that should be addressed after the
> > conversion, to avoid losing focus), but I would love to see a thorough
> > review of the conversion to avoid obvious regressions like the one in the
> > built-in interactive `add` I had to fix recently.
>
> I reviewed it --
> https://lore.kernel.org/git/CABPp-BEOX+zxR9-yyx-EaiOV-Z9yD0YP_Kwvu4iGB8enz40XXQ@mail.gmail.com/.
> I looked over the subsequent iterations too, and they still look good
> to me.

Ooops. I am sorry for misrepresenting the situation. I honestly had forgotten that the patch series did, in fact, receive a good and thorough review.

My apologies and thank you so much for all your help! Dscho

Junio C Hamano· Aug 17, 2022, 18:57 UTC · re: Elijah Newren · lore

Re: js/bisect-in-c, was Re: What's cooking in git.git (Aug 2022, #05; Mon, 15)

Elijah Newren <newren@gmail.com> writes:
Show 9 quoted lines
>> >  Expecting a (hopefully final) reroll.
>> ...
>
> Could I vote for just merging it down, as-is?  As far as I can tell,
> ... Further, such changes, while likely
> desirable for consistency among Git commands, would likely move us
> away from "faithful conversion from shell to C", and thus is likely
> better to be done as a separate step on top of the existing series
> anyway[4].

If this were a faithful conversion, yes, merging it right now can be one good approach; add a faithful but not very C-like convesion first and then make it "more like C code" later.

I however got an impression from the review discussion that it subtly changes behaviour (IIRC, one thing pointed out was that exit codes are now different from the original---there may or may not be others, but my impression was they were all minor like the "exit code" one).

My "hopefully final" comment was not about a big rearchitecting change like use of parse-options API but about adjusting such minor behaviour diversion so that we can say "This may not be very C-like, and does not use much of our established API, but it is a fairly faithful bug-to-bug compatible translation. Let's take it and make it more like C incrementally". And of course, what was implied in "hopefully final" was that such adjustments would be tiny, trivial and can be done without much controversy. After all, I was aware that the series was otherwise reviewed and received extensive comments (sorry, I forgot that it was by you).

Thanks.
Elijah Newren· Aug 17, 2022, 19:24 UTC · re: Junio C Hamano · lore

Re: js/bisect-in-c, was Re: What's cooking in git.git (Aug 2022, #05; Mon, 15)

On Wed, Aug 17, 2022 at 11:57 AM Junio C Hamano <gitster@pobox.com> wrote:
Show 35 quoted lines
>
> Elijah Newren <newren@gmail.com> writes:
>
> >> >  Expecting a (hopefully final) reroll.
> >> ...
> >
> > Could I vote for just merging it down, as-is?  As far as I can tell,
> > ... Further, such changes, while likely
> > desirable for consistency among Git commands, would likely move us
> > away from "faithful conversion from shell to C", and thus is likely
> > better to be done as a separate step on top of the existing series
> > anyway[4].
>
> If this were a faithful conversion, yes, merging it right now can be
> one good approach; add a faithful but not very C-like convesion
> first and then make it "more like C code" later.
>
> I however got an impression from the review discussion that it
> subtly changes behaviour (IIRC, one thing pointed out was that exit
> codes are now different from the original---there may or may not be
> others, but my impression was they were all minor like the "exit
> code" one).
>
> My "hopefully final" comment was not about a big rearchitecting
> change like use of parse-options API but about adjusting such minor
> behaviour diversion so that we can say "This may not be very C-like,
> and does not use much of our established API, but it is a fairly
> faithful bug-to-bug compatible translation.  Let's take it and make
> it more like C incrementally".  And of course, what was implied in
> "hopefully final" was that such adjustments would be tiny, trivial
> and can be done without much controversy.  After all, I was aware
> that the series was otherwise reviewed and received extensive
> comments (sorry, I forgot that it was by you).
>
> Thanks.

Ah, gotcha. My impression was that the exit codes did match what the previous shell code had done, but didn't match what other builtins usually return. Perhaps I misread those discussion comments.

Thanks for the clarification.
Junio C Hamano· Aug 17, 2022, 20:05 UTC · re: Elijah Newren · lore

Re: js/bisect-in-c, was Re: What's cooking in git.git (Aug 2022, #05; Mon, 15)

Elijah Newren <newren@gmail.com> writes:
> Ah, gotcha.  My impression was that the exit codes did match what the
> previous shell code had done, but didn't match what other builtins
> usually return.  Perhaps I misread those discussion comments.
Or perhaps I did ;-)

The topic has been waiting for the finishing polish for so long that I do not remember the details of the discussion offhand, certainly not better than I did when I left the note in the "What's cooking" report.

Johannes Schindelin· Aug 19, 2022, 11:04 UTC · re: Junio C Hamano · lore

Re: js/bisect-in-c, was Re: What's cooking in git.git (Aug 2022, #05; Mon, 15)

Hi Junio,
On Wed, 17 Aug 2022, Junio C Hamano wrote:
Show 7 quoted lines
> Elijah Newren <newren@gmail.com> writes:
>
> > Ah, gotcha.  My impression was that the exit codes did match what the
> > previous shell code had done, but didn't match what other builtins
> > usually return.  Perhaps I misread those discussion comments.
>
> Or perhaps I did ;-)

The exit codes before and after this patch series are a red herring. The _current_ code prints this when calling `git bisect start -h`:

	$ git bisect start -h
	usage: git bisect--helper --bisect-reset [<commit>]
	   or: git bisect--helper --bisect-terms [--term-good | --term-old | --term-bad | --term-new]
	   or: git bisect--helper --bisect-start [--term-{new,bad}=<term> --term-{old,good}=<term>] [--no-checkout] [--first-parent] [<bad> [<good>...]] [--] [<paths>...]
	   or: git bisect--helper --bisect-next
	   or: git bisect--helper --bisect-state (bad|new) [<rev>]
	   or: git bisect--helper --bisect-state (good|old) [<rev>...]
	   or: git bisect--helper --bisect-replay <filename>
	   or: git bisect--helper --bisect-skip [(<rev>|<range>)...]
	   or: git bisect--helper --bisect-visualize
	   or: git bisect--helper --bisect-run <cmd>...
	    --bisect-reset        reset the bisection state
	    --bisect-next-check   check whether bad or good terms exist
	    --bisect-terms        print out the bisect terms
	    --bisect-start        start the bisect session
	    --bisect-next         find the next bisection commit
	    --bisect-state        mark the state of ref (or refs)
	    --bisect-log          list the bisection steps so far
	    --bisect-replay       replay the bisection process from the given file
	    --bisect-skip         skip some commits for checkout
	    --bisect-visualize    visualize the bisection
	    --bisect-run          use <cmd>... to automatically bisect
	    --no-log              no log for BISECT_WRITE
Notice how this talks about `bisect--helper` and about `--bisect-reset`.
Also, the _current_ code exits with code 0 when calling `git bisect -h`.

This has been the case even as far back as v2.25.1, and possibly even longer.

Given these issues, I was mistakenly assuming that it would be okay to postpone these problems that are exclusively related to incorrect invocation of `git bisect`, and that it would make sense to focus on the conversion from shell code to C in _this_ patch series, and take care of these problems afterwards, instead of hodgepodging fixes for them into the same patch series as the conversion to C, the latter being hard enough to review as it stands, so much so that it received only a single high quality review.

But I see that you somehow got the idea that the review that lacked attention to the common code path somehow was a valid review and you somehow got it in your mind that this was valid feedback and that the patch series needs to be reworked so that it _also_ addresses issues that have been broken _before_ it.

Fine.

I'll try to get to it next week. It does leave a foul taste that we're not separating concerns properly in the Git project, but block a patch series that has a specific, already large scope, just because one reviewer wants it to have another scope and for some reason that now must be the scope of the patch series.

Ciao, Dscho

Ævar Arnfjörð Bjarmason· Aug 19, 2022, 14:40 UTC · re: Johannes Schindelin · lore

Re: js/bisect-in-c, was Re: What's cooking in git.git (Aug 2022, #05; Mon, 15)

On Fri, Aug 19 2022, Johannes Schindelin wrote:
Show 61 quoted lines
> Hi Junio,
>
> On Wed, 17 Aug 2022, Junio C Hamano wrote:
>
>> Elijah Newren <newren@gmail.com> writes:
>>
>> > Ah, gotcha.  My impression was that the exit codes did match what the
>> > previous shell code had done, but didn't match what other builtins
>> > usually return.  Perhaps I misread those discussion comments.
>>
>> Or perhaps I did ;-)
>
> The exit codes before and after this patch series are a red herring. The
> _current_ code prints this when calling `git bisect start -h`:
>
> 	$ git bisect start -h
> 	usage: git bisect--helper --bisect-reset [<commit>]
> 	   or: git bisect--helper --bisect-terms [--term-good | --term-old | --term-bad | --term-new]
> 	   or: git bisect--helper --bisect-start [--term-{new,bad}=<term> --term-{old,good}=<term>] [--no-checkout] [--first-parent] [<bad> [<good>...]] [--] [<paths>...]
> 	   or: git bisect--helper --bisect-next
> 	   or: git bisect--helper --bisect-state (bad|new) [<rev>]
> 	   or: git bisect--helper --bisect-state (good|old) [<rev>...]
> 	   or: git bisect--helper --bisect-replay <filename>
> 	   or: git bisect--helper --bisect-skip [(<rev>|<range>)...]
> 	   or: git bisect--helper --bisect-visualize
> 	   or: git bisect--helper --bisect-run <cmd>...
>
> 	    --bisect-reset        reset the bisection state
> 	    --bisect-next-check   check whether bad or good terms exist
> 	    --bisect-terms        print out the bisect terms
> 	    --bisect-start        start the bisect session
> 	    --bisect-next         find the next bisection commit
> 	    --bisect-state        mark the state of ref (or refs)
> 	    --bisect-log          list the bisection steps so far
> 	    --bisect-replay       replay the bisection process from the given file
> 	    --bisect-skip         skip some commits for checkout
> 	    --bisect-visualize    visualize the bisection
> 	    --bisect-run          use <cmd>... to automatically bisect
> 	    --no-log              no log for BISECT_WRITE
>
> Notice how this talks about `bisect--helper` and about `--bisect-reset`.
>
> Also, the _current_ code exits with code 0 when calling `git bisect -h`.
>
> This has been the case even as far back as v2.25.1, and possibly even
> longer.
>
> Given these issues, I was mistakenly assuming that it would be okay to
> postpone these problems that are exclusively related to incorrect
> invocation of `git bisect`, and that it would make sense to focus on the
> conversion from shell code to C in _this_ patch series, and take care of
> these problems afterwards, instead of hodgepodging fixes for them into the
> same patch series as the conversion to C, the latter being hard enough to
> review as it stands, so much so that it received only a single high
> quality review.
>
> But I see that you somehow got the idea that the review that lacked
> attention to the common code path somehow was a valid review and you
> somehow got it in your mind that this was valid feedback and that the
> patch series needs to be reworked so that it _also_ addresses issues that
> have been broken _before_ it.

I really think these remarks about "high quality review" and "the review that lacked attention" are overly snide and don't contribute to a friendly ML atmosphere.

We can all be wrong about stuff, e.g. [1] is one very recent case where I just plain misread something in a review. But can we just ask for a clarification etc?

In this case I fully agree with you that any existing issues in the conversion of bisect to C should be out of scope for your series, but that's not what your series is doing.

I've specifically been pointing out issues where the behavior is changed as a result.

For example, on "master" (and there's a lot more of these):
	$ ./git --exec-path=$PWD bisect terms a b c; echo $?
	error: --bisect-terms requires 0 or 1 argument
	255
On "seen", with your series:
	$ ./git --exec-path=$PWD bisect terms a b c; echo $?
	fatal: 'terms' requires 0 or 1 argument
        128

That's one of the things I pointed out to you, and clearly a behavior change in both the exit code emitted, and the message emitted.

I don't think it's unacceptable to have some behavior change as we migrate to the C version.

I'd just pointed out cases where that either seemed unnecessary, or migrated to some unusual pattern. E.g in the case of exiting with code 128 instead of 129 on usage errors, as we usually do.

Show 5 quoted lines
> I'll try to get to it next week. It does leave a foul taste that we're not
> separating concerns properly in the Git project, but block a patch series
> that has a specific, already large scope, just because one reviewer wants
> it to have another scope and for some reason that now must be the scope of
> the patch series.

I'd really like you to find and quote back to me somewhere I've attempted to "block" these patches, or anything of the kind. That's simply not true.

If you had actually asked: Aside from any outstanding issues with your series, I think as it stands that it's a net improvement on "master". I would not mind it advanced in its current state. We can fix any outstanding issues with it later, particularly due to what seem like time constraints on your end, and how unproductive reviewing it seems to be getting.

I think the only thing I've said which could be construed as "blocking" this series has been:

 * In
   https://lore.kernel.org/git/220627.86mtdxhnwk.gmgdl@evledraar.gmail.com/
   noting (and I'm paraphrasing here) that I couldn't in good conscience
   give it something like my Reviewed-by due to the various behavior
   changes it introduces, *and* the fact that large parts of the bisect
   interface it touches are completely untested.
   Now, of course "untested" is an existing issue, but I think it's fair
   to point that out when a series proposes to refactor some code that
   it's doing so on an interface that's not well tested, to the point
   that you can remove at least one "bisect" sub-command entirely and
   have the test suite still pass.
 * Pointing out specific bugs etc, as above.
 * In these "js/bisect-in-c" threads noting the outstanding issues with
   it, particularly as I think your own summaries have been.
   I don't see how you your remark that you "did not see any feedback
   that focuses on the actual scope of the patch series" in [2] with
   e.g. claim above that this behavior was "broken _before_ it" as
   anything except contradictory.

If your own summaries were something to the effect that no major issues had been raised, that you didn't have time to re-roll it, and could it either be picked up as-is or could others propose fix-ups on top I really wouldn't mind, or see any reason to comment in these threads.

1. https://lore.kernel.org/git/220819.86a6817xyw.gmgdl@evledraar.gmail.com/
2. https://lore.kernel.org/git/p053rrpq-17q7-pnrs-3794-o04ro1445s5s@tzk.qr/
Victoria Dye· Aug 16, 2022, 16:00 UTC · re: Junio C Hamano · lore

sy/mv-out-of-cone (was Re: What's cooking in git.git (Aug 2022, #05; Mon, 15))

Junio C Hamano wrote:
Show 18 quoted lines
> * sy/mv-out-of-cone (2022-08-10) 9 commits
>  - mv: check overwrite for in-to-out move
>  - advice.h: add advise_on_moving_dirty_path()
>  - mv: cleanup empty WORKING_DIRECTORY
>  - mv: from in-cone to out-of-cone
>  - mv: remove BOTH from enum update_mode
>  - mv: check if <destination> is a SKIP_WORKTREE_DIR
>  - mv: free the with_slash in check_dir_in_index()
>  - mv: rename check_dir_in_index() to empty_dir_has_sparse_contents()
>  - t7002: add tests for moving from in-cone to out-of-cone
> 
>  "git mv A B" in a sparsely populated working tree can be asked to
>  move a path from a directory that is "in cone" to another directory
>  that is "out of cone".  Handling of such a case has been improved.
> 
>  Will merge to 'next'?
>  source: <20220809120910.2021413-1-shaoxuan.yuan02@gmail.com>
> 
After reviewing the latest version [1], I think this is ready for 'next'.
[1] https://lore.kernel.org/git/52b67242-5d91-5406-9c95-9d8ddc49c079@github.com/
Junio C Hamano· Aug 16, 2022, 16:16 UTC · re: Victoria Dye · lore

Re: sy/mv-out-of-cone (was Re: What's cooking in git.git (Aug 2022, #05; Mon, 15))

Victoria Dye <vdye@github.com> writes:
Show 22 quoted lines
> Junio C Hamano wrote:
>> * sy/mv-out-of-cone (2022-08-10) 9 commits
>>  - mv: check overwrite for in-to-out move
>>  - advice.h: add advise_on_moving_dirty_path()
>>  - mv: cleanup empty WORKING_DIRECTORY
>>  - mv: from in-cone to out-of-cone
>>  - mv: remove BOTH from enum update_mode
>>  - mv: check if <destination> is a SKIP_WORKTREE_DIR
>>  - mv: free the with_slash in check_dir_in_index()
>>  - mv: rename check_dir_in_index() to empty_dir_has_sparse_contents()
>>  - t7002: add tests for moving from in-cone to out-of-cone
>> 
>>  "git mv A B" in a sparsely populated working tree can be asked to
>>  move a path from a directory that is "in cone" to another directory
>>  that is "out of cone".  Handling of such a case has been improved.
>> 
>>  Will merge to 'next'?
>>  source: <20220809120910.2021413-1-shaoxuan.yuan02@gmail.com>
>
> After reviewing the latest version [1], I think this is ready for 'next'.
>
> [1] https://lore.kernel.org/git/52b67242-5d91-5406-9c95-9d8ddc49c079@github.com/
Thanks, both.
Shaoxuan Yuan· Aug 17, 2022, 02:03 UTC · re: Victoria Dye · lore

Re: sy/mv-out-of-cone (was Re: What's cooking in git.git (Aug 2022, #05; Mon, 15))

On 8/17/2022 12:00 AM, Victoria Dye wrote:
Show 22 quoted lines
> Junio C Hamano wrote:
>> * sy/mv-out-of-cone (2022-08-10) 9 commits
>>   - mv: check overwrite for in-to-out move
>>   - advice.h: add advise_on_moving_dirty_path()
>>   - mv: cleanup empty WORKING_DIRECTORY
>>   - mv: from in-cone to out-of-cone
>>   - mv: remove BOTH from enum update_mode
>>   - mv: check if <destination> is a SKIP_WORKTREE_DIR
>>   - mv: free the with_slash in check_dir_in_index()
>>   - mv: rename check_dir_in_index() to empty_dir_has_sparse_contents()
>>   - t7002: add tests for moving from in-cone to out-of-cone
>>
>>   "git mv A B" in a sparsely populated working tree can be asked to
>>   move a path from a directory that is "in cone" to another directory
>>   that is "out of cone".  Handling of such a case has been improved.
>>
>>   Will merge to 'next'?
>>   source: <20220809120910.2021413-1-shaoxuan.yuan02@gmail.com>
>>
> After reviewing the latest version [1], I think this is ready for 'next'.
>
> [1] https://lore.kernel.org/git/52b67242-5d91-5406-9c95-9d8ddc49c079@github.com/
Thanks!
Elijah Newren· Aug 17, 2022, 00:36 UTC · re: Junio C Hamano · lore

cw/submodule-merge-messages (Was: Re: What's cooking in git.git (Aug 2022, #05; Mon, 15))

On Mon, Aug 15, 2022 at 6:50 PM Junio C Hamano <gitster@pobox.com> wrote:
Show 10 quoted lines
>
> * cw/submodule-merge-messages (2022-08-04) 1 commit
>   (merged to 'next' on 2022-08-12 at ede0890319)
>  + submodule merge: update conflict error message
>
>  Update the message given when "git merge" sees conflicts at a path
>  with a submodule while merging a superproject.
>
>  Will merge to 'master'.
>  source: <20220804195105.1303455-1-calvinwan@google.com>
I apologize for being away and not reviewing again before this merged
to next (vacation followed by coming down with Covid).  I noticed a
few issues with v8, so I submitted a few patches meant to go on top:
   https://lore.kernel.org/git/pull.1325.git.1660696081.gitgitgadget@gmail.com/

← back to recent threads