What's cooking in git.git (Jul 2022, #03; Mon, 11)
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: <[email protected]>
* 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: <[email protected]>
* 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: <[email protected]>
* 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: <[email protected]>
* 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: <[email protected]>
* 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: <[email protected]>
* 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: <[email protected]>
* 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: <[email protected]>
* 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: <[email protected]>
--------------------------------------------------
[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: <[email protected]>
* 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: <[email protected]>
* 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: <[email protected]>
* jk/ref-filter-discard-commit-buffer (2022-07-11) 1 commit
- ref-filter: disable save_commit_buffer while traversing
source: <[email protected]>
--------------------------------------------------
[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: <[email protected]>
* 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. <[email protected]>
source: <[email protected]>
* 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: <[email protected]>
--------------------------------------------------
[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: <[email protected]>
* 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/[email protected]>
source: <[email protected]>
* 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: <[email protected]>
* 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: <[email protected]>
* 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: <[email protected]>
* 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: <[email protected]>
* 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: <[email protected]>
* 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: <[email protected]>
* 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: <[email protected]>
* 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: <[email protected]>
* 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. <[email protected]>
source: <[email protected]>
* 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: <[email protected]>
* 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: <[email protected]>
* 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: <[email protected]>
* 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: <[email protected]>
* 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: <[email protected]>
* 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: <[email protected]>
* 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: <[email protected]>
* 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: <[email protected]>
* 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: <[email protected]>
* 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: <[email protected]>
* 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: <[email protected]>
* 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: <[email protected]>
* 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: <[email protected]>
* 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: <[email protected]>
* 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: <[email protected]>
* 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. <[email protected]>
source: <[email protected]>
* 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: <[email protected]>
* 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: <[email protected]>
* 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: <[email protected]>
* 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: <[email protected]>
* 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: <[email protected]>
* 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: <[email protected]>
* 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: <[email protected]>
* 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: <[email protected]>
* 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: <[email protected]>
* 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: <[email protected]>
* 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: <[email protected]>
* 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. <[email protected]>
source: <[email protected]>
* 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: <[email protected]>
* 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. <[email protected]>
source: <[email protected]>
* 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: <[email protected]>
* 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: <[email protected]>
source: <[email protected]>
--------------------------------------------------
[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: <[email protected]>
gc/bare-repo-discovery (was Re: What's cooking in git.git (Jul 2022, #03; Mon, 11))
Quoted 4 lines · Junio C Hamano
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!
Quoted 7 lines
* gc/bare-repo-discovery (2022-07-07) 5 commits
-setup.c: creatediscovery.bare
- safe.directory: usegit_protected_config()
- config: learngit_protected_config()
- Documentation: define protected configuration
-Documentation/git-config.txt: add SCOPES section
Quoted 5 lines
Introduce a discovery.barerepository configuration variable that allows users to forbid discovery of bare repositories.
Will merge to 'next'?
source: <[email protected]>
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.
Re: gc/bare-repo-discovery (was Re: What's cooking in git.git (Jul 2022, #03; Mon, 11))
Quoted 4 lines · Glen Choo
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: gc/bare-repo-discovery (was Re: What's cooking in git.git (Jul 2022, #03; Mon, 11))
Hi,
Quoted 10 lines · Junio C Hamano
Quoted 4 lines · Glen Choo
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))
Quoted 2 lines · Johannes Schindelin
I would find
safe.bareRepository = trueorfalsemore intuitive, and more concise.
Yup, that is fine by me.
Quoted 3 lines
And if there should be an option to ignore bare repositories when discovering a Git repository, it could be a tristate, with
ignorebeing the value to trigger that mode.
Sounds good.
Quoted 16 lines · Junio C Hamano
[New Topics]
* po/doc-add-renormalize (2022-07-09) 1 commit
- doc add: renormalize is not idempotent for CRCRLFDocumentation 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
Quoted 5 lines
The glossary entries for "commit-graph file" and "reachability bitmap" have been added.
Will merge to 'next'?
source: <[email protected]>
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
Quoted 3 lines · Philip Oakley
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".
ac/bitmap-lookup-table (was: Re: What's cooking in git.git (Jul 2022, #03; Mon, 11))
In reply to Junio C HamanoHi Junio,
Quoted 8 lines · Junio C Hamano
* 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
Quoted 5 lines
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: <[email protected]>
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
Re: ac/bitmap-lookup-table
Quoted 17 lines · Taylor Blau
Hi Junio,
Quoted 8 lines · Junio C Hamano
* 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 extensionQuoted 5 lines
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: <[email protected]>
Quoted 6 lines
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!
js/bisect-in-c, was Re: What's cooking in git.git (Jul 2022, #03; Mon, 11)
In reply to Junio C HamanoHi Junio,
Quoted 18 lines · Junio C Hamano
* js/bisect-in-c (2022-06-27) 16 commits
- bisect: no longer try to clean up left-over.git/head-namefiles
- bisect: remove Cogito-related code
- Turngit bisectinto a full built-in
- bisect: move even the command-line parsing tobisect--helper
- bisect: teach thebisect--helpercommand to show the correct usage strings
- bisect--helper: return only correct exit codes incmd_*()
- bisect--helper: move theBISECT_STATEcase to the end
- bisect--helper: make--bisect-stateoptional
- bisect--helper: align the sub-command order withgit-bisect.sh
- bisect--helper: using--bisect-statewithout 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
Quoted 4 lines
Final bits of "git
bisect.sh" have been rewritten in C.Expecting a (hopefully final) reroll.
cf. <[email protected]>
I did not find that one, but I found
https://lore.kernel.org/git/[email protected]/
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.
Quoted 1 line
source: <[email protected]>
Thanks,
Dscho
Re: js/bisect-in-c, was Re: What's cooking in git.git (Jul 2022, #03; Mon, 11)
Quoted 27 lines · Johannes Schindelin
Hi Junio,
Quoted 18 lines · Junio C Hamano
* js/bisect-in-c (2022-06-27) 16 commits
- bisect: no longer try to clean up left-over.git/head-namefiles
- bisect: remove Cogito-related code
- Turngit bisectinto a full built-in
- bisect: move even the command-line parsing tobisect--helper
- bisect: teach thebisect--helpercommand to show the correct usage strings
- bisect--helper: return only correct exit codes incmd_*()
- bisect--helper: move theBISECT_STATEcase to the end
- bisect--helper: make--bisect-stateoptional
- bisect--helper: align the sub-command order withgit-bisect.sh
- bisect--helper: using--bisect-statewithout 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 bisectionQuoted 4 lines
Final bits of "git
bisect.sh" have been rewritten in C.Expecting a (hopefully final) reroll.
cf. <[email protected]>
Quoted 8 lines
I did not find that one, but I found
https://lore.kernel.org/git/[email protected]/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.
Quoted 2 lines
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/[email protected]/
2. https://lore.kernel.org/git/[email protected]/
3. https://lore.kernel.org/git/[email protected]/
Re: js/bisect-in-c, was Re: What's cooking in git.git (Jul 2022, #03; Mon, 11)
Quoted 11 lines · Ævar Arnfjörð Bjarmason
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 $? 129But 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.
Quoted 4 lines
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?
Quoted 11 lines
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/[email protected]/
2. https://lore.kernel.org/git/[email protected]/
3. https://lore.kernel.org/git/[email protected]/
Re: js/bisect-in-c, was Re: What's cooking in git.git (Jul 2022, #03; Mon, 11)
Quoted 23 lines · Junio C Hamano
Quoted 11 lines · Ævar Arnfjörð Bjarmason
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 $? 129But 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.
Quoted 4 lines
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.
Quoted 5 lines
"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 :)
Quoted 11 lines
Quoted 11 lines
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/[email protected]/
2. https://lore.kernel.org/git/[email protected]/
3. https://lore.kernel.org/git/[email protected]/
Re: js/bisect-in-c, was Re: What's cooking in git.git (Jul 2022, #03; Mon, 11)
In reply to Junio C HamanoHi Junio,
Quoted 11 lines · Junio C Hamano
Quoted 9 lines · Ævar Arnfjörð Bjarmason
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
Quoted 6 lines
Quoted 2 lines
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)
Quoted 22 lines · Johannes Schindelin
Hi Junio,
Quoted 11 lines · Junio C Hamano
Quoted 9 lines · Ævar Arnfjörð Bjarmason
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 $? 129Quoted 6 lines
Quoted 2 lines
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.
Quoted 5 lines
This patch series already implements
git bisectin 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
Re: js/bisect-in-c, was Re: What's cooking in git.git (Jul 2022, #03; Mon, 11)
Hi Ævar,
Quoted 28 lines · Ævar Arnfjörð Bjarmason
Quoted 20 lines · Johannes Schindelin
Quoted 11 lines · Junio C Hamano
Quoted 9 lines · Ævar Arnfjörð Bjarmason
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 $? 129Quoted 6 lines
Quoted 2 lines
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.
Quoted 5 lines
This patch series already implements
git bisectin 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
Quoted 5 lines
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 callusage_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/[email protected]/,
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)
Quoted 38 lines · Johannes Schindelin
Hi Ævar,
Quoted 28 lines · Ævar Arnfjörð Bjarmason
Quoted 20 lines · Johannes Schindelin
Quoted 11 lines · Junio C Hamano
Quoted 9 lines · Ævar Arnfjörð Bjarmason
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 $? 129Quoted 6 lines
Quoted 2 lines
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.
Quoted 5 lines
This patch series already implements
git bisectin 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] 129Quoted 5 lines
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 callusage_msg_opt().
Quoted 6 lines
It would have been better to take the time to spell out clearly that you are taking offense in
git bisect start -hnot 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/[email protected]/
Quoted 3 lines
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.
Quoted 11 lines
(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 -hshows the usage ofbisect--helper!Instead, the scope of the patch series is to finalize converting the
bisectcommand 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 -hto 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.
Quoted 5 lines
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.
...
Quoted 3 lines
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=Dschobehaves.
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?
Quoted 31 lines
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 bybisectbeing 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/[email protected]/,
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.
Quoted 3 lines
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.
Quoted 11 lines
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.