What's cooking in git.git (Jul 2022, #03; Mon, 11)

What's cooking in git.git (Jul 2022, #03; Mon, 11)

[Junio C Hamano]

Here are the topics that have been cooking in my tree.  Commits
prefixed with '+' are in 'next' (being in 'next' is a sign that a
topic is stable enough to be used and are candidate to be in a
future release).  Commits prefixed with '-' are only in 'seen',
and aren't considered "accepted" at all.

Maintenance releases v2.37.1 and others have been tagged.  They are
to address CVE-2022-29187, a vulnerability related to CVE-2022-24765
that was fixed earlier.  Big thanks to Carlo Arenas and Johannes
Schindelin for fixing the issue and helping the releases out.

Copies of the source code to Git live in many repositories, and the
following is a list of the ones I push into or their mirrors.  Some
repositories have only a subset of branches.

With maint, master, next, seen, todo:

	git://git.kernel.org/pub/scm/git/git.git/
	git://repo.or.cz/alt-git.git/
	https://kernel.googlesource.com/pub/scm/git/git/
	https://github.com/git/git/
	https://gitlab.com/git-vcs/git/

With all the integration branches and topics broken out:

	https://github.com/gitster/git/

Even though the preformatted documentation in HTML and man format
are not sources, they are published in these repositories for
convenience (replace "htmldocs" with "manpages" for the manual
pages):

	git://git.kernel.org/pub/scm/git/git-htmldocs.git/
	https://github.com/gitster/git-htmldocs.git/

Release tarballs are available at:

	https://www.kernel.org/pub/software/scm/git/

--------------------------------------------------
[Graduated to 'master']

* ac/bitmap-format-doc (2022-06-16) 3 commits
  (merged to 'next' on 2022-06-16 at 5591d11601)
 + bitmap-format.txt: add information for trailing checksum
 + bitmap-format.txt: fix some formatting issues
 + bitmap-format.txt: feed the file to asciidoc to generate html

 Adjust technical/bitmap-format to be formatted by AsciiDoc, and
 add some missing information to the documentation.
 source: <pull.1246.v4.git.1655355834.gitgitgadget@gmail.com>


* cr/setup-bug-typo (2022-06-17) 1 commit
  (merged to 'next' on 2022-06-17 at 8834ffe0ab)
 + setup: fix function name in a BUG() message

 Typofix in a BUG() message.
 source: <pull.1255.git.1654782920256.gitgitgadget@gmail.com>


* ds/branch-checked-out (2022-06-21) 7 commits
  (merged to 'next' on 2022-06-21 at e42bc4566f)
 + branch: drop unused worktrees variable
 + fetch: stop passing around unused worktrees variable
  (merged to 'next' on 2022-06-17 at c881874257)
 + branch: fix branch_checked_out() leaks
 + branch: use branch_checked_out() when deleting refs
 + fetch: use new branch_checked_out() and add tests
 + branch: check for bisects and rebases
 + branch: add branch_checked_out() helper
 (this branch is used by ds/rebase-update-ref.)

 Introduce a helper to see if a branch is already being worked on
 (hence should not be newly checked out in a working tree), which
 performs much better than the existing find_shared_symref() to
 replace many uses of the latter.
 source: <pull.1254.v2.git.1655234853.gitgitgadget@gmail.com>


* ds/vscode-settings (2022-06-27) 1 commit
  (merged to 'next' on 2022-07-02 at fcbd2e7aca)
 + vscode: improve tab size and wrapping

 Will merge to 'master'.
 source: <pull.1271.git.1656354587496.gitgitgadget@gmail.com>


* jk/optim-promisor-object-enumeration (2022-06-16) 1 commit
  (merged to 'next' on 2022-06-16 at ce0712a74c)
 + is_promisor_object(): walk promisor packs in pack-order

 Collection of what is referenced by objects in promisor packs have
 been optimized to inspect these objects in the in-pack order.
 source: <YqrTsbXbEjx0Pabn@coredump.intra.peff.net>


* jk/revisions-doc-markup-fix (2022-06-22) 1 commit
  (merged to 'next' on 2022-07-02 at e25dbe8cfb)
 + revisions.txt: escape "..." to avoid asciidoc horizontal ellipsis

 Documentation mark-up fix.
 source: <YrOmsA04FZae89be@coredump.intra.peff.net>


* pb/diff-doc-raw-format (2022-06-13) 3 commits
  (merged to 'next' on 2022-07-02 at 198480cbc6)
 + diff-index.txt: update raw output format in examples
 + diff-format.txt: correct misleading wording
 + diff-format.txt: dst can be 0* SHA-1 when path is deleted, too

 Update "git diff/log --raw" format documentation.
 source: <pull.1259.git.1655123383.gitgitgadget@gmail.com>


* rs/archive-with-internal-gzip (2022-06-15) 6 commits
  (merged to 'next' on 2022-06-17 at ab5af6acd1)
 + archive-tar: use internal gzip by default
 + archive-tar: use OS_CODE 3 (Unix) for internal gzip
 + archive-tar: add internal gzip implementation
 + archive-tar: factor out write_block()
 + archive: rename archiver data field to filter_command
 + archive: update format documentation

 Teach "git archive" to (optionally and then by default) avoid
 spawning an external "gzip" process when creating ".tar.gz" (and
 ".tgz") archives.
 source: <9df761c3-355a-ede9-7971-b32687fe9abb@web.de>


* rs/combine-diff-with-incompatible-options (2022-06-21) 2 commits
  (merged to 'next' on 2022-07-02 at 0fe8b80a3e)
 + combine-diff: abort if --output is given
 + combine-diff: abort if --ignore-matching-lines is given

 Certain diff options are currently ignored when combined-diff is
 shown; mark them as incompatible with the feature.
 source: <220524.86v8tuvfl1.gmgdl@evledraar.gmail.com>

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

* po/doc-add-renormalize (2022-07-09) 1 commit
 - doc add: renormalize is not idempotent for CRCRLF

 Documentation for "git add --renormalize" has been improved.

 Will merge to 'next'?
 source: <d3b8ed97a105ea1d7e656c964b7eee378e11ede6.1657385781.git.gitgitgadget@gmail.com>


* po/glossary-around-traversal (2022-07-09) 3 commits
 - glossary: add reachability bitmap description
 - glossary: add commit graph description
 - glossary: add Object DataBase (ODB) abbreviation

 The glossary entries for "commit-graph file" and "reachability
 bitmap" have been added.

 Will merge to 'next'?
 source: <pull.1282.git.1657385781.gitgitgadget@gmail.com>


* rs/cocci-array-copy (2022-07-10) 1 commit
 - cocci: avoid normalization rules for memcpy

 A coccinelle rule (in contrib/) to encourage use of COPY_ARRAY
 macro has been improved.

 Will merge to 'next'.
 source: <ded153d4-4aea-d4da-11cb-ec66d181e4c9@web.de>


* sg/multi-pack-index-parse-options-fix (2022-07-10) 1 commit
  (merged to 'next' on 2022-07-11 at 1e14685680)
 + multi-pack-index: simplify handling of unknown --options

 The way "git multi-pack" uses parse-options API has been improved.

 Will merge to 'master'.
 source: <20220710151645.GA2038@szeder.dev>


* jk/ref-filter-discard-commit-buffer (2022-07-11) 1 commit
 - ref-filter: disable save_commit_buffer while traversing

 source: <Ysw4JtoHW1vWmqhz@coredump.intra.peff.net>

--------------------------------------------------
[Stalled]

* ll/curl-accept-language (2022-07-11) 1 commit
 - remote-curl: send Accept-Language header to server

 Earlier, HTTP transport clients learned to tell the server side
 what locale they are in by sending Accept-Language HTTP header, but
 this was done only for some requests but not others.

 Will merge to 'next'.
 source: <pull.1251.v4.git.1657519134336.gitgitgadget@gmail.com>


* bc/stash-export (2022-04-08) 4 commits
 - builtin/stash: provide a way to import stashes from a ref
 - builtin/stash: provide a way to export stashes to a ref
 - builtin/stash: factor out revision parsing into a function
 - object-name: make get_oid quietly return an error

 A mechanism to export and import stash entries to and from a normal
 commit to transfer it across repositories has been introduced.

 Expecting a reroll.
 cf. <YnL2d4Vr9Vr7W4Hj@camp.crustytoothpaste.net>
 source: <20220407215352.3491567-1-sandals@crustytoothpaste.net>


* cw/remote-object-info (2022-05-06) 11 commits
 - SQUASH??? coccicheck
 - SQUASH??? ensure that coccicheck is happy
 - SQUASH??? compilation fix
 - cat-file: add --batch-command remote-object-info command
 - cat-file: move parse_cmd and DEFAULT_FORMAT up
 - transport: add object-info fallback to fetch
 - transport: add client side capability to request object-info
 - object-info: send attribute packet regardless of object ids
 - object-store: add function to free object_info contents
 - fetch-pack: move fetch default settings
 - fetch-pack: refactor packet writing

 A client component to talk with the object-info endpoint.

 Expecting a reroll.
 source: <20220502170904.2770649-1-calvinwan@google.com>

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

* ab/cocci-unused (2022-07-06) 6 commits
  (merged to 'next' on 2022-07-11 at 7fa60d2a5b)
 + cocci: generalize "unused" rule to cover more than "strbuf"
 + cocci: add and apply a rule to find "unused" strbufs
 + cocci: have "coccicheck{,-pending}" depend on "coccicheck-test"
 + cocci: add a "coccicheck-test" target and test *.cocci rules
 + Makefile & .gitignore: ignore & clean "git.res", not "*.res"
 + Makefile: remove mandatory "spatch" arguments from SPATCH_FLAGS

 Add Coccinelle rules to detect the pattern of initializing and then
 finalizing a structure without using it in between at all, which
 happens after code restructuring and the compilers fail to
 recognize as an unused varilable.

 Will merge to 'master'.
 source: <cover-v4-0.6-00000000000-20220705T134033Z-avarab@gmail.com>


* jk/clone-unborn-confusion (2022-07-11) 4 commits
 - clone: move unborn head creation to update_head()
 - clone: use remote branch if it matches default HEAD
 - clone: propagate empty remote HEAD even with other branches
 - clone: drop extra newline from warning message

 "git clone" from a repository with some ref whose HEAD is unborn
 did not set the HEAD in the resulting repository correctly, which
 has been corrected.

 Will merge to 'next'.
 source: <YsdyLS4UFzj0j/wB@coredump.intra.peff.net>
 source: <YsvrsOH1jg559yVt@coredump.intra.peff.net>


* ac/bitmap-lookup-table (2022-07-06) 6 commits
 - p5310-pack-bitmaps.sh: remove pack.writeReverseIndex
 - bitmap-lookup-table: add performance tests for lookup table
 - pack-bitmap: prepare to read lookup table extension
 - pack-bitmap-write: learn pack.writeBitmapLookupTable and add tests
 - pack-bitmap-write.c: write lookup table extension
 - Documentation/technical: describe bitmap lookup table extension

 The pack bitmap file gained a bitmap-lookup table to speed up
 locating the necessary bitmap for a given commit.

 Will merge to 'next'?
 source: <pull.1266.v3.git.1656924376.gitgitgadget@gmail.com>


* bc/nettle-sha256 (2022-07-10) 1 commit
  (merged to 'next' on 2022-07-11 at cf9595d8ca)
 + sha256: add support for Nettle

 Support for libnettle as SHA256 implementation has been added.

 Will merge to 'master'.
 source: <20220710132907.1499365-1-sandals@crustytoothpaste.net>


* jc/builtin-mv-move-array (2022-07-09) 1 commit
  (merged to 'next' on 2022-07-09 at 0d3b3f62e5)
 + builtin/mv.c: use the MOVE_ARRAY() macro instead of memmove()

 Apply Coccinelle rule to turn raw memmove() into MOVE_ARRAY() cpp
 macro, which would improve maintainability and readability.

 Will merge to 'master'.
 source: <xmqq4jzpu4xp.fsf_-_@gitster.g>


* jd/gpg-interface-trust-level-string (2022-07-10) 1 commit
  (merged to 'next' on 2022-07-11 at 7b3cca73a8)
 + gpg-interface: add function for converting trust level to string

 The code to convert between GPG trust level strings and internal
 constants we use to represent them have been cleaned up.

 Will merge to 'master'.
 source: <pull.1281.v4.git.1657515650587.gitgitgadget@gmail.com>


* kk/p4-client-name-encoding-fix (2022-07-08) 1 commit
  (merged to 'next' on 2022-07-11 at 9c18616f76)
 + git-p4: fix bug with encoding of p4 client name

 "git p4" did not handle non-ASCII client name well, which has been
 corrected.

 Will merge to 'master'.
 source: <pull.1285.git.git.1657267260405.gitgitgadget@gmail.com>


* sa/cat-file-mailmap (2022-07-09) 4 commits
 - cat-file: add mailmap support
 - ident: rename commit_rewrite_person() to apply_mailmap_to_header()
 - ident: move commit_rewrite_person() to ident.c
 - revision: improve commit_rewrite_person()

 "git cat-file" learned an option to use the mailmap when showing
 commit and tag objects.
 source: <20220709154149.165524-1-siddharthasthana31@gmail.com>


* fr/vimdiff-layout-fix (2022-07-08) 1 commit
  (merged to 'next' on 2022-07-09 at d8461bd236)
 + vimdiff: make layout engine more robust against user vim settings

 Recent update to vimdiff layout code has been made more robust
 against different end-user vim settings.

 Will merge to 'master'.
 source: <20220708181024.45839-1-greenfoo@u92.eu>


* ds/git-rebase-doc-markup (2022-06-30) 1 commit
  (merged to 'next' on 2022-07-08 at 24a0b80b71)
 + git-rebase.txt: use back-ticks consistently

 References to commands-to-be-typed-literally in "git rebase"
 documentation mark-up have been corrected.

 Will merge to 'master'.
 source: <pull.1270.v3.git.1656508868146.gitgitgadget@gmail.com>


* ds/rebase-update-ref (2022-06-28) 8 commits
 - rebase: add rebase.updateRefs config option
 - rebase: update refs from 'update-ref' commands
 - rebase: add --update-refs option
 - sequencer: add update-ref command
 - sequencer: define array with enum values
 - rebase-interactive: update 'merge' description
 - branch: consider refs under 'update-refs'
 - t2407: test branches currently using apply backend

 "git rebase -i" learns to update branches whose tip appear in the
 rebased range.

 Expecting a reroll.
 cf. <15631ea2-6722-fd24-c8a6-0cee638b0602@github.com>
 source: <pull.1247.v3.git.1656422759.gitgitgadget@gmail.com>


* tb/pack-objects-remove-pahole-comment (2022-06-28) 1 commit
  (merged to 'next' on 2022-07-06 at d7494fbdef)
 + pack-objects.h: remove outdated pahole results

 Comment fix.

 Will merge to 'master'.
 source: <1379af2e9d271b501ef3942398e7f159a9c77973.1656440978.git.me@ttaylorr.com>


* ab/leakfix (2022-07-01) 11 commits
  (merged to 'next' on 2022-07-11 at 0b107fffcf)
 + pull: fix a "struct oid_array" memory leak
 + cat-file: fix a common "struct object_context" memory leak
 + gc: fix a memory leak
 + checkout: avoid "struct unpack_trees_options" leak
 + merge-file: fix memory leaks on error path
 + merge-file: refactor for subsequent memory leak fix
 + cat-file: fix a memory leak in --batch-command mode
 + revert: free "struct replay_opts" members
 + submodule.c: free() memory from xgetcwd()
 + clone: fix memory leak in wanted_peer_refs()
 + check-ref-format: fix trivial memory leak

 Plug various memory leaks.

 Will merge to 'master'.
 source: <cover-v2-00.11-00000000000-20220701T104017Z-avarab@gmail.com>


* ab/test-tool-leakfix (2022-07-01) 9 commits
  (merged to 'next' on 2022-07-11 at db7a724694)
 + test-tool delta: fix a memory leak
 + test-tool ref-store: fix a memory leak
 + test-tool bloom: fix memory leaks
 + test-tool json-writer: fix memory leaks
 + test-tool regex: call regfree(), fix memory leaks
 + test-tool urlmatch-normalization: fix a memory leak
 + test-tool {dump,scrap}-cache-tree: fix memory leaks
 + test-tool path-utils: fix a memory leak
 + test-tool test-hash: fix a memory leak

 Plug various memory leaks in test-tool commands.

 Will merge to 'master'.
 source: <cover-v2-0.9-00000000000-20220701T103503Z-avarab@gmail.com>


* en/t6429-test-must-be-empty-fix (2022-06-30) 1 commit
  (merged to 'next' on 2022-07-06 at 627c51773c)
 + t6429: fix use of non-existent function

 A test fix.

 Will merge to 'master'.
 source: <pull.1276.git.1656652799863.gitgitgadget@gmail.com>


* gc/submodule-use-super-prefix (2022-06-30) 8 commits
  (merged to 'next' on 2022-07-11 at 0d9cf172f9)
 + submodule--helper: remove display path helper
 + submodule--helper update: use --super-prefix
 + submodule--helper: remove unused SUPPORT_SUPER_PREFIX flags
 + submodule--helper: use correct display path helper
 + submodule--helper: don't recreate recursive prefix
 + submodule--helper update: use display path helper
 + submodule--helper tests: add missing "display path" coverage
 + Merge branch 'ab/submodule-cleanup' into gc/submodule-use-super-prefix
 (this branch uses ab/submodule-cleanup.)

 Another step to rewrite more parts of "git submodule" in C.

 Will merge to 'master'.
 source: <20220701021157.88858-1-chooglen@google.com>


* hx/lookup-commit-in-graph-fix (2022-06-30) 1 commit
  (merged to 'next' on 2022-07-08 at cef32db0b6)
 + commit-graph.c: no lazy fetch in lookup_commit_in_graph()

 A corner case bug where lazily fetching objects from a promisor
 remote resulted in infinite recursion has been corrected.

 Will merge to 'master'.
 source: <96d4bb71505d87ed501c058bbd89bfc13d08b24a.1656593279.git.hanxin.hx@bytedance.com>


* ll/ls-files-tests-update (2022-07-06) 1 commit
  (merged to 'next' on 2022-07-06 at 444d1eabd0)
 + ls-files: update test style

 Test update.

 Will merge to 'master'.
 source: <pull.1269.v6.git.1656863349926.gitgitgadget@gmail.com>


* pw/xdiff-alloc (2022-07-08) 4 commits
 - xdiff: introduce XDL_ALLOC_GROW()
 - xdiff: introduce XDL_CALLOC_ARRAY()
 - xdiff: introduce xdl_calloc
 - xdiff: introduce XDL_ALLOC_ARRAY()

 Add a level of redirection to array allocation API in xdiff part,
 to make it easier to share with the libgit2 project.

 Will merge to 'next'?
 source: <pull.1272.v2.git.1657297519.gitgitgadget@gmail.com>


* sy/mv-out-of-cone (2022-07-01) 8 commits
  (merged to 'next' on 2022-07-08 at 654970fdb7)
 + mv: add check_dir_in_index() and solve general dir check issue
 + mv: use flags mode for update_mode
 + mv: check if <destination> exists in index to handle overwriting
 + mv: check if out-of-cone file exists in index with SKIP_WORKTREE bit
 + mv: decouple if/else-if checks using goto
 + mv: update sparsity after moving from out-of-cone to in-cone
 + t1092: mv directory from out-of-cone to in-cone
 + t7002: add tests for moving out-of-cone file/directory

 "git mv A B" in a sparsely populated working tree can be asked to
 move a path between directories that are "in cone" (i.e. expected
 to be materialized in the working tree) and "out of cone"
 (i.e. expected to be hidden).  The handling of such cases has been
 improved.

 Will merge to 'master'.
 source: <20220630023737.473690-1-shaoxuan.yuan02@gmail.com>


* ab/squelch-empty-fsync-traces (2022-06-30) 1 commit
 . trace2: don't include "fsync" events in all trace2 logs

 Omit fsync-related trace2 entries when their values are all zero.

 Breaks tests in hx/unpack-streaming with an interesting interaction.
 source: <patch-v2-1.1-a1fc37de947-20220630T084607Z-avarab@gmail.com>


* cl/grep-max-count (2022-06-22) 1 commit
  (merged to 'next' on 2022-07-08 at 646199ab4c)
 + grep: add --max-count command line option

 "git grep -m<max-hits>" is a way to limit the hits shown per file.

 Will merge to 'master'.
 source: <pull.1278.v4.git.git.1655927252899.gitgitgadget@gmail.com>


* tk/rev-parse-doc-clarify-at-u (2022-06-23) 1 commit
  (merged to 'next' on 2022-07-08 at 1075452f32)
 + rev-parse: documentation adjustment - mention remote tracking with @{u}

 Doc update.

 Will merge to 'master'.
 source: <pull.1265.v2.git.1655960512385.gitgitgadget@gmail.com>


* en/merge-tree (2022-06-22) 17 commits
  (merged to 'next' on 2022-07-08 at a29b4896ab)
 + git-merge-tree.txt: add a section on potentional usage mistakes
 + merge-tree: add a --allow-unrelated-histories flag
 + merge-tree: allow `ls-files -u` style info to be NUL terminated
 + merge-ort: optionally produce machine-readable output
 + merge-ort: store more specific conflict information
 + merge-ort: make `path_messages` a strmap to a string_list
 + merge-ort: store messages in a list, not in a single strbuf
 + merge-tree: provide easy access to `ls-files -u` style info
 + merge-tree: provide a list of which files have conflicts
 + merge-ort: remove command-line-centric submodule message from merge-ort
 + merge-ort: provide a merge_get_conflicted_files() helper function
 + merge-tree: support including merge messages in output
 + merge-ort: split out a separate display_update_messages() function
 + merge-tree: implement real merges
 + merge-tree: add option parsing and initial shell for real merge function
 + merge-tree: move logic for existing merge into new function
 + merge-tree: rename merge_trees() to trivial_merge_trees()

 A new command is introduced that takes two commits and computes a
 tree that would be contained in the resulting merge commit, if the
 histories leading to these two commits were to be merged, and is
 added as a new mode of "git merge-tree" subcommand.

 Will merge to 'master'.
 source: <pull.1122.v7.git.1655511660.gitgitgadget@gmail.com>


* dr/i18n-die-warn-error-usage (2022-06-21) 1 commit
  (merged to 'next' on 2022-07-08 at 6f639750a1)
 + i18n: mark message helpers prefix for translation

 Give _() markings to fatal/warning/usage: labels that are shown in
 front of these messages.

 Will merge to 'master'.
 source: <pull.1279.v2.git.git.1655819877758.gitgitgadget@gmail.com>


* ds/t5510-brokequote (2022-06-21) 1 commit
  (merged to 'next' on 2022-07-06 at 2776bed385)
 + t5510: replace 'origin' with URL more carefully

 Test fix.

 Will merge to 'master'.
 source: <484a330e-0902-6e1b-8189-63c72dcea494@github.com>


* en/merge-restore-to-pristine (2022-06-21) 6 commits
 - merge: do not exit restore_state() prematurely
 - merge: ensure we can actually restore pre-merge state
 - merge: make restore_state() restore staged state too
 - merge: fix save_state() to work when there are racy-dirty files
 - merge: remove unused variable
 - t6424: make sure a failed merge preserves local changes

 When "git merge" finds that it cannot perform a merge, it should
 restore the working tree to the state before the command was
 initiated, but in some corner cases it didn't.

 Needs review.
 source: <pull.1231.v2.git.1655621424.gitgitgadget@gmail.com>


* tk/apply-case-insensitive (2022-06-21) 3 commits
 - apply: support case-only renames in case-insensitive filesystems
 - reset: new failing test for reset of case-insensitive duplicate in index
 - t4141: test "git apply" with core.ignorecase

 "git apply" barfed on a patch that makes a case-only rename on a
 case-insensitive filesystem.

 Needs review.
 source: <pull.1257.v2.git.1655655027.gitgitgadget@gmail.com>


* zh/ls-files-format (2022-07-11) 1 commit
 - ls-files: introduce "--format" option

 "git ls-files" learns the "--format" option to tweak its output.

 Getting closer to finish?
 cf. <xmqqleszl2p0.fsf@gitster.g>
 source: <pull.1262.v6.git.1657558435532.gitgitgadget@gmail.com>


* ab/test-quoting-fix (2022-06-30) 3 commits
  (merged to 'next' on 2022-07-06 at 0aa78fd9db)
 + config tests: fix harmless but broken "rm -r" cleanup
 + test-lib.sh: fix prepend_var() quoting issue
 + tests: add missing double quotes to included library paths

 Fixes for tests when the source directory has unusual characters in
 its path, e.g. whitespaces, double-quotes, etc.

 Will merge to 'master'.
 source: <cover-v2-0.3-00000000000-20220630T101646Z-avarab@gmail.com>


* en/merge-dual-dir-renames-fix (2022-07-06) 5 commits
  (merged to 'next' on 2022-07-11 at 5f8dadf87b)
 + merge-ort: fix issue with dual rename and add/add conflict
 + merge-ort: shuffle the computation and cleanup of potential collisions
 + merge-ort: make a separate function for freeing struct collisions
 + merge-ort: small cleanups of check_for_directory_rename
 + t6423: add tests of dual directory rename plus add/add conflict

 Fixes a long-standing corner case bug around directory renames in
 the merge-ort strategy.

 Will merge to 'master'.
 source: <pull.1268.v4.git.1656984823.gitgitgadget@gmail.com>


* zk/push-use-bitmaps (2022-06-17) 1 commit
  (merged to 'next' on 2022-07-08 at 8aa1f94fad)
 + send-pack.c: add config push.useBitmaps

 "git push" sometimes perform poorly when reachability bitmaps are
 used, even in a repository where other operations are helped by
 bitmaps.  The push.useBitmaps configuration variable is introduced
 to allow disabling use of reachability bitmaps only for "git push".

 Will merge to 'master'.
 source: <pull.1263.v4.git.1655492779228.gitgitgadget@gmail.com>


* jk/remote-show-with-negative-refspecs (2022-06-17) 1 commit
  (merged to 'next' on 2022-07-08 at d4e49ad22a)
 + remote: handle negative refspecs in git remote show
 (this branch is used by jk/t5505-restructure.)

 "git remote show [-n] frotz" now pays attention to negative
 pathspecs.

 Will merge to 'master'.
 source: <20220617002036.1577-2-jacob.keller@gmail.com>


* js/commit-graph-parsing-without-repo-settings (2022-06-15) 1 commit
 - commit-graph: refactor to avoid prepare_repo_settings

 Expecting a reroll.
 source: <9b56496b0809cc8a25af877ea97042e2cb7f2af6.1655246092.git.steadmon@google.com>


* ro/mktree-allow-missing-fix (2022-06-21) 1 commit
  (merged to 'next' on 2022-07-08 at 599ed6fb84)
 + mktree: do not check type of remote objects

 "git mktree --missing" lazily fetched objects that are missing from
 the local object store, which was totally unnecessary for the purpose
 of creating the tree object(s) from its input.

 Will merge to 'master'.
 source: <748f39a9-65aa-2110-cf92-7ddf81b5f507@roku.com>


* jt/connected-show-missing-from-which-side (2022-06-10) 1 commit
 - fetch,fetch-pack: clarify connectivity check error

 We may find an object missing after a "git fetch" stores the
 objects it obtained from the other side, but it is not necessarily
 because the remote failed to send necessary objects.  Reword the
 messages in an attempt to help users explore other possibilities
 when they hit this error.

 Expecting a reroll.
 source: <20220610195247.1177549-1-jonathantanmy@google.com>


* ab/submodule-cleanup (2022-06-28) 12 commits
  (merged to 'next' on 2022-07-08 at 6f3886aa03)
 + git-sh-setup.sh: remove "say" function, change last users
 + git-submodule.sh: use "$quiet", not "$GIT_QUIET"
 + submodule--helper: eliminate internal "--update" option
 + submodule--helper: understand --checkout, --merge and --rebase synonyms
 + submodule--helper: report "submodule" as our name in some "-h" output
 + submodule--helper: rename "absorb-git-dirs" to "absorbgitdirs"
 + submodule update: remove "-v" option
 + submodule--helper: have --require-init imply --init
 + git-submodule.sh: remove unused top-level "--branch" argument
 + git-submodule.sh: make the "$cached" variable a boolean
 + git-submodule.sh: remove unused $prefix variable
 + git-submodule.sh: remove unused sanitize_submodule_env()
 (this branch is used by gc/submodule-use-super-prefix.)

 Further preparation to turn git-submodule.sh into a builtin.

 Will merge to 'master'.
 source: <cover-v4-00.12-00000000000-20220628T095914Z-avarab@gmail.com>


* jc/resolve-undo (2022-07-11) 2 commits
 - fsck: do not dereference NULL while checking resolve-undo data
  (merged to 'next' on 2022-06-15 at c195e5a2d9)
 + revision: mark blobs needed for resolve-undo as reachable

 The resolve-undo information in the index was not protected against
 GC, which has been corrected.

 Will merge to 'next'.
 source: <xmqqfskdieqz.fsf@gitster.g>


* ab/build-gitweb (2022-06-28) 8 commits
  (merged to 'next' on 2022-07-11 at 731e354ff0)
 + gitweb/Makefile: add a "NO_GITWEB" parameter
 + Makefile: build 'gitweb' in the default target
 + gitweb/Makefile: include in top-level Makefile
 + gitweb: remove "test" and "test-installed" targets
 + gitweb/Makefile: prepare to merge into top-level Makefile
 + gitweb/Makefile: clear up and de-duplicate the gitweb.{css,js} vars
 + gitweb/Makefile: add a $(GITWEB_ALL) variable
 + gitweb/Makefile: define all .PHONY prerequisites inline

 Teach "make all" to build gitweb as well.

 Will merge to 'master'.
 source: <cover-v3-0.8-00000000000-20220628T100936Z-avarab@gmail.com>


* ab/test-without-templates (2022-06-06) 7 commits
  (merged to 'next' on 2022-07-11 at afab6c1918)
 + tests: don't assume a .git/info for .git/info/sparse-checkout
 + tests: don't assume a .git/info for .git/info/exclude
 + tests: don't assume a .git/info for .git/info/refs
 + tests: don't assume a .git/info for .git/info/attributes
 + tests: don't assume a .git/info for .git/info/grafts
 + tests: don't depend on template-created .git/branches
 + t0008: don't rely on default ".git/info/exclude"

 Tweak tests so that they still work when the "git init" template
 did not create .git/info directory.

 Will merge to 'master'.
 source: <cover-v2-0.7-00000000000-20220603T110506Z-avarab@gmail.com>


* hx/unpack-streaming (2022-06-13) 6 commits
  (merged to 'next' on 2022-07-08 at 4eb375ec2f)
 + unpack-objects: use stream_loose_object() to unpack large objects
 + core doc: modernize core.bigFileThreshold documentation
 + object-file.c: add "stream_loose_object()" to handle large object
 + object-file.c: factor out deflate part of write_loose_object()
 + object-file.c: refactor write_loose_object() to several steps
 + unpack-objects: low memory footprint for get_data() in dry_run mode

 Allow large objects read from a packstream to be streamed into a
 loose object file straight, without having to keep it in-core as a
 whole.

 Will merge to 'master'.
 source: <cover.1654914555.git.chiyutianyi@gmail.com>


* tb/show-ref-count (2022-06-06) 2 commits
 - builtin/show-ref.c: limit output with `--count`
 - builtin/show-ref.c: rename `found_match` to `matches_nr`

 "git show-ref" learned to stop after emitting N refs with the new
 "--count=N" option.

 Expecting a reroll.
 cf. <xmqqczfl4ce1.fsf@gitster.g>
 source: <cover.1654552560.git.me@ttaylorr.com>


* ds/bundle-uri-more (2022-06-06) 6 commits
 - fetch: add 'refs/bundle/' to log.excludeDecoration
 - bundle-uri: add support for http(s):// and file://
 - fetch: add --bundle-uri option
 - bundle-uri: create basic file-copy logic
 - remote-curl: add 'get' capability
 - docs: document bundle URI standard

 The "bundle URI" topic.

 Needs review.
 source: <pull.1248.git.1654545325.gitgitgadget@gmail.com>


* js/bisect-in-c (2022-06-27) 16 commits
 - bisect: no longer try to clean up left-over `.git/head-name` files
 - bisect: remove Cogito-related code
 - Turn `git bisect` into a full built-in
 - bisect: move even the command-line parsing to `bisect--helper`
 - bisect: teach the `bisect--helper` command to show the correct usage strings
 - bisect--helper: return only correct exit codes in `cmd_*()`
 - bisect--helper: move the `BISECT_STATE` case to the end
 - bisect--helper: make `--bisect-state` optional
 - bisect--helper: align the sub-command order with git-bisect.sh
 - bisect--helper: using `--bisect-state` without an argument is a bug
 - bisect--helper: really retire `--bisect-autostart`
 - bisect--helper: really retire --bisect-next-check
 - bisect--helper: retire the --no-log option
 - bisect: avoid double-quoting when printing the failed command
 - bisect run: fix the error message
 - bisect: verify that a bogus option won't try to start a bisection

 Final bits of "git bisect.sh" have been rewritten in C.

 Expecting a (hopefully final) reroll.
 cf. <20627.86ilolhnnn.gmgdl@evledraar.gmail.com>
 source: <pull.1132.v4.git.1656354677.gitgitgadget@gmail.com>


* gc/bare-repo-discovery (2022-07-07) 5 commits
 - setup.c: create `discovery.bare`
 - safe.directory: use git_protected_config()
 - config: learn `git_protected_config()`
 - Documentation: define protected configuration
 - Documentation/git-config.txt: add SCOPES section

 Introduce a discovery.barerepository configuration variable that
 allows users to forbid discovery of bare repositories.

 Will merge to 'next'?
 source: <pull.1261.v7.git.git.1657234914.gitgitgadget@gmail.com>


* gg/worktree-from-the-above (2022-06-21) 2 commits
  (merged to 'next' on 2022-07-08 at fa0e71ba39)
 + dir: minor refactoring / clean-up
 + dir: traverse into repository

 In a non-bare repository, the behavior of Git when the
 core.worktree configuration variable points at a directory that has
 a repository as its subdirectory, regressed in Git 2.27 days.

 Will merge to 'master'.
 source: <20220616234433.225-1-gg.oss@outlook.com>
 source: <20220616231956.154-1-gg.oss@outlook.com>

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

* ar/send-email-confirm-by-default (2022-04-22) 1 commit
 . send-email: always confirm by default

 "git send-email" is changed so that by default it asks for
 confirmation before sending each message out.

 Discarded.
 I wanted to like this, and had it in the version of Git I use
 myself for daily work, but the prompting turned out to be somewhat
 distracting.
 source: <20220422083629.1404989-1-hi@alyssa.is>

gc/bare-repo-discovery (was Re: What's cooking in git.git (Jul 2022, #03; Mon, 11))

[Glen Choo]

Junio C Hamano <gitster@pobox.com> writes:

> Maintenance releases v2.37.1 and others have been tagged.  They are
> to address CVE-2022-29187, a vulnerability related to CVE-2022-24765
> that was fixed earlier.  Big thanks to Carlo Arenas and Johannes
> Schindelin for fixing the issue and helping the releases out.

\o/ thanks everyone!

> * gc/bare-repo-discovery (2022-07-07) 5 commits
>  - setup.c: create `discovery.bare`
>  - safe.directory: use git_protected_config()
>  - config: learn `git_protected_config()`
>  - Documentation: define protected configuration
>  - Documentation/git-config.txt: add SCOPES section
>
>  Introduce a discovery.barerepository configuration variable that
>  allows users to forbid discovery of bare repositories.
>
>  Will merge to 'next'?
>  source: <pull.1261.v7.git.git.1657234914.gitgitgadget@gmail.com>

I have a (hopefully final) reroll planned that takes your
documentation suggestions. I think it reads a lot better with those, so
thanks!

I also noted your distaste for the `discovery.*` namespace (fair
enough). To avoid a reroll-of-the-reroll, I was hoping that we could
agree on something on-list (thread here [1]) before I send out the next
version.

[1] https://lore.kernel.org/git/kl6lsfn656cw.fsf@chooglen-macbookpro.roam.corp.google.com

Re: What's cooking in git.git (Jul 2022, #03; Mon, 11)

[Philip Oakley]

On 12/07/2022 18:07, Junio C Hamano wrote:
> [New Topics]
>
> * po/doc-add-renormalize (2022-07-09) 1 commit
>  - doc add: renormalize is not idempotent for CRCRLF
>
>  Documentation for "git add --renormalize" has been improved.
>
>  Will merge to 'next'?
>  source: <d3b8ed97a105ea1d7e656c964b7eee378e11ede6.1657385781.git.gitgitgadget@gmail.com>
>
>
> * po/glossary-around-traversal (2022-07-09) 3 commits
>  - glossary: add reachability bitmap description
>  - glossary: add commit graph description
>  - glossary: add Object DataBase (ODB) abbreviation
>
>  The glossary entries for "commit-graph file" and "reachability
>  bitmap" have been added.
>
>  Will merge to 'next'?
>  source: <pull.1282.git.1657385781.gitgitgadget@gmail.com>
I'm expecting to do a re-roll for both these, though I'm just recovering
from an infection.
If you could hold off for a few days that would be great.
--
Philip

ac/bitmap-lookup-table (was: Re: What's cooking in git.git (Jul 2022, #03; Mon, 11))

[Taylor Blau]

Hi Junio,

On Tue, Jul 12, 2022 at 10:07:44AM -0700, Junio C Hamano wrote:
> * ac/bitmap-lookup-table (2022-07-06) 6 commits
>  - p5310-pack-bitmaps.sh: remove pack.writeReverseIndex
>  - bitmap-lookup-table: add performance tests for lookup table
>  - pack-bitmap: prepare to read lookup table extension
>  - pack-bitmap-write: learn pack.writeBitmapLookupTable and add tests
>  - pack-bitmap-write.c: write lookup table extension
>  - Documentation/technical: describe bitmap lookup table extension
>
>  The pack bitmap file gained a bitmap-lookup table to speed up
>  locating the necessary bitmap for a given commit.
>
>  Will merge to 'next'?
>  source: <pull.1266.v3.git.1656924376.gitgitgadget@gmail.com>

I think that this version is pretty close to being ready, but I haven't
had a chance to look it over carefully yet since getting back from my
time off last week.

I should have time to review this in the next day or two, if neither of
you mind waiting.

Thanks,
Taylor

js/bisect-in-c, was Re: What's cooking in git.git (Jul 2022, #03; Mon, 11)

[Johannes Schindelin]

Hi Junio,

On Tue, 12 Jul 2022, Junio C Hamano wrote:

> * js/bisect-in-c (2022-06-27) 16 commits
>  - bisect: no longer try to clean up left-over `.git/head-name` files
>  - bisect: remove Cogito-related code
>  - Turn `git bisect` into a full built-in
>  - bisect: move even the command-line parsing to `bisect--helper`
>  - bisect: teach the `bisect--helper` command to show the correct usage strings
>  - bisect--helper: return only correct exit codes in `cmd_*()`
>  - bisect--helper: move the `BISECT_STATE` case to the end
>  - bisect--helper: make `--bisect-state` optional
>  - bisect--helper: align the sub-command order with git-bisect.sh
>  - bisect--helper: using `--bisect-state` without an argument is a bug
>  - bisect--helper: really retire `--bisect-autostart`
>  - bisect--helper: really retire --bisect-next-check
>  - bisect--helper: retire the --no-log option
>  - bisect: avoid double-quoting when printing the failed command
>  - bisect run: fix the error message
>  - bisect: verify that a bogus option won't try to start a bisection
>
>  Final bits of "git bisect.sh" have been rewritten in C.
>
>  Expecting a (hopefully final) reroll.
>  cf. <20627.86ilolhnnn.gmgdl@evledraar.gmail.com>

I did not find that one, but I found
https://lore.kernel.org/git/220627.86ilolhnnn.gmgdl@evledraar.gmail.com/

And that claims that Git has a convention to universally exit with code
129 when options are passed with incorrect values.

That claim does not survive even minimal contact with Git's source
code, though.

If I find some time, I will respond to that mail, but a reroll is actually
unnecessary.

>  source: <pull.1132.v4.git.1656354677.gitgitgadget@gmail.com>

Thanks,
Dscho

Re: js/bisect-in-c, was Re: What's cooking in git.git (Jul 2022, #03; Mon, 11)

[Ævar Arnfjörð Bjarmason]

On Wed, Jul 13 2022, Johannes Schindelin wrote:

> Hi Junio,
>
> On Tue, 12 Jul 2022, Junio C Hamano wrote:
>
>> * js/bisect-in-c (2022-06-27) 16 commits
>>  - bisect: no longer try to clean up left-over `.git/head-name` files
>>  - bisect: remove Cogito-related code
>>  - Turn `git bisect` into a full built-in
>>  - bisect: move even the command-line parsing to `bisect--helper`
>>  - bisect: teach the `bisect--helper` command to show the correct usage strings
>>  - bisect--helper: return only correct exit codes in `cmd_*()`
>>  - bisect--helper: move the `BISECT_STATE` case to the end
>>  - bisect--helper: make `--bisect-state` optional
>>  - bisect--helper: align the sub-command order with git-bisect.sh
>>  - bisect--helper: using `--bisect-state` without an argument is a bug
>>  - bisect--helper: really retire `--bisect-autostart`
>>  - bisect--helper: really retire --bisect-next-check
>>  - bisect--helper: retire the --no-log option
>>  - bisect: avoid double-quoting when printing the failed command
>>  - bisect run: fix the error message
>>  - bisect: verify that a bogus option won't try to start a bisection
>>
>>  Final bits of "git bisect.sh" have been rewritten in C.
>>
>>  Expecting a (hopefully final) reroll.
>>  cf. <20627.86ilolhnnn.gmgdl@evledraar.gmail.com>
>
> I did not find that one, but I found
> https://lore.kernel.org/git/220627.86ilolhnnn.gmgdl@evledraar.gmail.com/
>
> And that claims that Git has a convention to universally exit with code
> 129 when options are passed with incorrect values.
>
> That claim does not survive even minimal contact with Git's source
> code, though.

I'm not claiming that we always use 129 when we're fed bad options etc.,
but rather that that's what parse_options() does, so at this point most
commands do that consistently.
	
	./git --blah >/dev/null 2>&1; echo $?
	129
	./git status --blah >/dev/null 2>&1; echo $?
	129

But yes, you can find exceptions still, e.g. try that with "git log" and
it'll return 128.

Your series migrates the bisect--helper.c away from parse_options() in a
a way that I don't think is necessary, but leaving that aside mimicking
the exit codes we'd get from parse_options() for those cases you're
handling in your custom parsing seems like a good thing.

> If I find some time, I will respond to that mail, but a reroll is actually
> unnecessary.

There's some more in [1], but there's at least one outstanding bug in
this series, i.e. that you're moving away from parse_options(), but
forgot to change the corresponding flag in git.c for the
built-in. That's then used by the completion mechanism.

But as noted in [2] and more recently in [1] I'm most concerned about us
having outstanding bugs due to past iterations of this having played
whack-a-mole in fixing specific edge cases I found, but not gone back
and added missing test coverage for the series beforehand.

Which, I'm not saying should hold this series up, but just that having
reviewed it for a few iterations I'm not comfortable saying we haven't
missed something else, and given the nature of the past whack-a-mole
fixes it looks like you haven't really looked it either.

I'm referring to e.g. the thread ending at [3], where I pointed out that
"git <subcommand> -h" was broken, you apparently tested one of the
subcommands and concluded it wasn't broken, but clearly not all of them.

Which, I'd be less concerned about if as pointed out in [1] we don't
have entirte bisect sub-commands that don't have any test coverage at
all, so whatever coverage we have probably has major gaps.

1. https://lore.kernel.org/git/220627.86mtdxhnwk.gmgdl@evledraar.gmail.com/
2. https://lore.kernel.org/git/220523.865ylwzgji.gmgdl@evledraar.gmail.com/
3. https://lore.kernel.org/git/220225.86ilt27uln.gmgdl@evledraar.gmail.com/

Re: js/bisect-in-c, was Re: What's cooking in git.git (Jul 2022, #03; Mon, 11)

[Junio C Hamano]

Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:

> I'm not claiming that we always use 129 when we're fed bad options etc.,
> but rather that that's what parse_options() does, so at this point most
> commands do that consistently.
> 	
> 	./git --blah >/dev/null 2>&1; echo $?
> 	129
> 	./git status --blah >/dev/null 2>&1; echo $?
> 	129
>
> But yes, you can find exceptions still, e.g. try that with "git log" and
> it'll return 128.

Yup, that was my understanding as well.  We may have existing
breakage that we shouldn't be actively imitating when we do not have
to.

> Which, I'm not saying should hold this series up, but just that having
> reviewed it for a few iterations I'm not comfortable saying we haven't
> missed something else, and given the nature of the past whack-a-mole
> fixes it looks like you haven't really looked it either.

"We haven't missed" is not something we can comfortably say, ever,
aobut a series with any meaningful size.  I am not so worried about
it, if it is your only worries.  Would it make it less likely to
have introduced unintended bugs if we find a way to keep using
parse-options?

> I'm referring to e.g. the thread ending at [3], where I pointed out that
> "git <subcommand> -h" was broken, you apparently tested one of the
> subcommands and concluded it wasn't broken, but clearly not all of them.
>
> Which, I'd be less concerned about if as pointed out in [1] we don't
> have entirte bisect sub-commands that don't have any test coverage at
> all, so whatever coverage we have probably has major gaps.
>
> 1. https://lore.kernel.org/git/220627.86mtdxhnwk.gmgdl@evledraar.gmail.com/
> 2. https://lore.kernel.org/git/220523.865ylwzgji.gmgdl@evledraar.gmail.com/
> 3. https://lore.kernel.org/git/220225.86ilt27uln.gmgdl@evledraar.gmail.com/

Re: gc/bare-repo-discovery (was Re: What's cooking in git.git (Jul 2022, #03; Mon, 11))

[Junio C Hamano]

Glen Choo <chooglen@google.com> writes:

> I also noted your distaste for the `discovery.*` namespace (fair
> enough). To avoid a reroll-of-the-reroll, I was hoping that we could
> agree on something on-list (thread here [1]) before I send out the next
> version.

I found your idea of adding this new one in the safe.* hierarchy
quite reasonable.  "safe.discoveredBareRepository = yes / no" may be
quote a mouthful, but I do not think I can think of anything better.

Re: What's cooking in git.git (Jul 2022, #03; Mon, 11)

[Junio C Hamano]

Philip Oakley <philipoakley@iee.email> writes:

> I'm expecting to do a re-roll for both these, though I'm just recovering
> from an infection.
> If you could hold off for a few days that would be great.

Be well soon and take care of yourself.

Thanks, will relabel them to "Expecting a reroll".

Re: ac/bitmap-lookup-table

[Junio C Hamano]

Taylor Blau <me@ttaylorr.com> writes:

> Hi Junio,
>
> On Tue, Jul 12, 2022 at 10:07:44AM -0700, Junio C Hamano wrote:
>> * ac/bitmap-lookup-table (2022-07-06) 6 commits
>>  - p5310-pack-bitmaps.sh: remove pack.writeReverseIndex
>>  - bitmap-lookup-table: add performance tests for lookup table
>>  - pack-bitmap: prepare to read lookup table extension
>>  - pack-bitmap-write: learn pack.writeBitmapLookupTable and add tests
>>  - pack-bitmap-write.c: write lookup table extension
>>  - Documentation/technical: describe bitmap lookup table extension
>>
>>  The pack bitmap file gained a bitmap-lookup table to speed up
>>  locating the necessary bitmap for a given commit.
>>
>>  Will merge to 'next'?
>>  source: <pull.1266.v3.git.1656924376.gitgitgadget@gmail.com>
>
> I think that this version is pretty close to being ready, but I haven't
> had a chance to look it over carefully yet since getting back from my
> time off last week.
>
> I should have time to review this in the next day or two, if neither of
> you mind waiting.

Thanks!

Re: js/bisect-in-c, was Re: What's cooking in git.git (Jul 2022, #03; Mon, 11)

[Ævar Arnfjörð Bjarmason]

On Wed, Jul 13 2022, Junio C Hamano wrote:

> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
>
>> I'm not claiming that we always use 129 when we're fed bad options etc.,
>> but rather that that's what parse_options() does, so at this point most
>> commands do that consistently.
>> 	
>> 	./git --blah >/dev/null 2>&1; echo $?
>> 	129
>> 	./git status --blah >/dev/null 2>&1; echo $?
>> 	129
>>
>> But yes, you can find exceptions still, e.g. try that with "git log" and
>> it'll return 128.
>
> Yup, that was my understanding as well.  We may have existing
> breakage that we shouldn't be actively imitating when we do not have
> to.
>
>> Which, I'm not saying should hold this series up, but just that having
>> reviewed it for a few iterations I'm not comfortable saying we haven't
>> missed something else, and given the nature of the past whack-a-mole
>> fixes it looks like you haven't really looked it either.
>
> "We haven't missed" is not something we can comfortably say, ever,
> aobut a series with any meaningful size.  I am not so worried about
> it, if it is your only worries.  Would it make it less likely to
> have introduced unintended bugs if we find a way to keep using
> parse-options?

I started writing something here, but found myself rewriting the last 3
paragraphs of [1] seen in the context below, so I'll just refer to that.

FWIW ejecting 11-14/16, i.e. these patches:

	- Turn `git bisect` into a full built-in
	- bisect: move even the command-line parsing to `bisect--helper`
	- bisect: teach the `bisect--helper` command to show the correct usage strings
	- bisect--helper: return only correct exit codes in `cmd_*()`

Yields a result that I've got no concerns about whatsoever, and reduces
the diffstat from:

    7 files changed, 110 insertions(+), 207 deletions(-)

To just:

    4 files changed, 71 insertions(+), 67 deletions(-)

Which I think might be worth considering, similar to how the submodule
migration is happening in multi-step fashion. I.e. advancing the parts
that don't migrate it away from parse_options(), since I showed a way to
keep using it in [1] (while changing less code).

Or just merge it down, up to you :)

>> I'm referring to e.g. the thread ending at [3], where I pointed out that
>> "git <subcommand> -h" was broken, you apparently tested one of the
>> subcommands and concluded it wasn't broken, but clearly not all of them.
>>
>> Which, I'd be less concerned about if as pointed out in [1] we don't
>> have entirte bisect sub-commands that don't have any test coverage at
>> all, so whatever coverage we have probably has major gaps.
>>
>> 1. https://lore.kernel.org/git/220627.86mtdxhnwk.gmgdl@evledraar.gmail.com/
>> 2. https://lore.kernel.org/git/220523.865ylwzgji.gmgdl@evledraar.gmail.com/
>> 3. https://lore.kernel.org/git/220225.86ilt27uln.gmgdl@evledraar.gmail.com/

Re: gc/bare-repo-discovery (was Re: What's cooking in git.git (Jul 2022, #03; Mon, 11))

[Johannes Schindelin]

Hi,

On Wed, 13 Jul 2022, Junio C Hamano wrote:

> Glen Choo <chooglen@google.com> writes:
>
> > I also noted your distaste for the `discovery.*` namespace (fair
> > enough). To avoid a reroll-of-the-reroll, I was hoping that we could
> > agree on something on-list (thread here [1]) before I send out the next
> > version.
>
> I found your idea of adding this new one in the safe.* hierarchy
> quite reasonable.  "safe.discoveredBareRepository = yes / no" may be
> quote a mouthful, but I do not think I can think of anything better.

I would find `safe.bareRepository = true` or `false` more intuitive, and
more concise.

And if there should be an option to ignore bare repositories when
discovering a Git repository, it could be a tristate, with `ignore` being
the value to trigger that mode.

Thanks,
Dscho

Re: gc/bare-repo-discovery (was Re: What's cooking in git.git (Jul 2022, #03; Mon, 11))

[Junio C Hamano]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> I would find `safe.bareRepository = true` or `false` more intuitive, and
> more concise.

Yup, that is fine by me.

> And if there should be an option to ignore bare repositories when
> discovering a Git repository, it could be a tristate, with `ignore` being
> the value to trigger that mode.

Sounds good.

Re: js/bisect-in-c, was Re: What's cooking in git.git (Jul 2022, #03; Mon, 11)

[Johannes Schindelin]

[-- Attachment #1: Type: text/plain, Size: 921 bytes --]

Hi Junio,

On Wed, 13 Jul 2022, Junio C Hamano wrote:

> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
>
> > I'm not claiming that we always use 129 when we're fed bad options etc.,
> > but rather that that's what parse_options() does, so at this point most
> > commands do that consistently.
> >
> > 	./git --blah >/dev/null 2>&1; echo $?
> > 	129
> > 	./git status --blah >/dev/null 2>&1; echo $?
> > 	129
> >
> > But yes, you can find exceptions still, e.g. try that with "git log" and
> > it'll return 128.
>
> Yup, that was my understanding as well.  We may have existing
> breakage that we shouldn't be actively imitating when we do not have
> to.

This patch series already implements `git bisect` in the desired way:

	$ ./git bisect --invalid; echo $?
	usage: git bisect [help|start|bad|good|new|old|terms|skip|next|reset|visualize|view|replay|log|run]
	129

Ciao,
Johannes

Re: js/bisect-in-c, was Re: What's cooking in git.git (Jul 2022, #03; Mon, 11)

[Ævar Arnfjörð Bjarmason]

On Thu, Jul 14 2022, Johannes Schindelin wrote:

> Hi Junio,
>
> On Wed, 13 Jul 2022, Junio C Hamano wrote:
>
>> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
>>
>> > I'm not claiming that we always use 129 when we're fed bad options etc.,
>> > but rather that that's what parse_options() does, so at this point most
>> > commands do that consistently.
>> >
>> > 	./git --blah >/dev/null 2>&1; echo $?
>> > 	129
>> > 	./git status --blah >/dev/null 2>&1; echo $?
>> > 	129
>> >
>> > But yes, you can find exceptions still, e.g. try that with "git log" and
>> > it'll return 128.
>>
>> Yup, that was my understanding as well.  We may have existing
>> breakage that we shouldn't be actively imitating when we do not have
>> to.
>
> This patch series already implements `git bisect` in the desired way:
>
> 	$ ./git bisect --invalid; echo $?
> 	usage: git bisect [help|start|bad|good|new|old|terms|skip|next|reset|visualize|view|replay|log|run]
> 	129

It doesn't, the claim isn't that there's no way to have it return exit
code 129 on *some* invalid usage. In this case we do the "right" thing.

Rather that as noted in [1] there's other cases where we call die() and
should call usage_msg_opt().

Of course both of those would be more useful if the new built-in still
had the parse_options() usage info we could display. I.e. in this case
the conversion to a built-in leaves on the table nice benefits we'd get
for free.

Compare that with e.g. how "git bundle" handles it, note how we get not
only "don't do that", but also how valid usage would look like:
	
	$ git bundle -h
	usage: git bundle create [-q | --quiet | --progress | --all-progress] [--all-progress-implied]
	                         [--version=<version>] <file> <git-rev-list-args>
	   or: git bundle verify [-q | --quiet] <file>
	   or: git bundle fetch [--filter=<spec>] <uri>
	   or: git bundle list-heads <file> [<refname>...]
	   or: git bundle unbundle [--progress] <file> [<refname>...]
	$ git bundle create -h
	usage: git bundle create [-q | --quiet | --progress | --all-progress] [--all-progress-implied]
	                         [--version=<version>] <file> <git-rev-list-args>
	
	    -q, --quiet           do not show progress meter
	    --progress            show progress meter
	    --all-progress        show progress meter during object writing phase
	    --all-progress-implied
	                          similar to --all-progress when progress meter is shown
	    --version <n>         specify bundle format version

1. https://lore.kernel.org/git/220627.86ilolhnnn.gmgdl@evledraar.gmail.com/

Re: js/bisect-in-c, was Re: What's cooking in git.git (Jul 2022, #03; Mon, 11)

[Johannes Schindelin]

[-- Attachment #1: Type: text/plain, Size: 5349 bytes --]

Hi Ævar,

On Thu, 14 Jul 2022, Ævar Arnfjörð Bjarmason wrote:

> On Thu, Jul 14 2022, Johannes Schindelin wrote:
>
> > On Wed, 13 Jul 2022, Junio C Hamano wrote:
> >
> >> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
> >>
> >> > I'm not claiming that we always use 129 when we're fed bad options etc.,
> >> > but rather that that's what parse_options() does, so at this point most
> >> > commands do that consistently.
> >> >
> >> > 	./git --blah >/dev/null 2>&1; echo $?
> >> > 	129
> >> > 	./git status --blah >/dev/null 2>&1; echo $?
> >> > 	129
> >> >
> >> > But yes, you can find exceptions still, e.g. try that with "git log" and
> >> > it'll return 128.
> >>
> >> Yup, that was my understanding as well.  We may have existing
> >> breakage that we shouldn't be actively imitating when we do not have
> >> to.
> >
> > This patch series already implements `git bisect` in the desired way:
> >
> > 	$ ./git bisect --invalid; echo $?
> > 	usage: git bisect [help|start|bad|good|new|old|terms|skip|next|reset|visualize|view|replay|log|run]
> > 	129
>
> It doesn't, the claim isn't that there's no way to have it return exit
> code 129 on *some* invalid usage. In this case we do the "right" thing.
>
> Rather that as noted in [1] there's other cases where we call die() and
> should call usage_msg_opt().

It would have been better to take the time to spell out clearly that you
are taking offense in `git bisect start -h` not behaving in the way you
think is the rule in Git: to print a _subcommand_ usage and exit with code
129.

However, this feedback fails to recognize the scope of this patch series.

The patch series' intention is not to fix anything that is currently
broken. And it is already broken, my patch series does not introduce that
breakage (and it would make more sense to address this breakage _after_
the conversion, to avoid doubling the effort): The current output of `git
bisect start -h` shows the usage of `bisect--helper`!

Instead, the scope of the patch series is to finalize converting the
`bisect` command to a full built-in, implemented in C, and avoiding the
portability cost of running a POSIX shell script.

Note: I agree with you that it would be nice for `git bisect start -h` to
output a proper usage. There will be a time to discuss that, that time is
just simply not right now.

Since the scope is so different from what your feedback suggests, I have
to admit that it taxes my patience to see that laser focus on aspects that
are almost irrelevant compared to the aspects that should concern any
good review of this series: the correctness of the conversion, with a
heavy focus on the non-failure modes.

No user would care about the exit code of a failure mode (as long as it is
non-zero), if there are regressions e.g. in how `git bisect start
--good=Ævar --bad=Dscho` behaves.

So this hyper focus on what look like less relevant aspects is not only
irritating, it actively distracts me, others and even yourself from the
thorough review I would like to get: There have not been any thorough
reviews of this patch series so far, and I think it is because of this
here distraction.

The cost of this distraction is quite real: not only is there a
performance penalty of running POSIX shell scripts on Windows, there are
also problems with anti-malware disliking the way the POSIX emulation
layer works that we currently have to use on Windows to run `git bisect`,
which would be fixed by `bisect` being a full built-in. This distracting
feedback that prevents a thorough code review delays that fix for those
users.

To understand what I am aiming for, look at the deep analysis of the
rot13 filter conversion from Perl to C in
https://lore.kernel.org/git/4n20476q-6ssr-osp8-q5o3-p8ns726q4pn3@tzk.qr/,
where I carefully compared the behavior of the scripted code with the C
code that was designed to replace it.

At this point, it is good to recall Parkinson's law of triviality:

	Parkinson observed and illustrated that a committee whose job was
	to approve plans for a nuclear power plant spent the majority of
	its time with pointless discussions on relatively trivial and
	unimportant but easy-to-grasp issues, such as what materials to
	use for the staff bike-shed, while neglecting the less-trivial
	proposed design of the nuclear power plant itself, which is far
	more important but also a far more difficult and complex task to
	criticise constructively.

We've seen quite a few regressions as of recent that would have likely
been prevented by thorough reviews that do not distract themselves with
tangents, pet peeves and personal taste.

It would do good if we the reviewers on the Git mailing list took to heart
that Git is a software that millions of users depend on, not just our toy
to play with, and therefore the purpose of our reviews should aim to keep
Git working and safe. We will achieve that only if we avoid what Parkinson
called pointless discussions and instead put in the effort to provide
high-quality feedback that helps improve the design and the correctness of
the code.

In this instance, the discussion about exit codes and usage messages
should be postponed, in favor of focusing on the actual scope of this
patch series.

Ciao,
Johannes

Re: js/bisect-in-c, was Re: What's cooking in git.git (Jul 2022, #03; Mon, 11)

[Ævar Arnfjörð Bjarmason]

On Tue, Aug 16 2022, Johannes Schindelin wrote:

> Hi Ævar,
>
> On Thu, 14 Jul 2022, Ævar Arnfjörð Bjarmason wrote:
>
>> On Thu, Jul 14 2022, Johannes Schindelin wrote:
>>
>> > On Wed, 13 Jul 2022, Junio C Hamano wrote:
>> >
>> >> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
>> >>
>> >> > I'm not claiming that we always use 129 when we're fed bad options etc.,
>> >> > but rather that that's what parse_options() does, so at this point most
>> >> > commands do that consistently.
>> >> >
>> >> > 	./git --blah >/dev/null 2>&1; echo $?
>> >> > 	129
>> >> > 	./git status --blah >/dev/null 2>&1; echo $?
>> >> > 	129
>> >> >
>> >> > But yes, you can find exceptions still, e.g. try that with "git log" and
>> >> > it'll return 128.
>> >>
>> >> Yup, that was my understanding as well.  We may have existing
>> >> breakage that we shouldn't be actively imitating when we do not have
>> >> to.
>> >
>> > This patch series already implements `git bisect` in the desired way:
>> >
>> > 	$ ./git bisect --invalid; echo $?
>> > 	usage: git bisect [help|start|bad|good|new|old|terms|skip|next|reset|visualize|view|replay|log|run]
>> > 	129
>>
>> It doesn't, the claim isn't that there's no way to have it return exit
>> code 129 on *some* invalid usage. In this case we do the "right" thing.
>>
>> Rather that as noted in [1] there's other cases where we call die() and
>> should call usage_msg_opt().
>
> It would have been better to take the time to spell out clearly that you
> are taking offense in `git bisect start -h` not behaving in the way you
> think is the rule in Git: to print a _subcommand_ usage and exit with code
> 129.
>
> However, this feedback fails to recognize the scope of this patch series.

No, I'm pointing out that you could *also* get more benefit from moving
more towards the way we do things with other sub-commands in
builtin/bisect.c.

But the core feedback was on your 11/16
(https://lore.kernel.org/git/ce508583e455a1dbb7620a238edb11dae195f00d.1656354677.git.gitgitgadget@gmail.com/)
changing ("correct[ing") the return code

If we're going out of our way to change the behavior of bisect
while-we're-at-it let's change it to the actually correct thing. I think
Junio concurred with that here:
https://lore.kernel.org/git/xmqqtu7ldmrz.fsf@gitster.g/

> The patch series' intention is not to fix anything that is currently
> broken. And it is already broken, my patch series does not introduce that
> breakage.

I think that would be completely fair if it aimed to bug-for-bug
re-implement the current git-bisect.sh behavior, without the unnecessary
while-we're-at-it changes.

> (and it would make more sense to address this breakage _after_
> the conversion, to avoid doubling the effort): The current output of `git
> bisect start -h` shows the usage of `bisect--helper`!
>
> Instead, the scope of the patch series is to finalize converting the
> `bisect` command to a full built-in, implemented in C, and avoiding the
> portability cost of running a POSIX shell script.
>
> Note: I agree with you that it would be nice for `git bisect start -h` to
> output a proper usage. There will be a time to discuss that, that time is
> just simply not right now.

I agree with all of that, but that's not what I've been pointing out to
you, except to note that your bisect.sh->C conversion is making some
subsequent follow-up work harder than it needs to be.

> Since the scope is so different from what your feedback suggests, I have
> to admit that it taxes my patience to see that laser focus on aspects that
> are almost irrelevant compared to the aspects that should concern any
> good review of this series: the correctness of the conversion, with a
> heavy focus on the non-failure modes.

...

> No user would care about the exit code of a failure mode (as long as it is
> non-zero), if there are regressions e.g. in how `git bisect start
> --good=Ævar --bad=Dscho` behaves.

If users don't care about the specific exit code of failure modes why is
your series (the 11/16 noted above) going out of its way to change those
exit codes?

> So this hyper focus on what look like less relevant aspects is not only
> irritating, it actively distracts me, others and even yourself from the
> thorough review I would like to get: There have not been any thorough
> reviews of this patch series so far, and I think it is because of this
> here distraction.
>
> The cost of this distraction is quite real: not only is there a
> performance penalty of running POSIX shell scripts on Windows, there are
> also problems with anti-malware disliking the way the POSIX emulation
> layer works that we currently have to use on Windows to run `git bisect`,
> which would be fixed by `bisect` being a full built-in. This distracting
> feedback that prevents a thorough code review delays that fix for those
> users.
>
> To understand what I am aiming for, look at the deep analysis of the
> rot13 filter conversion from Perl to C in
> https://lore.kernel.org/git/4n20476q-6ssr-osp8-q5o3-p8ns726q4pn3@tzk.qr/,
> where I carefully compared the behavior of the scripted code with the C
> code that was designed to replace it.
>
> At this point, it is good to recall Parkinson's law of triviality:
>
> 	Parkinson observed and illustrated that a committee whose job was
> 	to approve plans for a nuclear power plant spent the majority of
> 	its time with pointless discussions on relatively trivial and
> 	unimportant but easy-to-grasp issues, such as what materials to
> 	use for the staff bike-shed, while neglecting the less-trivial
> 	proposed design of the nuclear power plant itself, which is far
> 	more important but also a far more difficult and complex task to
> 	criticise constructively.
>
> We've seen quite a few regressions as of recent that would have likely
> been prevented by thorough reviews that do not distract themselves with
> tangents, pet peeves and personal taste.

One way to avoid regressions is to change fewer things, I've given you
some feedback about how you can accomplish the same things your series
is trying to do with much less churn.

> It would do good if we the reviewers on the Git mailing list took to heart
> that Git is a software that millions of users depend on, not just our toy
> to play with, and therefore the purpose of our reviews should aim to keep
> Git working and safe. We will achieve that only if we avoid what Parkinson
> called pointless discussions and instead put in the effort to provide
> high-quality feedback that helps improve the design and the correctness of
> the code.
>
> In this instance, the discussion about exit codes and usage messages
> should be postponed, in favor of focusing on the actual scope of this
> patch series.

You're replying downthread of a message where among other things I
pointed out a specific bug that's introduced in your series,
i.e. exactly the sort of code correctness feedback you claim to be
asking for.

Which is also a roundabout way of replying to your larger point
here. I.e. you're lamenting that I didn't provide you more feedback on
the specifics of your series.

That's true, but the reason I haven't spent time on doing that is from
past experience with you routinely ignoring feedback on your patches.

So as pointed to you (and not for the first time) upthread this is still
broken:

	$ ./git --list-cmds=parseopt | grep -o bisect
	bisect
	$ ./git bisect --git-completion-helper
	usage: git bisect [help|start|bad|good|new|old|terms|skip|next|reset|visualize|view|replay|log|run]

I.e. it should be:

	$ ./git --list-cmds=parseopt | grep -o bisect
        $

The fix on top of your series is easy:
	
	diff --git a/git.c b/git.c
	index 182ae9474de..ae99630b3c7 100644
	--- a/git.c
	+++ b/git.c
	@@ -492,7 +492,7 @@ static struct cmd_struct commands[] = {
	 	{ "annotate", cmd_annotate, RUN_SETUP },
	 	{ "apply", cmd_apply, RUN_SETUP_GENTLY },
	 	{ "archive", cmd_archive, RUN_SETUP_GENTLY },
	-	{ "bisect", cmd_bisect, RUN_SETUP },
	+	{ "bisect", cmd_bisect, RUN_SETUP | NO_PARSEOPT },
	 	{ "blame", cmd_blame, RUN_SETUP },
	 	{ "branch", cmd_branch, RUN_SETUP | DELAY_PAGER_CONFIG },
	 	{ "bugreport", cmd_bugreport, RUN_SETUP_GENTLY },

I think your participation in reviews would be much improved if you
replied more point-by-point, e.g. the initial report of this specific
issue in your series has been sitting on-list for 2 months ([1]) without
a follow-up.

When you do send something in reply it shows that you either haven't
read the feedback on your own series, or are deciding to actively ignore
it (but without really clarifying that that's what you're doing in those
specific cases). Or perhps you've just not understood what I've pointed
out to you (which might be on me). In any case having the discussion on
the original thread would be much more productive.

1. https://lore.kernel.org/git/220627.86mtdxhnwk.gmgdl@evledraar.gmail.com/