* What's cooking in git.git (Aug 2022, #05; Mon, 15)
@ 2022-08-15 21:24 Junio C Hamano
2022-08-16 8:56 ` js/bisect-in-c, was " Johannes Schindelin
` (2 more replies)
0 siblings, 3 replies; 13+ messages in thread
From: Junio C Hamano @ 2022-08-15 21:24 UTC (permalink / raw)
To: git
Here are the topics that have been cooking in my tree. Commits
prefixed with '+' are in 'next' (being in 'next' is a sign that a
topic is stable enough to be used and are candidate to be in a future
release). Commits prefixed with '-' are only in 'seen', and aren't
considered "accepted" at all. A topic without enough support may be
discarded after a long period of no activity.
We are at the beginning of the week #6 of a 12-week cycle (cf.
https://tinyurl.com/gitCal).
Copies of the source code to Git live in many repositories, and the
following is a list of the ones I push into or their mirrors. Some
repositories have only a subset of branches.
With maint, master, next, seen, todo:
git://git.kernel.org/pub/scm/git/git.git/
git://repo.or.cz/alt-git.git/
https://kernel.googlesource.com/pub/scm/git/git/
https://github.com/git/git/
https://gitlab.com/git-vcs/git/
With all the integration branches and topics broken out:
https://github.com/gitster/git/
Even though the preformatted documentation in HTML and man format
are not sources, they are published in these repositories for
convenience (replace "htmldocs" with "manpages" for the manual
pages):
git://git.kernel.org/pub/scm/git/git-htmldocs.git/
https://github.com/gitster/git-htmldocs.git/
Release tarballs are available at:
https://www.kernel.org/pub/software/scm/git/
--------------------------------------------------
[Graduated to 'master']
* ab/hooks-regression-fix (2022-08-05) 1 commit
(merged to 'next' on 2022-08-08 at f5a3f88983)
+ hook API: don't segfault on strbuf_addf() to NULL "out"
A follow-up fix to a fix for a regression in 2.36.
source: <patch-1.1-2450e3e65cf-20220805T141402Z-avarab@gmail.com>
* ab/leak-check (2022-07-27) 15 commits
(merged to 'next' on 2022-08-05 at 2a6b9c8432)
+ CI: use "GIT_TEST_SANITIZE_LEAK_LOG=true" in linux-leaks
+ upload-pack: fix a memory leak in create_pack_file()
+ leak tests: mark passing SANITIZE=leak tests as leak-free
+ leak tests: don't skip some tests under SANITIZE=leak
+ test-lib: have the "check" mode for SANITIZE=leak consider leak logs
+ test-lib: add a GIT_TEST_PASSING_SANITIZE_LEAK=check mode
+ test-lib: simplify by removing test_external
+ tests: move copy/pasted PERL + Test::More checks to a lib-perl.sh
+ t/Makefile: don't remove test-results in "clean-except-prove-cache"
+ test-lib: add a SANITIZE=leak logging mode
+ t/README: reword the "GIT_TEST_PASSING_SANITIZE_LEAK" description
+ test-lib: add a --invert-exit-code switch
+ test-lib: fix GIT_EXIT_OK logic errors, use BAIL_OUT
+ test-lib: don't set GIT_EXIT_OK before calling test_atexit_handler
+ test-lib: use $1, not $@ in test_known_broken_{ok,failure}_
Extend SANITIZE=leak checking and declare more tests "currently leak-free".
source: <cover-v3-00.15-00000000000-20220727T230800Z-avarab@gmail.com>
* ab/plug-revisions-leak (2022-08-03) 6 commits
(merged to 'next' on 2022-08-05 at d1ca88976f)
+ revisions API: don't leak memory on argv elements that need free()-ing
+ bisect.c: partially fix bisect_rev_setup() memory leak
+ log: refactor "rev.pending" code in cmd_show()
+ log: fix a memory leak in "git show <revision>..."
+ test-fast-rebase helper: use release_revisions() (again)
+ bisect.c: add missing "goto" for release_revisions()
Plug a bit more leaks in the revisions API.
source: <cover-v3-0.6-00000000000-20220802T152925Z-avarab@gmail.com>
* ab/tech-docs-to-help (2022-08-04) 12 commits
(merged to 'next' on 2022-08-08 at 65c9ec7308)
+ docs: move http-protocol docs to man section 5
+ docs: move cruft pack docs to gitformat-pack
+ docs: move pack format docs to man section 5
+ docs: move signature docs to man section 5
+ docs: move index format docs to man section 5
+ docs: move protocol-related docs to man section 5
+ docs: move commit-graph format docs to man section 5
+ git docs: add a category for file formats, protocols and interfaces
+ git docs: add a category for user-facing file, repo and command UX
+ git help doc: use "<doc>" instead of "<guide>"
+ help.c: remove common category behavior from drop_prefix() behavior
+ help.c: refactor drop_prefix() to use a "switch" statement"
Expose a lot of "tech docs" via "git help" interface.
source: <cover-v8-00.12-00000000000-20220804T162138Z-avarab@gmail.com>
* gc/git-reflog-doc-markup (2022-08-01) 1 commit
(merged to 'next' on 2022-08-05 at f2d8721ab2)
+ Documentation/git-reflog: remove unneeded \ from \{
Doc mark-up fix.
source: <pull.1304.git.git.1659387885711.gitgitgadget@gmail.com>
* jc/rerere-autoupdate-doc (2022-08-03) 2 commits
(merged to 'next' on 2022-08-08 at 6407091d13)
+ doc: clarify rerere-autoupdate
+ doc: consolidate --rerere-autoupdate description
Update documentation on the "--[no-]rerere-autoupdate" option.
source: <xmqq35f2ysd9.fsf@gitster.g>
* js/safe-directory-plus (2022-08-08) 5 commits
(merged to 'next' on 2022-08-10 at 3d32a87210)
+ mingw: handle a file owned by the Administrators group correctly
+ mingw: be more informative when ownership check fails on FAT32
+ mingw: provide details about unsafe directories' ownership
+ setup: prepare for more detailed "dubious ownership" messages
+ setup: fix some formatting
Platform-specific code that determines if a directory is OK to use
as a repository has been taught to report more details, especially
on Windows.
source: <pull.1286.v2.git.1659965270.gitgitgadget@gmail.com>
* lt/symbolic-ref-sanity (2022-08-01) 1 commit
(merged to 'next' on 2022-08-03 at 443647b94a)
+ symbolic-ref: refuse to set syntactically invalid target
"git symbolic-ref symref non..sen..se" is now diagnosed as an error.
source: <YugYNzQYWqDCmOqN@coredump.intra.peff.net>
* pw/use-glibc-tunable-for-malloc-optim (2022-08-04) 1 commit
(merged to 'next' on 2022-08-08 at 1300f84dc4)
+ tests: cache glibc version check
Avoid repeatedly running getconf to ask libc version in the test
suite, and instead just as it once per script.
source: <pull.1311.git.1659620305757.gitgitgadget@gmail.com>
--------------------------------------------------
[New Topics]
* ll/disk-usage-humanise (2022-08-11) 1 commit
(merged to 'next' on 2022-08-14 at 3873a83f90)
+ rev-list: support human-readable output for `--disk-usage`
"git rev-list --disk-usage" learned to take an optional value
"human" to show the reported value in human-readable format, like
"3.40MiB".
Will merge to 'master'.
source: <pull.1313.v5.git.1660193274336.gitgitgadget@gmail.com>
* ed/fsmonitor-on-network-disk (2022-08-11) 1 commit
(merged to 'next' on 2022-08-14 at 637d458d9c)
+ fsmonitor: option to allow fsmonitor to run against network-mounted repos
The built-in fsmonitor refuses to work on a network mounted
repositories; a configuration knob for users to override this has
been introduced.
Will merge to 'master'.
source: <pull.1317.v4.git.1660262231357.gitgitgadget@gmail.com>
* jk/is-promisor-object-keep-tree-in-use (2022-08-14) 1 commit
- is_promisor_object(): fix use-after-free of tree buffer
An earlier optimization discarded a tree-object buffer that is
still in use, which has been corrected.
Will merge to 'next'.
source: <YviWO9Bhz5PU1HaL@coredump.intra.peff.net>
* js/fetch-negotiation-trace (2022-08-15) 1 commit
- fetch-pack: add tracing for negotiation rounds
The common ancestor negotiation exchange during a "git fetch"
session now leaves trace log.
Will merge to 'next'.
source: <4390677ec75d51487142adf7c2ab821cbd24a53e.1659477669.git.steadmon@google.com>
* pw/rebase-keep-base-fixes (2022-08-15) 5 commits
- rebase --keep-base: imply --no-fork-point
- rebase --keep-base: imply --reapply-cherry-picks
- rebase: factor out merge_base calculation
- rebase: store orig_head as a commit
- t3416: set $EDITOR in subshell
"git rebase --keep-base" used to discard the commits that are
already cherry-picked to the upstream, even when "keep-base" meant
that the base, on top of which the history is being rebuilt, does
not yet include these cherry-picked commits. The --keep-base
option now implies --reapply-cherry-picks and --no-fork-point
options.
Needs review.
source: <pull.1323.git.1660576283.gitgitgadget@gmail.com>
--------------------------------------------------
[Cooking]
* fc/vimdiff-layout-vimdiff3-fix (2022-08-10) 7 commits
(merged to 'next' on 2022-08-11 at a14fec292f)
+ mergetools: vimdiff: simplify tabfirst
+ mergetools: vimdiff: fix single window layouts
+ mergetools: vimdiff: rework tab logic
+ mergetools: vimdiff: fix for diffopt
+ mergetools: vimdiff: silence annoying messages
+ mergetools: vimdiff: make vimdiff3 actually work
+ mergetools: vimdiff: fix comment
"vimdiff3" regression fix.
Will merge to 'master'.
source: <20220810154618.307275-1-felipe.contreras@gmail.com>
* jk/fsck-tree-mode-bits-fix (2022-08-10) 3 commits
(merged to 'next' on 2022-08-11 at 219fe53025)
+ fsck: downgrade tree badFilemode to "info"
+ fsck: actually detect bad file modes in trees
+ tree-walk: add a mechanism for getting non-canonicalized modes
"git fsck" reads mode from tree objects but canonicalizes the mode
before passing it to the logic to check object sanity, which has
hid broken tree objects from the checking logic. This has been
corrected, but to help exiting projects with broken tree objects
that they cannot fix retroactively, the severity of anomalies this
code detects has been demoted to "info" for now.
Will merge to 'master'.
source: <YvQcNpizy9uOZiAz@coredump.intra.peff.net>
* ag/merge-strategies-in-c (2022-08-10) 14 commits
- sequencer: use the "octopus" strategy without forking
- sequencer: use the "resolve" strategy without forking
- merge: use the "octopus" strategy without forking
- merge: use the "resolve" strategy without forking
- merge-octopus: rewrite in C
- merge-recursive: move better_branch_name() to merge.c
- merge-resolve: rewrite in C
- merge-one-file: rewrite in C
- update-index: move add_cacheinfo() to read-cache.c
- merge-index: add a new way to invoke `git-merge-one-file'
- merge-index: drop the index
- merge-index: libify merge_one_path() and merge_all()
- t6060: add tests for removed files
- t6060: modify multiple files to expose a possible issue with merge-index
An attempt to rewrite remaining merge strategies from shell to C.
source: <20220809185429.20098-1-alban.gruin@gmail.com>
* sy/mv-out-of-cone (2022-08-10) 9 commits
- mv: check overwrite for in-to-out move
- advice.h: add advise_on_moving_dirty_path()
- mv: cleanup empty WORKING_DIRECTORY
- mv: from in-cone to out-of-cone
- mv: remove BOTH from enum update_mode
- mv: check if <destination> is a SKIP_WORKTREE_DIR
- mv: free the with_slash in check_dir_in_index()
- mv: rename check_dir_in_index() to empty_dir_has_sparse_contents()
- t7002: add tests for moving from in-cone to out-of-cone
"git mv A B" in a sparsely populated working tree can be asked to
move a path from a directory that is "in cone" to another directory
that is "out of cone". Handling of such a case has been improved.
Will merge to 'next'?
source: <20220809120910.2021413-1-shaoxuan.yuan02@gmail.com>
* sy/sparse-rm (2022-08-08) 5 commits
(merged to 'next' on 2022-08-12 at 5bf10965fb)
+ rm: integrate with sparse-index
+ rm: expand the index only when necessary
+ pathspec.h: move pathspec_needs_expanded_index() from reset.c to here
+ t1092: add tests for `git-rm`
+ Merge branch 'vd/sparse-reset-checkout-fixes' into sy/sparse-rm
(this branch uses vd/sparse-reset-checkout-fixes.)
"git rm" has become more aware of the sparse-index feature.
Will merge to 'master'.
source: <20220807041335.1790658-1-shaoxuan.yuan02@gmail.com>
* vd/scalar-generalize-diagnose (2022-08-12) 11 commits
- scalar: update technical doc roadmap
- scalar-diagnose: use 'git diagnose --mode=all'
- builtin/bugreport.c: create '--diagnose' option
- builtin/diagnose.c: add '--mode' option
- builtin/diagnose.c: create 'git diagnose' builtin
- diagnose.c: add option to configure archive contents
- scalar-diagnose: move functionality to common location
- scalar-diagnose: move 'get_disk_info()' to 'compat/'
- scalar-diagnose: add directory to archiver more gently
- scalar-diagnose: avoid 32-bit overflow of size_t
- scalar-diagnose: use "$GIT_UNZIP" in test
The "diagnose" feature to create a zip archive for diagnostic
material has been lifted from "scalar" and made into a feature of
"git bugreport".
Will merge to 'next'?
source: <pull.1310.v4.git.1660335019.gitgitgadget@gmail.com>
* jk/pipe-command-nonblock (2022-08-03) 1 commit
- pipe_command(): mark stdin descriptor as non-blocking
Fix deadlocks between main Git process and subprocess spawned via
the pipe_command() API, that can kill "git add -p" that was
reimplemented in C recently.
Needs waiting for corresponding change to Windows to put the pipe
into nonblock mode.
cf. <YulFTSTbVaTwuQtt@coredump.intra.peff.net>
source: <YunxHOa2sJeEpJxd@coredump.intra.peff.net>
* es/mark-gc-cruft-as-experimental (2022-08-03) 2 commits
- config: let feature.experimental imply gc.cruftPacks=true
- gc: add tests for --cruft and friends
Enable gc.cruftpacks by default for those who opt into
feature.experimental setting.
Expecting a reroll.
cf. <220804.86a68ke9d5.gmgdl@evledraar.gmail.com>
cf. <6803b725-526e-a1c8-f15c-a9ed4a144d4c@github.com>
source: <20220803205721.3686361-1-emilyshaffer@google.com>
* vd/sparse-reset-checkout-fixes (2022-08-08) 4 commits
(merged to 'next' on 2022-08-12 at 755d6ecdb8)
+ unpack-trees: unpack new trees as sparse directories
+ cache.h: create 'index_name_pos_sparse()'
+ oneway_diff: handle removed sparse directories
+ checkout: fix nested sparse directory diff in sparse index
(this branch is used by sy/sparse-rm.)
Fixes to sparse index compatibility work for "reset" and "checkout"
commands.
Will merge to 'master'.
source: <pull.1312.v3.git.1659985672.gitgitgadget@gmail.com>
* sg/parse-options-subcommand (2022-07-25) 20 commits
- builtin/worktree.c: let parse-options parse subcommands
- builtin/stash.c: let parse-options parse subcommands
- builtin/sparse-checkout.c: let parse-options parse subcommands
- builtin/remote.c: let parse-options parse subcommands
- builtin/reflog.c: let parse-options parse subcommands
- builtin/notes.c: let parse-options parse subcommands
- builtin/multi-pack-index.c: let parse-options parse subcommands
- builtin/hook.c: let parse-option parse subcommands
- builtin/gc.c: let parse-options parse 'git maintenance's subcommands
- builtin/commit-graph.c: let parse-options parse subcommands
- builtin/bundle.c: let parse-options parse subcommands
- parse-options: add support for parsing subcommands
- parse-options: drop leading space from '--git-completion-helper' output
- parse-options: clarify the limitations of PARSE_OPT_NODASH
- parse-options: PARSE_OPT_KEEP_UNKNOWN only applies to --options
- api-parse-options.txt: fix description of OPT_CMDMODE
- t0040-parse-options: test parse_options() with various 'parse_opt_flags'
- t5505-remote.sh: check the behavior without a subcommand
- t3301-notes.sh: check that default operation mode doesn't take arguments
- git.c: update NO_PARSEOPT markings
Introduce the "subcommand" mode to parse-options API and update the
command line parser of Git commands with subcommands.
Expecting a reroll.
cf. <20220812152837.GC3790@szeder.dev>
source: <20220725123857.2773963-1-szeder.dev@gmail.com>
* ds/bundle-uri-clone (2022-08-10) 5 commits
- clone: --bundle-uri cannot be combined with --depth
- bundle-uri: add support for http(s):// and file://
- clone: add --bundle-uri option
- bundle-uri: create basic file-copy logic
- remote-curl: add 'get' capability
Implement "git clone --bundle-uri".
source: <pull.1300.v3.git.1660050703.gitgitgadget@gmail.com>
* ds/decorate-filter-tweak (2022-08-05) 11 commits
- fetch: use ref_namespaces during prefetch
- maintenance: stop writing log.excludeDecoration
- log: create log.initialDecorationSet=all
- log: add --clear-decorations option
- log: add default decoration filter
- log-tree: use ref_namespaces instead of if/else-if
- refs: use ref_namespaces for replace refs base
- refs: add array of ref namespaces
- t4207: test coloring of grafted decorations
- t4207: modernize test
- refs: allow "HEAD" as decoration filter
The namespaces used by "log --decorate" from "refs/" hierarchy by
default has been tightened.
Will merge to 'next'?
source: <pull.1301.v3.git.1659722323.gitgitgadget@gmail.com>
* es/doc-creation-factor-fix (2022-07-28) 2 commits
- range-diff: clarify --creation-factor=<factor>
- format-patch: clarify --creation-factor=<factor>
Expecting a reroll.
source: <7229p500-p2r4-on87-6802-8o90s36rr3s4@tzk.qr>
* ab/submodule-helper-prep (2022-08-03) 28 commits
- submodule--helper: fix bad config API usage
- submodule--helper: libify "must_die_on_failure" code paths (for die)
- submodule--helper: libify "must_die_on_failure" code paths
- submodule--helper: libify determine_submodule_update_strategy()
- submodule--helper: don't exit() on failure, return
- submodule--helper: use "code" in run_update_command()
- submodule--helper: move submodule_strategy_to_string() to only user
- submodule--helper: don't call submodule_strategy_to_string() in BUG()
- submodule--helper: add missing braces to "else" arm
- submodule--helper: return "ret", not "1" from update_submodule()
- submodule--helper: rename "int res" to "int ret"
- submodule--helper: don't redundantly check "else if (res)"
- submodule--helper: refactor "errmsg_str" to be a "struct strbuf"
- submodule--helper: add "const" to copy of "update_data"
- submodule--helper: pass a "const struct module_clone_data" to clone_submodule()
- submodule--helper: move "sb" in clone_submodule() to its own scope
- submodule--helper: use xstrfmt() in clone_submodule()
- submodule--helper: replace memset() with { 0 }-initialization
- submodule--helper style: add \n\n after variable declarations
- submodule--helper style: don't separate declared variables with \n\n
- submodule--helper: move "resolve-relative-url-test" to a test-tool
- submodule--helper: move "check-name" to a test-tool
- submodule--helper: move "is-active" to a test-tool
- test-tool submodule-config: remove unused "--url" handling
- submodule--helper: remove unused "list" helper
- submodule--helper: remove unused "name" helper
- submodule tests: test for "add <repository> <abs-path>"
- submodule tests: test usage behavior
(this branch is used by ab/submodule-helper-leakfix.)
Code clean-up of "git submodule--helper".
Expecting a (hopefully final?) reroll.
cf. <220803.86h72tfpcc.gmgdl@evledraar.gmail.com>
source: <cover-v2-00.28-00000000000-20220802T154036Z-avarab@gmail.com>
* ab/dedup-config-and-command-docs (2022-07-29) 9 commits
- docs: add CONFIGURATION sections that fuzzy map to built-ins
- docs: add CONFIGURATION sections that map to a built-in
- log docs: de-duplicate configuration sections
- difftool docs: de-duplicate configuration sections
- notes docs: de-duplicate configuration sections
- apply docs: de-duplicate configuration sections
- send-email docs: de-duplicate configuration sections
- grep docs: de-duplicate configuration sections
- docs: add and use include template for config/* includes
Share the text used to explain configuration variables used by "git
<subcmd>" in "git help <subcmd>" with the text from "git help config".
Expecting a reroll.
cf. <CAHd-oW5mD-H1kvuF9VEVb8KjaSkUSUpBH-WAkpCn6_Ci8o888w@mail.gmail.com>
cf. <CAHd-oW7s6Hu24uTjCW9ROBbJkA5+7TCu32a4L_BXVLhcvw5kSw@mail.gmail.com>
cf. <xmqqlesb4lwh.fsf@gitster.g>
source: <cover-v2-0.9-00000000000-20220729T081959Z-avarab@gmail.com>
* cw/remote-object-info (2022-08-13) 7 commits
- SQUASH???
- cat-file: add remote-object-info to batch-command
- transport: add client support for object-info
- serve: advertise object-info feature
- protocol-caps: initialization bug fix
- fetch-pack: move fetch initialization
- fetch-pack: refactor packet writing
A client component to talk with the object-info endpoint.
Expecting a reroll.
cf. <20220728230210.2952731-1-calvinwan@google.com>
cf. <CAFySSZDvgwbbHCHfyuaqX3tKsr-GjJ9iihygg6rNNe46Ys7_EA@mail.gmail.com>
source: <20220728230210.2952731-1-calvinwan@google.com>
* mt/rot13-in-c (2022-08-14) 4 commits
- tests: use the new C rot13-filter helper to avoid PERL prereq
- t0021: implementation the rot13-filter.pl script in C
- t0021: avoid grepping for a Perl-specific string at filter output
- Merge branch 'mt/checkout-count-fix' into mt/rot13-in-c
Test portability improvements.
Will merge to 'next'?
source: <cover.1660522524.git.matheus.bernardino@usp.br>
* tl/trace2-config-scope (2022-08-11) 2 commits
- tr2: shows scope unconditionally in addition to key-value pair
- api-trace2.txt: print config key-value pair
Tweak trace2 output about configuration variables.
source: <cover.1660272404.git.dyroneteng@gmail.com>
* ab/submodule-helper-leakfix (2022-08-03) 18 commits
- submodule--helper: fix a configure_added_submodule() leak
- submodule--helper: free rest of "displaypath" in "struct update_data"
- submodule--helper: free some "displaypath" in "struct update_data"
- submodule--helper: fix a memory leak in print_status()
- submodule--helper: fix a leak in module_add()
- submodule--helper: fix obscure leak in module_add()
- submodule--helper: fix "reference" leak
- submodule--helper: fix a memory leak in get_default_remote_submodule()
- submodule--helper: fix a leak with repo_clear()
- submodule--helper: fix "sm_path" and other "module_cb_list" leaks
- submodule--helper: fix "errmsg_str" memory leak
- submodule--helper: add and use *_release() functions
- submodule--helper: don't leak {run,capture}_command() cp.dir argument
- submodule--helper: "struct pathspec" memory leak in module_update()
- submodule--helper: fix most "struct pathspec" memory leaks
- submodule--helper: fix trivial get_default_remote_submodule() leak
- submodule--helper: fix a leak in "clone_submodule"
- Merge branch 'ab/submodule-helper-prep' into ab/submodule-helper-leakfix
(this branch uses ab/submodule-helper-prep.)
Plugging leaks in submodule--helper.
Getting there.
source: <cover-v5-00.17-00000000000-20220802T155002Z-avarab@gmail.com>
* cw/submodule-merge-messages (2022-08-04) 1 commit
(merged to 'next' on 2022-08-12 at ede0890319)
+ submodule merge: update conflict error message
Update the message given when "git merge" sees conflicts at a path
with a submodule while merging a superproject.
Will merge to 'master'.
source: <20220804195105.1303455-1-calvinwan@google.com>
* po/doc-add-renormalize (2022-08-10) 1 commit
(merged to 'next' on 2022-08-11 at 53851663eb)
+ doc add: renormalize is not idempotent for CRCRLF
Documentation for "git add --renormalize" has been improved.
Will merge to 'master'.
source: <20220810144450.470-2-philipoakley@iee.email>
* po/glossary-around-traversal (2022-07-09) 3 commits
- glossary: add reachability bitmap description
- glossary: add commit graph description
- glossary: add Object DataBase (ODB) abbreviation
The glossary entries for "commit-graph file" and "reachability
bitmap" have been added.
Expecting a reroll.
cf. <dfe0c1ab-33f8-f13e-71ce-1829bb0d2d7f@iee.email>
source: <pull.1282.git.1657385781.gitgitgadget@gmail.com>
* ac/bitmap-lookup-table (2022-08-14) 6 commits
- bitmap-lookup-table: add performance tests for lookup table
- pack-bitmap: prepare to read lookup table extension
- pack-bitmap-write: learn pack.writeBitmapLookupTable and add tests
- pack-bitmap-write.c: write lookup table extension
- bitmap: move `get commit positions` code to `bitmap_writer_finish`
- Documentation/technical: describe bitmap lookup table extension
The pack bitmap file gained a bitmap-lookup table to speed up
locating the necessary bitmap for a given commit.
source: <pull.1266.v6.git.1660496112.gitgitgadget@gmail.com>
* jt/connected-show-missing-from-which-side (2022-06-10) 1 commit
- fetch,fetch-pack: clarify connectivity check error
We may find an object missing after a "git fetch" stores the
objects it obtained from the other side, but it is not necessarily
because the remote failed to send necessary objects. Reword the
messages in an attempt to help users explore other possibilities
when they hit this error.
Expecting a reroll.
source: <20220610195247.1177549-1-jonathantanmy@google.com>
* tb/show-ref-count (2022-06-06) 2 commits
- builtin/show-ref.c: limit output with `--count`
- builtin/show-ref.c: rename `found_match` to `matches_nr`
"git show-ref" learned to stop after emitting N refs with the new
"--count=N" option.
Expecting a reroll.
cf. <xmqqczfl4ce1.fsf@gitster.g>
source: <cover.1654552560.git.me@ttaylorr.com>
* ds/bundle-uri-more (2022-08-10) 2 commits
(merged to 'next' on 2022-08-12 at 4f445a058d)
+ bundle-uri: add example bundle organization
+ docs: document bundle URI standard
The "bundle URI" design gets documented.
Will merge to 'master'.
source: <pull.1248.v4.git.1660050761.gitgitgadget@gmail.com>
* js/bisect-in-c (2022-06-27) 16 commits
- bisect: no longer try to clean up left-over `.git/head-name` files
- bisect: remove Cogito-related code
- Turn `git bisect` into a full built-in
- bisect: move even the command-line parsing to `bisect--helper`
- bisect: teach the `bisect--helper` command to show the correct usage strings
- bisect--helper: return only correct exit codes in `cmd_*()`
- bisect--helper: move the `BISECT_STATE` case to the end
- bisect--helper: make `--bisect-state` optional
- bisect--helper: align the sub-command order with git-bisect.sh
- bisect--helper: using `--bisect-state` without an argument is a bug
- bisect--helper: really retire `--bisect-autostart`
- bisect--helper: really retire --bisect-next-check
- bisect--helper: retire the --no-log option
- bisect: avoid double-quoting when printing the failed command
- bisect run: fix the error message
- bisect: verify that a bogus option won't try to start a bisection
Final bits of "git bisect.sh" have been rewritten in C.
Expecting a (hopefully final) reroll.
cf. <20627.86ilolhnnn.gmgdl@evledraar.gmail.com>
source: <pull.1132.v4.git.1656354677.gitgitgadget@gmail.com>
--------------------------------------------------
[Discarded]
* mb/doc-rerere-autoupdate (2022-07-15) 1 commit
. cherry-pick doc: clarify no-rerere-autoupdate still allows rerere
Clarifies that the "--no-rerere-autoupdate" option does not disable
the "rerere" mechanism (nor does "--rerere-autoupdate" enable it).
Superseded by jc/rerere-autoupdate-doc
source: <20220715092527.1567837-1-mail@beyermatthias.de>
* fr/vimdiff-layout-colors-fix (2022-08-07) 3 commits
. mergetools: vimdiff: update unit tests
. mergetools: vimdiff: fix single tab mode, single window mode and colors
. mergetools: vimdiff: fix comment
"vimdiff3" regression fix.
Superseded by fc/vimdiff-layout-vimdiff3-fix
source: <20220808053459.184367-1-greenfoo@u92.eu>
* tk/apply-case-insensitive (2022-06-21) 3 commits
. apply: support case-only renames in case-insensitive filesystems
. reset: new failing test for reset of case-insensitive duplicate in index
. t4141: test "git apply" with core.ignorecase
"git apply" barfed on a patch that makes a case-only rename on a
case-insensitive filesystem.
In stalled state for too long.
source: <pull.1257.v2.git.1655655027.gitgitgadget@gmail.com>
* bc/stash-export (2022-04-08) 4 commits
. builtin/stash: provide a way to import stashes from a ref
. builtin/stash: provide a way to export stashes to a ref
. builtin/stash: factor out revision parsing into a function
. object-name: make get_oid quietly return an error
A mechanism to export and import stash entries to and from a normal
commit to transfer it across repositories has been introduced.
In stalled state for too long.
cf. <YnL2d4Vr9Vr7W4Hj@camp.crustytoothpaste.net>
source: <20220407215352.3491567-1-sandals@crustytoothpaste.net>
^ permalink raw reply [flat|nested] 13+ messages in thread
* js/bisect-in-c, was Re: What's cooking in git.git (Aug 2022, #05; Mon, 15)
2022-08-15 21:24 What's cooking in git.git (Aug 2022, #05; Mon, 15) Junio C Hamano
@ 2022-08-16 8:56 ` Johannes Schindelin
2022-08-17 1:26 ` Elijah Newren
2022-08-16 16:00 ` sy/mv-out-of-cone (was Re: What's cooking in git.git (Aug 2022, #05; Mon, 15)) Victoria Dye
2022-08-17 0:36 ` cw/submodule-merge-messages (Was: " Elijah Newren
2 siblings, 1 reply; 13+ messages in thread
From: Johannes Schindelin @ 2022-08-16 8:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
[-- Attachment #1: Type: text/plain, Size: 1966 bytes --]
Hi Junio,
On Mon, 15 Aug 2022, Junio C Hamano wrote:
> * js/bisect-in-c (2022-06-27) 16 commits
> - bisect: no longer try to clean up left-over `.git/head-name` files
> - bisect: remove Cogito-related code
> - Turn `git bisect` into a full built-in
> - bisect: move even the command-line parsing to `bisect--helper`
> - bisect: teach the `bisect--helper` command to show the correct usage strings
> - bisect--helper: return only correct exit codes in `cmd_*()`
> - bisect--helper: move the `BISECT_STATE` case to the end
> - bisect--helper: make `--bisect-state` optional
> - bisect--helper: align the sub-command order with git-bisect.sh
> - bisect--helper: using `--bisect-state` without an argument is a bug
> - bisect--helper: really retire `--bisect-autostart`
> - bisect--helper: really retire --bisect-next-check
> - bisect--helper: retire the --no-log option
> - bisect: avoid double-quoting when printing the failed command
> - bisect run: fix the error message
> - bisect: verify that a bogus option won't try to start a bisection
>
> Final bits of "git bisect.sh" have been rewritten in C.
>
> Expecting a (hopefully final) reroll.
> cf. <20627.86ilolhnnn.gmgdl@evledraar.gmail.com>
> source: <pull.1132.v4.git.1656354677.gitgitgadget@gmail.com>
I had another look at the thread and did not see any feedback that focuses
on the actual scope of the patch series. Conversions from scripted parts
of Git to built-ins are always a bit finicky (and hard to review, I
admit).
Therefore I would like to move the status to "needs review".
I do not think that there are any major issues with it (Ævar's feedback
notwithstanding, it focuses on tangents that should be addressed after the
conversion, to avoid losing focus), but I would love to see a thorough
review of the conversion to avoid obvious regressions like the one in the
built-in interactive `add` I had to fix recently.
Ciao,
Dscho
^ permalink raw reply [flat|nested] 13+ messages in thread
* sy/mv-out-of-cone (was Re: What's cooking in git.git (Aug 2022, #05; Mon, 15))
2022-08-15 21:24 What's cooking in git.git (Aug 2022, #05; Mon, 15) Junio C Hamano
2022-08-16 8:56 ` js/bisect-in-c, was " Johannes Schindelin
@ 2022-08-16 16:00 ` Victoria Dye
2022-08-16 16:16 ` Junio C Hamano
2022-08-17 2:03 ` Shaoxuan Yuan
2022-08-17 0:36 ` cw/submodule-merge-messages (Was: " Elijah Newren
2 siblings, 2 replies; 13+ messages in thread
From: Victoria Dye @ 2022-08-16 16:00 UTC (permalink / raw)
To: Junio C Hamano, git
Junio C Hamano wrote:
> * sy/mv-out-of-cone (2022-08-10) 9 commits
> - mv: check overwrite for in-to-out move
> - advice.h: add advise_on_moving_dirty_path()
> - mv: cleanup empty WORKING_DIRECTORY
> - mv: from in-cone to out-of-cone
> - mv: remove BOTH from enum update_mode
> - mv: check if <destination> is a SKIP_WORKTREE_DIR
> - mv: free the with_slash in check_dir_in_index()
> - mv: rename check_dir_in_index() to empty_dir_has_sparse_contents()
> - t7002: add tests for moving from in-cone to out-of-cone
>
> "git mv A B" in a sparsely populated working tree can be asked to
> move a path from a directory that is "in cone" to another directory
> that is "out of cone". Handling of such a case has been improved.
>
> Will merge to 'next'?
> source: <20220809120910.2021413-1-shaoxuan.yuan02@gmail.com>
>
After reviewing the latest version [1], I think this is ready for 'next'.
[1] https://lore.kernel.org/git/52b67242-5d91-5406-9c95-9d8ddc49c079@github.com/
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: sy/mv-out-of-cone (was Re: What's cooking in git.git (Aug 2022, #05; Mon, 15))
2022-08-16 16:00 ` sy/mv-out-of-cone (was Re: What's cooking in git.git (Aug 2022, #05; Mon, 15)) Victoria Dye
@ 2022-08-16 16:16 ` Junio C Hamano
2022-08-17 2:03 ` Shaoxuan Yuan
1 sibling, 0 replies; 13+ messages in thread
From: Junio C Hamano @ 2022-08-16 16:16 UTC (permalink / raw)
To: Victoria Dye, Shaoxuan Yuan; +Cc: git
Victoria Dye <vdye@github.com> writes:
> Junio C Hamano wrote:
>> * sy/mv-out-of-cone (2022-08-10) 9 commits
>> - mv: check overwrite for in-to-out move
>> - advice.h: add advise_on_moving_dirty_path()
>> - mv: cleanup empty WORKING_DIRECTORY
>> - mv: from in-cone to out-of-cone
>> - mv: remove BOTH from enum update_mode
>> - mv: check if <destination> is a SKIP_WORKTREE_DIR
>> - mv: free the with_slash in check_dir_in_index()
>> - mv: rename check_dir_in_index() to empty_dir_has_sparse_contents()
>> - t7002: add tests for moving from in-cone to out-of-cone
>>
>> "git mv A B" in a sparsely populated working tree can be asked to
>> move a path from a directory that is "in cone" to another directory
>> that is "out of cone". Handling of such a case has been improved.
>>
>> Will merge to 'next'?
>> source: <20220809120910.2021413-1-shaoxuan.yuan02@gmail.com>
>
> After reviewing the latest version [1], I think this is ready for 'next'.
>
> [1] https://lore.kernel.org/git/52b67242-5d91-5406-9c95-9d8ddc49c079@github.com/
Thanks, both.
^ permalink raw reply [flat|nested] 13+ messages in thread
* cw/submodule-merge-messages (Was: Re: What's cooking in git.git (Aug 2022, #05; Mon, 15))
2022-08-15 21:24 What's cooking in git.git (Aug 2022, #05; Mon, 15) Junio C Hamano
2022-08-16 8:56 ` js/bisect-in-c, was " Johannes Schindelin
2022-08-16 16:00 ` sy/mv-out-of-cone (was Re: What's cooking in git.git (Aug 2022, #05; Mon, 15)) Victoria Dye
@ 2022-08-17 0:36 ` Elijah Newren
2 siblings, 0 replies; 13+ messages in thread
From: Elijah Newren @ 2022-08-17 0:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
On Mon, Aug 15, 2022 at 6:50 PM Junio C Hamano <gitster@pobox.com> wrote:
>
> * cw/submodule-merge-messages (2022-08-04) 1 commit
> (merged to 'next' on 2022-08-12 at ede0890319)
> + submodule merge: update conflict error message
>
> Update the message given when "git merge" sees conflicts at a path
> with a submodule while merging a superproject.
>
> Will merge to 'master'.
> source: <20220804195105.1303455-1-calvinwan@google.com>
I apologize for being away and not reviewing again before this merged
to next (vacation followed by coming down with Covid). I noticed a
few issues with v8, so I submitted a few patches meant to go on top:
https://lore.kernel.org/git/pull.1325.git.1660696081.gitgitgadget@gmail.com/
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: js/bisect-in-c, was Re: What's cooking in git.git (Aug 2022, #05; Mon, 15)
2022-08-16 8:56 ` js/bisect-in-c, was " Johannes Schindelin
@ 2022-08-17 1:26 ` Elijah Newren
2022-08-17 6:27 ` Johannes Schindelin
2022-08-17 18:57 ` Junio C Hamano
0 siblings, 2 replies; 13+ messages in thread
From: Elijah Newren @ 2022-08-17 1:26 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Git Mailing List
Hi,
On Tue, Aug 16, 2022 at 3:49 AM Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
>
> Hi Junio,
>
> On Mon, 15 Aug 2022, Junio C Hamano wrote:
>
> > * js/bisect-in-c (2022-06-27) 16 commits
> > - bisect: no longer try to clean up left-over `.git/head-name` files
> > - bisect: remove Cogito-related code
> > - Turn `git bisect` into a full built-in
> > - bisect: move even the command-line parsing to `bisect--helper`
> > - bisect: teach the `bisect--helper` command to show the correct usage strings
> > - bisect--helper: return only correct exit codes in `cmd_*()`
> > - bisect--helper: move the `BISECT_STATE` case to the end
> > - bisect--helper: make `--bisect-state` optional
> > - bisect--helper: align the sub-command order with git-bisect.sh
> > - bisect--helper: using `--bisect-state` without an argument is a bug
> > - bisect--helper: really retire `--bisect-autostart`
> > - bisect--helper: really retire --bisect-next-check
> > - bisect--helper: retire the --no-log option
> > - bisect: avoid double-quoting when printing the failed command
> > - bisect run: fix the error message
> > - bisect: verify that a bogus option won't try to start a bisection
> >
> > Final bits of "git bisect.sh" have been rewritten in C.
> >
> > Expecting a (hopefully final) reroll.
> > cf. <20627.86ilolhnnn.gmgdl@evledraar.gmail.com>
Junio: This link came up dead for me; I think the intended link was
220627.86ilolhnnn.gmgdl@evledraar.gmail.com ?
> > source: <pull.1132.v4.git.1656354677.gitgitgadget@gmail.com>
>
> I had another look at the thread and did not see any feedback that focuses
> on the actual scope of the patch series. Conversions from scripted parts
> of Git to built-ins are always a bit finicky (and hard to review, I
> admit).
>
> Therefore I would like to move the status to "needs review".
>
> I do not think that there are any major issues with it (Ævar's feedback
> notwithstanding, it focuses on tangents that should be addressed after the
> conversion, to avoid losing focus), but I would love to see a thorough
> review of the conversion to avoid obvious regressions like the one in the
> built-in interactive `add` I had to fix recently.
I reviewed it --
https://lore.kernel.org/git/CABPp-BEOX+zxR9-yyx-EaiOV-Z9yD0YP_Kwvu4iGB8enz40XXQ@mail.gmail.com/.
I looked over the subsequent iterations too, and they still look good
to me.
Could I vote for just merging it down, as-is? As far as I can tell,
this series was stalled for 6-7 months over "doesn't use
parse_options() API", even though Dscho addressed that directly in v1
in one of his commit messages stating he had already investigated that
route and found it wanting, at least in its current state[1]. It
appears, from my reading, that using parse_options() API was insisted
upon...though it turns out that making parse_options() capable of
handling such things is at least another 20-patch series[2] (which may
not be enough either[3]). Further, such changes, while likely
desirable for consistency among Git commands, would likely move us
away from "faithful conversion from shell to C", and thus is likely
better to be done as a separate step on top of the existing series
anyway[4].
If we merge down, as-is, then Ævar can go to town on it, possibly
using SZEDER's changes[2], and convert the new bisect code over to
using parse_options(), and show Dscho what he meant by how it could be
done. Maybe Ævar will even demonstrate that it is quite simple to do.
Or, perhaps, Ævar will discover what Dscho did and agree that
parse_options() really can't handle that case. I wouldn't be
surprised by either outcome. Either way, I think it'd resolve the
issue much faster than going round and round in discussions.
And I think the result would be more to everyone's liking -- Dscho
gets to concentrate on the stuff he cares about (user experience,
converting shell to C faithfully), and Ævar gets to concentrate on the
stuff he cares about (internal code consistency, tree-wide
refactorings). And in the meantime, the rest of us get to enjoy the
fruits of three separate GSoC projects plus Dscho's attempt to tie it
all together. I think Dscho's Dscho's submission improves upon
current Git and is good enough to merge, even if there may be ways to
make it even better.
Anyway, just my $0.02.
[1] https://lore.kernel.org/git/515e86e20758ed7f5b4a8ce8f38bfbbac27ec42a.1643328752.git.gitgitgadget@gmail.com/
[2] https://lore.kernel.org/git/20220812150420.GA3790@szeder.dev/
[3] https://lore.kernel.org/git/1p04q351-9938-r0r7-snr6-9s8237s27459@tzk.qr/
[4] https://lore.kernel.org/git/8o63pp64-4s00-1000-42s1-38so68398337@tzk.qr/
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: sy/mv-out-of-cone (was Re: What's cooking in git.git (Aug 2022, #05; Mon, 15))
2022-08-16 16:00 ` sy/mv-out-of-cone (was Re: What's cooking in git.git (Aug 2022, #05; Mon, 15)) Victoria Dye
2022-08-16 16:16 ` Junio C Hamano
@ 2022-08-17 2:03 ` Shaoxuan Yuan
1 sibling, 0 replies; 13+ messages in thread
From: Shaoxuan Yuan @ 2022-08-17 2:03 UTC (permalink / raw)
To: Victoria Dye, Junio C Hamano, git
On 8/17/2022 12:00 AM, Victoria Dye wrote:
> Junio C Hamano wrote:
>> * sy/mv-out-of-cone (2022-08-10) 9 commits
>> - mv: check overwrite for in-to-out move
>> - advice.h: add advise_on_moving_dirty_path()
>> - mv: cleanup empty WORKING_DIRECTORY
>> - mv: from in-cone to out-of-cone
>> - mv: remove BOTH from enum update_mode
>> - mv: check if <destination> is a SKIP_WORKTREE_DIR
>> - mv: free the with_slash in check_dir_in_index()
>> - mv: rename check_dir_in_index() to empty_dir_has_sparse_contents()
>> - t7002: add tests for moving from in-cone to out-of-cone
>>
>> "git mv A B" in a sparsely populated working tree can be asked to
>> move a path from a directory that is "in cone" to another directory
>> that is "out of cone". Handling of such a case has been improved.
>>
>> Will merge to 'next'?
>> source: <20220809120910.2021413-1-shaoxuan.yuan02@gmail.com>
>>
> After reviewing the latest version [1], I think this is ready for 'next'.
>
> [1] https://lore.kernel.org/git/52b67242-5d91-5406-9c95-9d8ddc49c079@github.com/
Thanks!
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: js/bisect-in-c, was Re: What's cooking in git.git (Aug 2022, #05; Mon, 15)
2022-08-17 1:26 ` Elijah Newren
@ 2022-08-17 6:27 ` Johannes Schindelin
2022-08-17 18:57 ` Junio C Hamano
1 sibling, 0 replies; 13+ messages in thread
From: Johannes Schindelin @ 2022-08-17 6:27 UTC (permalink / raw)
To: Elijah Newren; +Cc: Junio C Hamano, Git Mailing List
[-- Attachment #1: Type: text/plain, Size: 2998 bytes --]
Hi Elijah,
On Tue, 16 Aug 2022, Elijah Newren wrote:
> On Tue, Aug 16, 2022 at 3:49 AM Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
> >
> > On Mon, 15 Aug 2022, Junio C Hamano wrote:
> >
> > > * js/bisect-in-c (2022-06-27) 16 commits
> > > - bisect: no longer try to clean up left-over `.git/head-name` files
> > > - bisect: remove Cogito-related code
> > > - Turn `git bisect` into a full built-in
> > > - bisect: move even the command-line parsing to `bisect--helper`
> > > - bisect: teach the `bisect--helper` command to show the correct usage strings
> > > - bisect--helper: return only correct exit codes in `cmd_*()`
> > > - bisect--helper: move the `BISECT_STATE` case to the end
> > > - bisect--helper: make `--bisect-state` optional
> > > - bisect--helper: align the sub-command order with git-bisect.sh
> > > - bisect--helper: using `--bisect-state` without an argument is a bug
> > > - bisect--helper: really retire `--bisect-autostart`
> > > - bisect--helper: really retire --bisect-next-check
> > > - bisect--helper: retire the --no-log option
> > > - bisect: avoid double-quoting when printing the failed command
> > > - bisect run: fix the error message
> > > - bisect: verify that a bogus option won't try to start a bisection
> > >
> > > Final bits of "git bisect.sh" have been rewritten in C.
> > >
> > > Expecting a (hopefully final) reroll.
> > > cf. <20627.86ilolhnnn.gmgdl@evledraar.gmail.com>
>
> Junio: This link came up dead for me; I think the intended link was
> 220627.86ilolhnnn.gmgdl@evledraar.gmail.com ?
I had mentioned this in
https://lore.kernel.org/git/s3726r9p-r96o-7793-0qrq-o54rs4npr972@tzk.qr/
but failed to ask Junio to change it in the What's cooking mails. Thank
you for pointing it out, too.
> > > source: <pull.1132.v4.git.1656354677.gitgitgadget@gmail.com>
> >
> > I had another look at the thread and did not see any feedback that focuses
> > on the actual scope of the patch series. Conversions from scripted parts
> > of Git to built-ins are always a bit finicky (and hard to review, I
> > admit).
> >
> > Therefore I would like to move the status to "needs review".
> >
> > I do not think that there are any major issues with it (Ævar's feedback
> > notwithstanding, it focuses on tangents that should be addressed after the
> > conversion, to avoid losing focus), but I would love to see a thorough
> > review of the conversion to avoid obvious regressions like the one in the
> > built-in interactive `add` I had to fix recently.
>
> I reviewed it --
> https://lore.kernel.org/git/CABPp-BEOX+zxR9-yyx-EaiOV-Z9yD0YP_Kwvu4iGB8enz40XXQ@mail.gmail.com/.
> I looked over the subsequent iterations too, and they still look good
> to me.
Ooops. I am sorry for misrepresenting the situation. I honestly had
forgotten that the patch series did, in fact, receive a good and thorough
review.
My apologies and thank you so much for all your help!
Dscho
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: js/bisect-in-c, was Re: What's cooking in git.git (Aug 2022, #05; Mon, 15)
2022-08-17 1:26 ` Elijah Newren
2022-08-17 6:27 ` Johannes Schindelin
@ 2022-08-17 18:57 ` Junio C Hamano
2022-08-17 19:24 ` Elijah Newren
1 sibling, 1 reply; 13+ messages in thread
From: Junio C Hamano @ 2022-08-17 18:57 UTC (permalink / raw)
To: Elijah Newren; +Cc: Johannes Schindelin, Git Mailing List
Elijah Newren <newren@gmail.com> writes:
>> > Expecting a (hopefully final) reroll.
>> ...
>
> Could I vote for just merging it down, as-is? As far as I can tell,
> ... Further, such changes, while likely
> desirable for consistency among Git commands, would likely move us
> away from "faithful conversion from shell to C", and thus is likely
> better to be done as a separate step on top of the existing series
> anyway[4].
If this were a faithful conversion, yes, merging it right now can be
one good approach; add a faithful but not very C-like convesion
first and then make it "more like C code" later.
I however got an impression from the review discussion that it
subtly changes behaviour (IIRC, one thing pointed out was that exit
codes are now different from the original---there may or may not be
others, but my impression was they were all minor like the "exit
code" one).
My "hopefully final" comment was not about a big rearchitecting
change like use of parse-options API but about adjusting such minor
behaviour diversion so that we can say "This may not be very C-like,
and does not use much of our established API, but it is a fairly
faithful bug-to-bug compatible translation. Let's take it and make
it more like C incrementally". And of course, what was implied in
"hopefully final" was that such adjustments would be tiny, trivial
and can be done without much controversy. After all, I was aware
that the series was otherwise reviewed and received extensive
comments (sorry, I forgot that it was by you).
Thanks.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: js/bisect-in-c, was Re: What's cooking in git.git (Aug 2022, #05; Mon, 15)
2022-08-17 18:57 ` Junio C Hamano
@ 2022-08-17 19:24 ` Elijah Newren
2022-08-17 20:05 ` Junio C Hamano
0 siblings, 1 reply; 13+ messages in thread
From: Elijah Newren @ 2022-08-17 19:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Git Mailing List
On Wed, Aug 17, 2022 at 11:57 AM Junio C Hamano <gitster@pobox.com> wrote:
>
> Elijah Newren <newren@gmail.com> writes:
>
> >> > Expecting a (hopefully final) reroll.
> >> ...
> >
> > Could I vote for just merging it down, as-is? As far as I can tell,
> > ... Further, such changes, while likely
> > desirable for consistency among Git commands, would likely move us
> > away from "faithful conversion from shell to C", and thus is likely
> > better to be done as a separate step on top of the existing series
> > anyway[4].
>
> If this were a faithful conversion, yes, merging it right now can be
> one good approach; add a faithful but not very C-like convesion
> first and then make it "more like C code" later.
>
> I however got an impression from the review discussion that it
> subtly changes behaviour (IIRC, one thing pointed out was that exit
> codes are now different from the original---there may or may not be
> others, but my impression was they were all minor like the "exit
> code" one).
>
> My "hopefully final" comment was not about a big rearchitecting
> change like use of parse-options API but about adjusting such minor
> behaviour diversion so that we can say "This may not be very C-like,
> and does not use much of our established API, but it is a fairly
> faithful bug-to-bug compatible translation. Let's take it and make
> it more like C incrementally". And of course, what was implied in
> "hopefully final" was that such adjustments would be tiny, trivial
> and can be done without much controversy. After all, I was aware
> that the series was otherwise reviewed and received extensive
> comments (sorry, I forgot that it was by you).
>
> Thanks.
Ah, gotcha. My impression was that the exit codes did match what the
previous shell code had done, but didn't match what other builtins
usually return. Perhaps I misread those discussion comments.
Thanks for the clarification.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: js/bisect-in-c, was Re: What's cooking in git.git (Aug 2022, #05; Mon, 15)
2022-08-17 19:24 ` Elijah Newren
@ 2022-08-17 20:05 ` Junio C Hamano
2022-08-19 11:04 ` Johannes Schindelin
0 siblings, 1 reply; 13+ messages in thread
From: Junio C Hamano @ 2022-08-17 20:05 UTC (permalink / raw)
To: Elijah Newren; +Cc: Johannes Schindelin, Git Mailing List
Elijah Newren <newren@gmail.com> writes:
> Ah, gotcha. My impression was that the exit codes did match what the
> previous shell code had done, but didn't match what other builtins
> usually return. Perhaps I misread those discussion comments.
Or perhaps I did ;-)
The topic has been waiting for the finishing polish for so long that
I do not remember the details of the discussion offhand, certainly
not better than I did when I left the note in the "What's cooking"
report.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: js/bisect-in-c, was Re: What's cooking in git.git (Aug 2022, #05; Mon, 15)
2022-08-17 20:05 ` Junio C Hamano
@ 2022-08-19 11:04 ` Johannes Schindelin
2022-08-19 14:40 ` Ævar Arnfjörð Bjarmason
0 siblings, 1 reply; 13+ messages in thread
From: Johannes Schindelin @ 2022-08-19 11:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Elijah Newren, Git Mailing List
Hi Junio,
On Wed, 17 Aug 2022, Junio C Hamano wrote:
> Elijah Newren <newren@gmail.com> writes:
>
> > Ah, gotcha. My impression was that the exit codes did match what the
> > previous shell code had done, but didn't match what other builtins
> > usually return. Perhaps I misread those discussion comments.
>
> Or perhaps I did ;-)
The exit codes before and after this patch series are a red herring. The
_current_ code prints this when calling `git bisect start -h`:
$ git bisect start -h
usage: git bisect--helper --bisect-reset [<commit>]
or: git bisect--helper --bisect-terms [--term-good | --term-old | --term-bad | --term-new]
or: git bisect--helper --bisect-start [--term-{new,bad}=<term> --term-{old,good}=<term>] [--no-checkout] [--first-parent] [<bad> [<good>...]] [--] [<paths>...]
or: git bisect--helper --bisect-next
or: git bisect--helper --bisect-state (bad|new) [<rev>]
or: git bisect--helper --bisect-state (good|old) [<rev>...]
or: git bisect--helper --bisect-replay <filename>
or: git bisect--helper --bisect-skip [(<rev>|<range>)...]
or: git bisect--helper --bisect-visualize
or: git bisect--helper --bisect-run <cmd>...
--bisect-reset reset the bisection state
--bisect-next-check check whether bad or good terms exist
--bisect-terms print out the bisect terms
--bisect-start start the bisect session
--bisect-next find the next bisection commit
--bisect-state mark the state of ref (or refs)
--bisect-log list the bisection steps so far
--bisect-replay replay the bisection process from the given file
--bisect-skip skip some commits for checkout
--bisect-visualize visualize the bisection
--bisect-run use <cmd>... to automatically bisect
--no-log no log for BISECT_WRITE
Notice how this talks about `bisect--helper` and about `--bisect-reset`.
Also, the _current_ code exits with code 0 when calling `git bisect -h`.
This has been the case even as far back as v2.25.1, and possibly even
longer.
Given these issues, I was mistakenly assuming that it would be okay to
postpone these problems that are exclusively related to incorrect
invocation of `git bisect`, and that it would make sense to focus on the
conversion from shell code to C in _this_ patch series, and take care of
these problems afterwards, instead of hodgepodging fixes for them into the
same patch series as the conversion to C, the latter being hard enough to
review as it stands, so much so that it received only a single high
quality review.
But I see that you somehow got the idea that the review that lacked
attention to the common code path somehow was a valid review and you
somehow got it in your mind that this was valid feedback and that the
patch series needs to be reworked so that it _also_ addresses issues that
have been broken _before_ it.
Fine.
I'll try to get to it next week. It does leave a foul taste that we're not
separating concerns properly in the Git project, but block a patch series
that has a specific, already large scope, just because one reviewer wants
it to have another scope and for some reason that now must be the scope of
the patch series.
Ciao,
Dscho
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: js/bisect-in-c, was Re: What's cooking in git.git (Aug 2022, #05; Mon, 15)
2022-08-19 11:04 ` Johannes Schindelin
@ 2022-08-19 14:40 ` Ævar Arnfjörð Bjarmason
0 siblings, 0 replies; 13+ messages in thread
From: Ævar Arnfjörð Bjarmason @ 2022-08-19 14:40 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Elijah Newren, Git Mailing List
On Fri, Aug 19 2022, Johannes Schindelin wrote:
> Hi Junio,
>
> On Wed, 17 Aug 2022, Junio C Hamano wrote:
>
>> Elijah Newren <newren@gmail.com> writes:
>>
>> > Ah, gotcha. My impression was that the exit codes did match what the
>> > previous shell code had done, but didn't match what other builtins
>> > usually return. Perhaps I misread those discussion comments.
>>
>> Or perhaps I did ;-)
>
> The exit codes before and after this patch series are a red herring. The
> _current_ code prints this when calling `git bisect start -h`:
>
> $ git bisect start -h
> usage: git bisect--helper --bisect-reset [<commit>]
> or: git bisect--helper --bisect-terms [--term-good | --term-old | --term-bad | --term-new]
> or: git bisect--helper --bisect-start [--term-{new,bad}=<term> --term-{old,good}=<term>] [--no-checkout] [--first-parent] [<bad> [<good>...]] [--] [<paths>...]
> or: git bisect--helper --bisect-next
> or: git bisect--helper --bisect-state (bad|new) [<rev>]
> or: git bisect--helper --bisect-state (good|old) [<rev>...]
> or: git bisect--helper --bisect-replay <filename>
> or: git bisect--helper --bisect-skip [(<rev>|<range>)...]
> or: git bisect--helper --bisect-visualize
> or: git bisect--helper --bisect-run <cmd>...
>
> --bisect-reset reset the bisection state
> --bisect-next-check check whether bad or good terms exist
> --bisect-terms print out the bisect terms
> --bisect-start start the bisect session
> --bisect-next find the next bisection commit
> --bisect-state mark the state of ref (or refs)
> --bisect-log list the bisection steps so far
> --bisect-replay replay the bisection process from the given file
> --bisect-skip skip some commits for checkout
> --bisect-visualize visualize the bisection
> --bisect-run use <cmd>... to automatically bisect
> --no-log no log for BISECT_WRITE
>
> Notice how this talks about `bisect--helper` and about `--bisect-reset`.
>
> Also, the _current_ code exits with code 0 when calling `git bisect -h`.
>
> This has been the case even as far back as v2.25.1, and possibly even
> longer.
>
> Given these issues, I was mistakenly assuming that it would be okay to
> postpone these problems that are exclusively related to incorrect
> invocation of `git bisect`, and that it would make sense to focus on the
> conversion from shell code to C in _this_ patch series, and take care of
> these problems afterwards, instead of hodgepodging fixes for them into the
> same patch series as the conversion to C, the latter being hard enough to
> review as it stands, so much so that it received only a single high
> quality review.
>
> But I see that you somehow got the idea that the review that lacked
> attention to the common code path somehow was a valid review and you
> somehow got it in your mind that this was valid feedback and that the
> patch series needs to be reworked so that it _also_ addresses issues that
> have been broken _before_ it.
I really think these remarks about "high quality review" and "the review
that lacked attention" are overly snide and don't contribute to a
friendly ML atmosphere.
We can all be wrong about stuff, e.g. [1] is one very recent case where
I just plain misread something in a review. But can we just ask for a
clarification etc?
In this case I fully agree with you that any existing issues in the
conversion of bisect to C should be out of scope for your series, but
that's not what your series is doing.
I've specifically been pointing out issues where the behavior is changed
as a result.
For example, on "master" (and there's a lot more of these):
$ ./git --exec-path=$PWD bisect terms a b c; echo $?
error: --bisect-terms requires 0 or 1 argument
255
On "seen", with your series:
$ ./git --exec-path=$PWD bisect terms a b c; echo $?
fatal: 'terms' requires 0 or 1 argument
128
That's one of the things I pointed out to you, and clearly a behavior
change in both the exit code emitted, and the message emitted.
I don't think it's unacceptable to have some behavior change as we
migrate to the C version.
I'd just pointed out cases where that either seemed unnecessary, or
migrated to some unusual pattern. E.g in the case of exiting with code
128 instead of 129 on usage errors, as we usually do.
> I'll try to get to it next week. It does leave a foul taste that we're not
> separating concerns properly in the Git project, but block a patch series
> that has a specific, already large scope, just because one reviewer wants
> it to have another scope and for some reason that now must be the scope of
> the patch series.
I'd really like you to find and quote back to me somewhere I've
attempted to "block" these patches, or anything of the kind. That's
simply not true.
If you had actually asked: Aside from any outstanding issues with your
series, I think as it stands that it's a net improvement on "master". I
would not mind it advanced in its current state. We can fix any
outstanding issues with it later, particularly due to what seem like
time constraints on your end, and how unproductive reviewing it seems to
be getting.
I think the only thing I've said which could be construed as "blocking"
this series has been:
* In
https://lore.kernel.org/git/220627.86mtdxhnwk.gmgdl@evledraar.gmail.com/
noting (and I'm paraphrasing here) that I couldn't in good conscience
give it something like my Reviewed-by due to the various behavior
changes it introduces, *and* the fact that large parts of the bisect
interface it touches are completely untested.
Now, of course "untested" is an existing issue, but I think it's fair
to point that out when a series proposes to refactor some code that
it's doing so on an interface that's not well tested, to the point
that you can remove at least one "bisect" sub-command entirely and
have the test suite still pass.
* Pointing out specific bugs etc, as above.
* In these "js/bisect-in-c" threads noting the outstanding issues with
it, particularly as I think your own summaries have been.
I don't see how you your remark that you "did not see any feedback
that focuses on the actual scope of the patch series" in [2] with
e.g. claim above that this behavior was "broken _before_ it" as
anything except contradictory.
If your own summaries were something to the effect that no major issues
had been raised, that you didn't have time to re-roll it, and could it
either be picked up as-is or could others propose fix-ups on top I
really wouldn't mind, or see any reason to comment in these threads.
1. https://lore.kernel.org/git/220819.86a6817xyw.gmgdl@evledraar.gmail.com/
2. https://lore.kernel.org/git/p053rrpq-17q7-pnrs-3794-o04ro1445s5s@tzk.qr/
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2022-08-19 15:11 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-08-15 21:24 What's cooking in git.git (Aug 2022, #05; Mon, 15) Junio C Hamano
2022-08-16 8:56 ` js/bisect-in-c, was " Johannes Schindelin
2022-08-17 1:26 ` Elijah Newren
2022-08-17 6:27 ` Johannes Schindelin
2022-08-17 18:57 ` Junio C Hamano
2022-08-17 19:24 ` Elijah Newren
2022-08-17 20:05 ` Junio C Hamano
2022-08-19 11:04 ` Johannes Schindelin
2022-08-19 14:40 ` Ævar Arnfjörð Bjarmason
2022-08-16 16:00 ` sy/mv-out-of-cone (was Re: What's cooking in git.git (Aug 2022, #05; Mon, 15)) Victoria Dye
2022-08-16 16:16 ` Junio C Hamano
2022-08-17 2:03 ` Shaoxuan Yuan
2022-08-17 0:36 ` cw/submodule-merge-messages (Was: " Elijah Newren
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).