{"thread":{"id":"56998","subject":"What's cooking in git.git (Nov 2021, #07; Mon, 29)","startedAt":"2021-11-30T02:17:03Z","lastAt":"2021-12-07T01:59:05Z","messageCount":42,"participants":["Junio C Hamano","Jeff King","brian m. carlson","Ævar Arnfjörð Bjarmason","Eric Sunshine","Elijah Newren","Aleen 徐沛文","Fabian Stelzer","Victoria Dye","Neeraj Singh","Phillip Wood"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"442593","messageId":"xmqqzgpm2xrd.fsf@gitster.g","threadId":"56998","inReplyTo":null,"subject":"What's cooking in git.git (Nov 2021, #07; Mon, 29)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-11-30T02:16:54Z","receivedAt":"2021-11-30T02:17:03Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"As promised, most of the topics that have been cooking in 'next'\nsince the previous release cycle have been merged to 'master' to\nstart a new cycle, with a small exception.  The tip of 'next' has\nbeen rewound and there is 0 topics on it right now.\n\nThe exception is 'ns/tmp-objdir' and a few topics that depend on it,\nwhich are kicked out of 'next' to give the base topic a chance to\nlose the two \"fixup!\" band-aid.  Careful re-reading of the topic by\nsomebody with a fresh set of eyes (meaning, everybody, as this has\nbeen dormant for almost a month) is very much appreciated to move\nthings forward.  Also ns/remerge-diff that is Neeraj's rebase of the\nremerge-diff topic needs Elijah's Ack at least.\n\nMany of the new patches in 'seen' since the last cycle ended are\ntruly 'just seen' and not 'read' at all, as you can see from the\nlack of any topic description to speak of in the following list.\nHelp is appreciated here, too.  Before whipping them into some\npresentable shape, I wouldn't be able to take any more new topics.\n\n\n\n\n\nHere are the topics that have been cooking in my tree.  Commits\nprefixed with '+' are in 'next' (being in 'next' is a sign that a\ntopic is stable enough to be used and are candidate to be in a\nfuture release).  Commits prefixed with '-' are only in 'seen',\nwhich means nothing more than that I have found them of interest for\nsome reason (like \"it may have hard-to-resolve conflicts with\nanother topic already in flight\" or \"this may turn out to be\nuseful\").  Do not read too much into a topic being in (or not in)\n'seen'.  The ones marked with '.' do not appear in any of the\nintegration branches, but I am still holding onto them.\n\nA few topics for regression fixes have been merged to 'next' and\nwill be merged to 'master' shortly.  There are many topics listed as\n\"New\" that are in 'seen', but I haven't read many of them (and I\nshouldn't have anyway, before dealing with regression fixes) and\nhaven't gave any summary comments in this report, either, yet.\n\nCopies of the source code to Git live in many repositories, and the\nfollowing is a list of the ones I push into or their mirrors.  Some\nrepositories have only a subset of branches.\n\nWith maint, master, next, seen, todo:\n\n\tgit://git.kernel.org/pub/scm/git/git.git/\n\tgit://repo.or.cz/alt-git.git/\n\thttps://kernel.googlesource.com/pub/scm/git/git/\n\thttps://github.com/git/git/\n\thttps://gitlab.com/git-vcs/git/\n\nWith all the integration branches and topics broken out:\n\n\thttps://github.com/gitster/git/\n\nEven though the preformatted documentation in HTML and man format\nare not sources, they are published in these repositories for\nconvenience (replace \"htmldocs\" with \"manpages\" for the manual\npages):\n\n\tgit://git.kernel.org/pub/scm/git/git-htmldocs.git/\n\thttps://github.com/gitster/git-htmldocs.git/\n\nRelease tarballs are available at:\n\n\thttps://www.kernel.org/pub/software/scm/git/\n\n--------------------------------------------------\n[Graduated to 'master']\n\n* ab/refs-errno-cleanup (2021-10-16) 21 commits\n  (merged to 'next' on 2021-10-29 at 3f57147176)\n + refs API: post-migration API renaming [2/2]\n + refs API: post-migration API renaming [1/2]\n + refs API: don't expose \"errno\" in run_transaction_hook()\n + refs API: make expand_ref() & repo_dwim_log() not set errno\n + refs API: make resolve_ref_unsafe() not set errno\n + refs API: make refs_ref_exists() not set errno\n + refs API: make refs_resolve_refdup() not set errno\n + refs tests: ignore ignore errno in test-ref-store helper\n + refs API: ignore errno in worktree.c's find_shared_symref()\n + refs API: ignore errno in worktree.c's add_head_info()\n + refs API: make files_copy_or_rename_ref() et al not set errno\n + refs API: make loose_fill_ref_dir() not set errno\n + refs API: make resolve_gitlink_ref() not set errno\n + refs API: remove refs_read_ref_full() wrapper\n + refs/files: remove \"name exist?\" check in lock_ref_oid_basic()\n + reflog tests: add --updateref tests\n + refs API: make refs_rename_ref_available() static\n + refs API: make parse_loose_ref_contents() not set errno\n + refs API: make refs_read_raw_ref() not set errno\n + refs API: add a version of refs_resolve_ref_unsafe() with \"errno\"\n + branch tests: test for errno propagating on failing read\n\n The \"remainder\" of hn/refs-errno-cleanup topic.\n\n\n* ab/sh-retire-helper-functions (2021-10-21) 6 commits\n  (merged to 'next' on 2021-11-03 at 4b49d9f4be)\n + git-sh-setup: remove \"sane_grep\", it's not needed anymore\n + git-sh-setup: remove unused sane_egrep() function\n + git-instaweb: unconditionally assume that gitweb is mod_perl capable\n + Makefile: remove $(NO_CURL) from $(SCRIPT_DEFINES)\n + Makefile: remove $(GIT_VERSION) from $(SCRIPT_DEFINES)\n + Makefile: move git-SCRIPT-DEFINES adjacent to $(SCRIPT_DEFINES)\n (this branch is used by ab/make-dependency.)\n\n Make a few helper functions unused and then lose them.\n\n\n* jc/fix-ref-sorting-parse (2021-10-20) 2 commits\n  (merged to 'next' on 2021-10-29 at e3ec6e8e77)\n + for-each-ref: delay parsing of --sort=<atom> options\n + Merge branch 'ab/ref-filter-leakfix' into jc/fix-ref-sorting-parse\n\n Things like \"git -c branch.sort=bogus branch new HEAD\", i.e. the\n operation modes of the \"git branch\" command that do not need the\n sort key information, no longer errors out by seeing a bogus sort\n key.\n\n\n* jc/tutorial-format-patch-base (2021-10-23) 1 commit\n  (merged to 'next' on 2021-10-29 at 67ff1a5a77)\n + MyFirstContribution: teach to use \"format-patch --base=auto\"\n\n Teach and encourage first-time contributors to this project to\n state the base commit when they submit their topic.\n\n\n* jc/unsetenv-returns-an-int (2021-10-29) 1 commit\n  (merged to 'next' on 2021-11-01 at a11670a5a5)\n + unsetenv(3) returns int, not void\n\n The compatibility implementation for unsetenv(3) were written to\n mimic ancient, non-POSIX, variant seen in an old glibc; it has been\n changed to return an integer to match the more modern era.\n\n\n* jk/loosen-urlmatch (2021-10-12) 1 commit\n  (merged to 'next' on 2021-10-25 at f66ca39ebe)\n + urlmatch: add underscore to URL_HOST_CHARS\n\n Treat \"_\" as any other URL-valid characters in an URL when matching\n the per-URL configuration variable names.\n\n\n* mc/clean-smudge-with-llp64 (2021-11-03) 8 commits\n  (merged to 'next' on 2021-11-03 at fe5160a170)\n + clean/smudge: allow clean filters to process extremely large files\n + odb: guard against data loss checking out a huge file\n + git-compat-util: introduce more size_t helpers\n + odb: teach read_blob_entry to use size_t\n + t1051: introduce a smudge filter test for extremely large files\n + test-lib: add prerequisite for 64-bit platforms\n + test-tool genzeros: generate large amounts of data more efficiently\n + test-genzeros: allow more than 2G zeros in Windows\n\n The clean/smudge conversion code path has been prepared to better\n work on platforms where ulong is narrower than size_t.\n\n\n* ow/stash-count-in-status-porcelain-output (2021-10-21) 2 commits\n  (merged to 'next' on 2021-10-29 at 1a01b886e5)\n + status: print stash info with --porcelain=v2 --show-stash\n + status: count stash entries in separate function\n\n Allow \"git status --porcelain=v2\" to show the number of stash\n entries with --show-stash like the normal output does.\n\n\n* so/stash-staged (2021-10-28) 2 commits\n  (merged to 'next' on 2021-10-29 at 50335e8eeb)\n + stash: get rid of unused argument in stash_staged()\n  (merged to 'next' on 2021-10-25 at 68b88e35c4)\n + stash: implement '--staged' option for 'push' and 'save'\n\n \"git stash\" learned the \"--staged\" option to stash away what has\n been added to the index (and nothing else).\n\n\n* tb/plug-pack-bitmap-leaks (2021-10-28) 9 commits\n  (merged to 'next' on 2021-11-01 at 47d218862b)\n + pack-bitmap.c: more aggressively free in free_bitmap_index()\n + pack-bitmap.c: don't leak type-level bitmaps\n + midx.c: write MIDX filenames to strbuf\n + builtin/multi-pack-index.c: don't leak concatenated options\n + builtin/repack.c: avoid leaking child arguments\n + builtin/pack-objects.c: don't leak memory via arguments\n + t/helper/test-read-midx.c: free MIDX within read_midx_file()\n + midx.c: don't leak MIDX from verify_midx_file\n + midx.c: clean up chunkfile after reading the MIDX\n\n Leakfix.\n\n\n* tp/send-email-completion (2021-10-28) 2 commits\n  (merged to 'next' on 2021-11-01 at 7104356cc0)\n + send-email docs: add format-patch options\n + send-email: programmatically generate bash completions\n\n The command line complation for \"git send-email\" options have been\n tweaked to make it easier to keep it in sync with the command itself.\n\n--------------------------------------------------\n[New Topics]\n\n* ab/ambiguous-object-name (2021-11-26) 6 commits\n - object-name: re-use \"struct strbuf\" in show_ambiguous_object()\n - object-name: iterate ambiguous objects before showing header\n - object-name: show date for ambiguous tag objects\n - object-name: make ambiguous object output translatable\n - object-name: explicitly handle OBJ_BAD in show_ambiguous_object()\n - object-name tests: add tests for ambiguous object blind spots\n\n\n* cb/add-p-single-key-fix (2021-11-28) 1 commit\n - add -p: avoid use of undefined $key when ReadKey -> EOF\n\n\n* cb/mingw-gmtime-r (2021-11-27) 1 commit\n - mingw: avoid fallback for {local,gm}time_r()\n\n\n* ds/trace2-regions-in-tests (2021-11-29) 2 commits\n - t/t*: remove custom GIT_TRACE2_EVENT_NESTING\n - test-lib.sh: set GIT_TRACE2_EVENT_NESTING\n\n\n* hn/allow-bogus-oid-in-ref-tests (2021-11-29) 6 commits\n - t1430: create valid symrefs using test-helper\n - t1430: remove refs using test-tool\n - refs: add REF_SKIP_REFNAME_VERIFICATION flag\n - refs: allow skipping OID verification\n - refs: update comment.\n - test-ref-store: plug memory leak in cmd_delete_refs\n\n\n* hn/t1404-df-limitation-is-ref-files-only (2021-11-29) 1 commit\n - t1404: mark directory/file conflict tests with REFFILES\n\n\n* jc/reflog-iterator-callback-doc (2021-11-28) 1 commit\n - refs: document callback for reflog-ent iterators\n\n\n* po/size-t-for-vs (2021-11-26) 3 commits\n - object-file.c: LLP64 compatibility, upcast unity for left shift\n - diffcore-delta.c: LLP64 compatibility, upcast unity for left shift\n - repack.c: LLP64 compatibility, upcast unity for left shift\n\n\n* yn/complete-date-format-options (2021-11-25) 1 commit\n - completion: add human and auto: date format\n\n\n* jc/grep-patterntype-default-doc (2021-11-29) 1 commit\n - grep: clarify what `grep.patternType=default` means\n\n--------------------------------------------------\n[Stalled]\n\n* ar/submodule-update (2021-10-13) 9 commits\n . submodule--helper: rename helper functions\n . submodule--helper: remove unused helpers\n . submodule: move core cmd_update() logic to C\n . submodule--helper: run update using child process struct\n . submodule--helper: allow setting superprefix for init_submodule()\n . submodule--helper: refactor get_submodule_displaypath()\n . submodule--helper: rename helpers for update-clone\n . submodule--helper: get remote names from any repository\n . submodule--helper: split up ensure_core_worktree()\n\n Rewrite of \"git submodule update\" in C.\n\n Kicked out of 'seen' to make room for es/superproject-aware-submodules\n which is among the topics this topic stomps on.\n\n\n* cf/fetch-set-upstream-while-detached (2021-07-06) 1 commit\n - fetch: fix segfault on --set-upstream while on a detached HEAD\n\n \"git fetch --set-upstream\" while on detached HEAD segfaulted\n instead of noticing that such an operation did not make sense.\n\n Getting tired of waiting for a reroll; will discard.\n\n--------------------------------------------------\n[Cooking]\n\n* ab/ci-updates (2021-11-23) 5 commits\n - CI: don't run \"make test\" twice in one job\n - CI: use \"$runs_on_pool\", not \"$jobname\" to select packages & config\n - CI: rename the \"Linux32\" job to lower-case \"linux32\"\n - CI: use shorter names that fit in UX tooltips\n - CI: remove Travis CI support\n\n Drop support for TravisCI and update test workflows at GitHub.\n\n\n* en/keep-cwd (2021-11-29) 11 commits\n - t2501: simplify the tests since we can now assume desired behavior\n - dir: new flag to remove_dir_recurse() to spare the original_cwd\n - dir: avoid incidentally removing the original_cwd in remove_path()\n - stash: do not attempt to remove startup_info->original_cwd\n - rebase: do not attempt to remove startup_info->original_cwd\n - clean: do not attempt to remove startup_info->original_cwd\n - symlinks: do not include startup_info->original_cwd in dir removal\n - unpack-trees: add special cwd handling\n - unpack-trees: refuse to remove startup_info->original_cwd\n - setup: introduce startup_info->original_cwd\n - t2501: add various tests for removing the current working directory\n\n\n* ab/run-command (2021-11-25) 9 commits\n - run-command API: remove \"env\" member, always use \"env_array\"\n - difftool: use \"env_array\" to simplify memory management\n - run-command API: remove \"argv\" member, always use \"args\"\n - run-command API users: use strvec_push(), not argv construction\n - run-command API users: use strvec_pushl(), not argv construction\n - run-command tests: use strvec_pushv(), not argv assignment\n - run-command API users: use strvec_pushv(), not argv assignment\n - upload-archive: use regular \"struct child_process\" pattern\n - worktree: stop being overly intimate with run_command() internals\n\n\n* hn/create-reflog-simplify (2021-11-22) 1 commit\n - refs: drop force_create argument of create_reflog API\n\n A small simplification of API.\n\n Will merge to 'next'.\n\n\n* hn/reflog-tests (2021-11-25) 5 commits\n - refs/debug: trim trailing LF from reflog message\n - test-ref-store: tweaks to for-each-reflog-ent format\n - t1405: check for_each_reflog_ent_reverse() more thoroughly\n - test-ref-store: don't add newline to reflog message\n - show-branch: show reflog message\n\n Prepare tests on ref API to help testing reftable backends.\n\n\n* jt/midx-doc-fix (2021-11-22) 1 commit\n - Doc: no midx and partial clone relation\n\n Docfix.\n\n Will merge to 'next'.\n\n\n* tl/ls-tree-oid-only (2021-11-22) 1 commit\n - ls-tree.c: support `--oid-only` option for \"git-ls-tree\"\n\n \"git ls-tree\" learns \"--oid-only\" option, similar to \"--name-only\".\n\n Expecting a reroll.\n\n\n* jk/t7006-sigpipe-tests-fix (2021-11-22) 3 commits\n - t7006: simplify exit-code checks for sigpipe tests\n - t7006: clean up SIGPIPE handling in trace2 tests\n - run-command: unify signal and regular logic for wait_or_whine()\n\n The function to cull a child process and determine the exit status\n had two separate code paths for normal callers and callers in a\n signal handler, and the latter did not yield correct value when the\n child has caught a signal.  The handling of the exit status has\n been unified for these two code paths.  An existing test with\n flakiness has also been corrected.\n\n Will merge to 'next'.\n\n\n* em/missing-pager (2021-11-24) 1 commit\n - pager: fix crash when pager program doesn't exist\n\n\n* ab/checkout-branch-info-leakfix (2021-11-18) 1 commit\n - checkout: fix \"branch info\" memory leaks\n\n Leakfix.\n\n Will merge to 'next'.\n\n\n* ab/make-dependency (2021-11-18) 24 commits\n - Makefile: move \".SUFFIXES\" rule to shared.mak\n - Makefile: define $(LIB_H) in terms of $(FIND_SOURCE_FILES)\n - Makefile: disable GNU make built-in wildcard rules\n - Makefile: use $(file) I/O instead of \"FORCE\" when possible\n - Makefile: correct the dependency graph of hook-list.h\n - Makefiles: add and use wildcard \"mkdir -p\" template\n - Makefile: use $(wspfx) for $(QUIET...) in shared.mak\n - Makefile: add \"$(QUIET)\" boilerplate to shared.mak\n - Makefile: add a \"TRACK_template\" for GIT-*{FLAGS,DEFINES,...}\n - Makefile: re-add and use the \"shellquote\" macros\n - Makefile: move $(comma), $(empty) and $(space) to shared.mak\n - Makefiles: add \"shared.mak\", move \".DELETE_ON_ERROR\" to it\n - Makefile: stop needing @@GIT_VERSION@@ in *.perl scripts\n - Makefile: create a GIT-PYTHON-DEFINES, like \"PERL\"\n - Makefile: correct \"GIT-PERL-{DEFINES,HEADER}\" dependency graph\n - Makefile: adjust Perl-related comments & whitespace\n - Makefile: change \"ifndef NO_PERL\" to \"ifdef NO_PERL\"\n - Makefile: guard Perl-only variable assignments\n - Makefile: remove \"mv $@ $@+\" dance redundant to .DELETE_ON_ERROR\n - Makefile: clean perl/build/ even with NO_PERL=Y\n - Makefile: use \"=\" not \":=\" for po/* and perl/*\n - Makefile: don't set up \"perl/build\" rules under NO_PERL=Y\n - Makefile: don't invoke msgfmt with --statistics\n - Merge branch 'ab/sh-retire-helper-functions' into ab/make-dependency\n\n Dependency clean-up.\n\n\n* ah/advice-pull-has-no-preference-between-rebase-and-merge (2021-11-19) 1 commit\n - pull: don't say that merge is \"the default strategy\"\n\n The advice message given by \"git pull\" when the user hasn't made a\n choice between merge and rebase still said that the merge is the\n default, which no longer is the case.  This has been corrected.\n\n Will merge to 'next'.\n\n\n* ds/fetch-pull-with-sparse-index (2021-11-29) 3 commits\n - ls-files: add --sparse option\n - fetch/pull: use the sparse index\n - Merge branch 'ld/sparse-diff-blame' into ds/fetch-pull-with-sparse-index\n (this branch uses ld/sparse-diff-blame and vd/sparse-reset.)\n\n\n* fs/ssh-signing-other-keytypes (2021-11-19) 2 commits\n - ssh signing: make sign/amend test more resilient\n - ssh signing: support non ssh-* keytypes\n\n\n* fs/test-prereq (2021-11-20) 3 commits\n - test-lib: make BAIL_OUT() work in tests and prereq\n - test-lib: introduce required prereq for test runs\n - test-lib: show missing prereq summary\n\n The test framework learns to list unsatisfied test prerequisites,\n and optionally error out when prerequisites that are expected to be\n satisfied are not.\n\n Will merge to 'next'?\n\n\n* jk/t5319-midx-corruption-test-deflake (2021-11-18) 1 commit\n - t5319: corrupt more bytes of the midx checksum\n\n Test fix.\n\n Will merge to 'next'.\n\n\n* js/trace2-avoid-recursive-errors (2021-11-18) 1 commit\n - trace2: disable tr2_dst before warning on write errors\n\n trace2 error code path fix.\n\n Will merge to 'next'.\n\n\n* pw/xdiff-classify-record-in-histogram (2021-11-18) 3 commits\n - xdiff: simplify comparison\n - xdiff: avoid unnecessary memory allocations\n - diff histogram: intern strings\n\n \"diff --histogram\" optimization.\n\n Will merge to 'next'.\n\n\n* rs/mergesort (2021-11-18) 1 commit\n - mergesort: avoid left shift overflow\n\n Bitop fix for platforms whose \"long\" is 32-bit.\n\n Will merge to 'next'.\n\n\n* xw/am-empty (2021-11-22) 2 commits\n - am: support --empty=<option> to handle empty patches\n - doc: git-format-patch: describe the option --always\n\n \"git am\" learns \"--empty=(die|drop|keep)\" option to tweak what is\n done to a piece of e-mail without a patch in it.\n\n Will merge to 'next'.\n\n\n* hk/ci-checkwhitespace-commentfix (2021-11-19) 1 commit\n - ci(check-whitespace): update stale file top comments\n\n Comment fix.\n\n Will merge to 'next'.\n\n\n* jk/fetch-pack-avoid-sigpipe-to-index-pack (2021-11-19) 1 commit\n - fetch-pack: ignore SIGPIPE when writing to index-pack\n\n \"git fetch\", when received a bad packfile, can fail with SIGPIPE.\n This wasn't wrong per-se, but we now detect the situation and fail\n in a more predictable way.\n\n Will merge to 'next'.\n\n\n* jk/refs-g11-workaround (2021-11-19) 1 commit\n - refs: work around gcc-11 warning with REF_HAVE_NEW\n\n Workaround for a false-alarm by gcc-11\n\n Will merge to 'next'.\n\n\n* mp/absorb-submodule-git-dir-upon-deinit (2021-11-19) 1 commit\n - submodule: absorb git dir instead of dying on deinit\n\n \"git submodule deinit\" for a submodule whose .git metadata\n directory is embedded in its working tree refused to work, until\n the submodule gets converted to use the \"absorbed\" form where the\n metadata directory is stored in superproject, and a gitfile at the\n top-level of the working tree of the submodule points at it.  The\n command is taught to convert such submodules to the absorbed form\n as needed.\n\n Will merge to 'next'?\n\n\n* rj/receive-pack-avoid-sigpipe-during-status-reporting (2021-11-10) 1 commit\n - receive-pack: ignore SIGPIPE while reporting status to client\n\n When the \"git push\" command is killed while the receiving end is\n trying to report what happened to the ref update proposals, the\n latter used to die, due to SIGPIPE.  The code now ignores SIGPIPE\n to increase our chances to run the post-receive hook after it\n happens.\n\n Will merge to 'next'?\n\n\n* ab/parse-options-cleanup (2021-11-10) 1 commit\n - parse-options.c: use \"enum parse_opt_result\" for parse_nodash_opt()\n\n Change the type of an internal function to return an enum (instead\n of int) and replace -2 that was used to signal an error with -1.\n\n\n* cw/protocol-v2-doc-fix (2021-11-11) 1 commit\n - protocol-v2.txt: align delim-pkt spec with usage\n\n Doc update.\n\n Will merge to 'next'.\n\n\n* jt/pack-header-lshift-overflow (2021-11-11) 1 commit\n - packfile: avoid overflowing shift during decode\n\n The code to decode the length of packed object size has been\n corrected.\n\n Will merge to 'next'.\n\n\n* bc/require-c99 (2021-11-18) 1 commit\n . git-compat-util: add a test balloon for C99 support\n\n Weather balloon to break people with compilers that do not support\n C99.\n\n Expecting a reroll.\n\n\n* jc/c99-var-decl-in-for-loop (2021-11-22) 1 commit\n - revision: use C99 declaration of variable in for() loop\n\n Weather balloon to break compilers that do not grok variable\n declaration in the for() loop.\n\n Will merge to 'next'?\n\n\n* tl/midx-docfix (2021-11-18) 1 commit\n - midx: fix a formatting issue in \"multi-pack-index.txt\"\n\n Doc mark-up fix.\n\n Will merge to 'next'.\n\n\n* ak/protect-any-current-branch (2021-11-15) 8 commits\n - branch: protect branches checked out in all worktrees\n - receive-pack: protect current branch for bare repository worktree\n - receive-pack: clean dead code from update_worktree()\n - fetch: protect branches checked out in all worktrees\n - worktree: simplify find_shared_symref() memory ownership model\n - branch: lowercase error messages\n - receive-pack: lowercase error messages\n - fetch: lowercase error messages\n\n \"git fetch\" without the \"--update-head-ok\" option ought to protect\n a checked out branch from getting updated, to prevent the working\n tree that checks it out to go out of sync.  The code was written\n before the use of \"git worktree\" got widespread, and only checked\n the branch that was checked out in the current worktree, which has\n been updated.\n (originally called ak/fetch-not-overwrite-any-current-branch)\n\n Will merge to 'next'?\n\n\n* jk/test-bitmap-fix (2021-11-05) 1 commit\n - test_bitmap_hashes(): handle repository without bitmaps\n\n Tighten code for testing pack-bitmap.\n\n Will merge to 'next'.\n\n\n* jk/jump-merge-with-pathspec (2021-11-09) 1 commit\n - git-jump: pass \"merge\" arguments to ls-files\n\n The \"merge\" subcommand of \"git jump\" (in contrib/) silently ignored\n pathspec and other parameters.\n\n Will merge to 'next'.\n\n\n* jk/strbuf-addftime-seconds-since-epoch (2021-11-04) 1 commit\n - strbuf_addftime(): handle \"%s\" manually\n\n The \"--date=format:<strftime>\" gained a workaround for the lack of\n system support for a non-local timezone to handle \"%s\" placeholder.\n\n Will merge to 'next'.\n\n\n* js/ci-no-directional-formatting (2021-11-04) 1 commit\n - ci: disallow directional formatting\n\n CI has been taught to catch some Unicode directional formatting\n sequence that can be used in certain mischief.\n\n Will merge to 'next'.\n\n\n* tw/var-default-branch (2021-11-03) 1 commit\n - var: add GIT_DEFAULT_BRANCH variable\n\n \"git var GIT_DEFAULT_BRANCH\" is a way to see what name is used for\n the newly created branch if \"git init\" is run.\n\n Will merge to 'next'.\n\n\n* ab/mark-leak-free-tests-even-more (2021-11-01) 15 commits\n - leak tests: mark some fast-import tests as passing with SANITIZE=leak\n - leak tests: mark some config tests as passing with SANITIZE=leak\n - leak tests: mark some status tests as passing with SANITIZE=leak\n - leak tests: mark some clone tests as passing with SANITIZE=leak\n - leak tests: mark some add tests as passing with SANITIZE=leak\n - leak tests: mark some diff tests as passing with SANITIZE=leak\n - leak tests: mark some apply tests as passing with SANITIZE=leak\n - leak tests: mark some notes tests as passing with SANITIZE=leak\n - leak tests: mark some update-index tests as passing with SANITIZE=leak\n - leak tests: mark some rev-parse tests as passing with SANITIZE=leak\n - leak tests: mark some rev-list tests as passing with SANITIZE=leak\n - leak tests: mark some misc tests as passing with SANITIZE=leak\n - leak tests: mark most gettext tests as passing with SANITIZE=leak\n - leak tests: mark \"sort\" test as passing SANITIZE=leak\n - leak tests: mark a read-tree test as passing SANITIZE=leak\n\n More tests are marked as leak-free.\n\n Will merge to 'next'.\n\n\n* if/redact-packfile-uri (2021-11-11) 2 commits\n - http-fetch: redact url on die() message\n - fetch-pack: redact packfile urls in traces\n\n Redact the path part of packfile URI that appears in the trace output.\n\n Will merge to 'next'.\n\n\n* ew/test-wo-fsync (2021-10-29) 1 commit\n - tests: disable fsync everywhere\n\n Allow running our tests while disabling internal fsync.\n\n\n* ja/doc-cleanup (2021-11-09) 10 commits\n - init doc: --shared=0xxx does not give umask but perm bits\n - doc: git-init: clarify file modes in octal.\n - doc: git-http-push: describe the refs as pattern pairs\n - doc: uniformize <URL> placeholders' case\n - doc: use three dots for indicating repetition instead of star\n - doc: git-ls-files: express options as optional alternatives\n - doc: use only hyphens as word separators in placeholders\n - doc: express grammar placeholders between angle brackets\n - doc: split placeholders as individual tokens\n - doc: fix git credential synopsis\n\n Doc update.\n\n Will merge to 'next'.\n\n\n* re/color-default-reset (2021-10-28) 3 commits\n - color: allow colors to be prefixed with \"reset\"\n - color: support \"default\" to restore fg/bg color\n - color: add missing GIT_COLOR_* white/black constants\n\n \"default\" and \"reset\" colors have been added to our palette.\n\n Will merge to 'next'?\n\n\n* jc/fix-first-object-walk (2021-10-29) 2 commits\n - docs: add headers in MyFirstObjectWalk\n - docs: fix places that break compilation in MyFirstObjectWalk\n\n Doc update.\n\n Will merge to 'next'.\n\n\n* pw/diff-color-moved-fix (2021-10-27) 15 commits\n - diff --color-moved: intern strings\n - diff: use designated initializers for emitted_diff_symbol\n - diff --color-moved-ws=allow-indentation-change: improve hash lookups\n - diff --color-moved: stop clearing potential moved blocks\n - diff --color-moved: shrink potential moved blocks as we go\n - diff --color-moved: unify moved block growth functions\n - diff --color-moved: call comparison function directly\n - diff --color-moved-ws=allow-indentation-change: simplify and optimize\n - diff: simplify allow-indentation-change delta calculation\n - diff --color-moved: avoid false short line matches and bad zerba coloring\n - diff --color-moved=zebra: fix alternate coloring\n - diff --color-moved: rewind when discarding pmb\n - diff --color-moved: factor out function\n - diff --color-moved: clear all flags on blocks that are too short\n - diff --color-moved: add perf tests\n\n Long-overdue correctness and performance update to \"diff\n --color-moved\" feature.\n\n Will merge to 'next'.\n\n\n* ab/generate-command-list (2021-11-05) 10 commits\n - generate-cmdlist.sh: don't parse command-list.txt thrice\n - generate-cmdlist.sh: replace \"grep' invocation with a shell version\n - generate-cmdlist.sh: do not shell out to \"sed\"\n - generate-cmdlist.sh: stop sorting category lines\n - generate-cmdlist.sh: replace for loop by printf's auto-repeat feature\n - generate-cmdlist.sh: run \"grep | sort\", not \"sort | grep\"\n - generate-cmdlist.sh: don't call get_categories() from category_list()\n - generate-cmdlist.sh: spawn fewer processes\n - generate-cmdlist.sh: trivial whitespace change\n - command-list.txt: sort with \"LC_ALL=C sort\"\n\n Build optimization.\n\n Will merge to 'next'.\n\n\n* es/pretty-describe-more (2021-11-01) 3 commits\n - pretty: add abbrev option to %(describe)\n - pretty: add tag option to %(describe)\n - pretty.c: rework describe options parsing for better extensibility\n\n Extend \"git log --format=%(describe)\" placeholder to allow passing\n selected command-line options to the underlying \"git describe\"\n command.\n\n Will merge to 'next'?\n\n\n* fs/ssh-signing-key-lifetime (2021-11-18) 10 commits\n - ssh signing: verify ssh-keygen in test prereq\n - ssh signing: make fmt-merge-msg consider key lifetime\n - ssh signing: make verify-tag consider key lifetime\n - ssh signing: make git log verify key lifetime\n - ssh signing: make verify-commit consider key lifetime\n - ssh signing: add key lifetime test prereqs\n - ssh signing: use sigc struct to pass payload\n - Merge branch 'ad/ssh-signing-testfix' into fs/ssh-signing-key-lifetime\n - Merge branch 'fs/ssh-signing-fix' into fs/ssh-signing-key-lifetime\n - Merge branch 'fs/ssh-signing' into fs/ssh-signing-key-lifetime\n\n Extend the signing of objects with SSH keys and learn to pay\n attention to the key validity time range when verifying.\n\n Will merge to 'next'?\n\n\n* jc/doc-submitting-patches-choice-of-base (2021-10-25) 2 commits\n - (wip) reword the final review part\n - SubmittingPatchs: clarify choice of base and testing\n\n Extend the guidance to choose the base commit to build your work\n on, and hint/nudge contributors to read others' changes.\n\n\n* gc/remote-with-fewer-static-global-variables (2021-11-18) 5 commits\n - remote: die if branch is not found in repository\n - remote: remove the_repository->remote_state from static methods\n - remote: use remote_state parameter internally\n - remote: move static variables into per-repository struct\n - t5516: add test case for pushing remote refspecs\n\n Code clean-up to eventually allow information on remotes defined\n for an arbitrary repository to be read.\n\n Will merge to 'next'.\n\n\n* ab/config-based-hooks-2 (2021-11-24) 18 commits\n - run-command: remove old run_hook_{le,ve}() hook API\n - receive-pack: convert push-to-checkout hook to hook.h\n - read-cache: convert post-index-change to use hook.h\n - commit: convert {pre-commit,prepare-commit-msg} hook to hook.h\n - git-p4: use 'git hook' to run hooks\n - send-email: use 'git hook run' for 'sendemail-validate'\n - git hook run: add an --ignore-missing flag\n - hooks: convert worktree 'post-checkout' hook to hook library\n - hooks: convert non-worktree 'post-checkout' hook to hook library\n - merge: convert post-merge to use hook.h\n - am: convert applypatch-msg to use hook.h\n - rebase: convert pre-rebase to use hook.h\n - hook API: add a run_hooks_l() wrapper\n - am: convert {pre,post}-applypatch to use hook.h\n - gc: use hook library for pre-auto-gc hook\n - hook API: add a run_hooks() wrapper\n - hook: add 'run' subcommand\n - Merge branch 'ab/config-based-hooks-1' into ab/config-based-hooks-2\n\n More \"config-based hooks\".\n\n\n* vd/sparse-sparsity-fix-on-read (2021-11-24) 4 commits\n - sparse-index: update do_read_index to ensure correct sparsity\n - sparse-index: add ensure_correct_sparsity function\n - sparse-index: avoid unnecessary cache tree clearing\n - test-read-cache.c: prepare_repo_settings after config init\n\n Ensure that the sparseness of the in-core index matches the\n index.sparse configuration specified by the repository immediately\n after the on-disk index file is read.\n\n Will merge to 'next'.\n\n\n* js/branch-track-inherit (2021-11-18) 1 commit\n - branch: add flags and config to inherit tracking\n\n \"git -c branch.autosetupmerge=inherit branch new old\" makes \"new\"\n to have the same upstream as the \"old\" branch, instead of marking\n \"old\" itself as its upstream.\n\n\n* jh/builtin-fsmonitor-part2 (2021-10-21) 29 commits\n - t7527: test status with untracked-cache and fsmonitor--daemon\n - fsmonitor: force update index after large responses\n - fsmonitor--daemon: use a cookie file to sync with file system\n - fsmonitor--daemon: periodically truncate list of modified files\n - t/perf/p7519: add fsmonitor--daemon test cases\n - t/perf/p7519: speed up test on Windows\n - t/helper/test-chmtime: skip directories on Windows\n - t/perf: avoid copying builtin fsmonitor files into test repo\n - t7527: create test for fsmonitor--daemon\n - t/helper/fsmonitor-client: create IPC client to talk to FSMonitor Daemon\n - help: include fsmonitor--daemon feature flag in version info\n - fsmonitor--daemon: implement handle_client callback\n - compat/fsmonitor/fsm-listen-darwin: implement FSEvent listener on MacOS\n - compat/fsmonitor/fsm-listen-darwin: add macos header files for FSEvent\n - compat/fsmonitor/fsm-listen-win32: implement FSMonitor backend on Windows\n - fsmonitor--daemon: create token-based changed path cache\n - fsmonitor--daemon: define token-ids\n - fsmonitor--daemon: add pathname classification\n - fsmonitor--daemon: implement 'start' command\n - fsmonitor--daemon: implement 'run' command\n - compat/fsmonitor/fsm-listen-darwin: stub in backend for Darwin\n - compat/fsmonitor/fsm-listen-win32: stub in backend for Windows\n - fsmonitor--daemon: implement 'stop' and 'status' commands\n - fsmonitor--daemon: add a built-in fsmonitor daemon\n - fsmonitor: document builtin fsmonitor\n - fsmonitor: use IPC to query the builtin FSMonitor daemon\n - fsmonitor: config settings are repository-specific\n - fsmonitor-ipc: create client routines for git-fsmonitor--daemon\n - fsmonitor: enhance existing comments\n\n Built-in fsmonitor (part 2).\n\n\n* ld/sparse-diff-blame (2021-11-29) 3 commits\n - blame: enable and test the sparse index\n - diff: enable and test the sparse index\n - Merge branch 'vd/sparse-reset' into ld/sparse-diff-blame\n (this branch is used by ds/fetch-pull-with-sparse-index; uses vd/sparse-reset.)\n\n Teach diff and blame to work well with sparse index.\n\n Expecting a reroll.\n cf. <YXgpqJIS2OgOgS+k@nand.local>\n\n\n* ns/remerge-diff (2021-10-27) 9 commits\n - doc/diff-options: explain the new --remerge-diff option\n - show, log: adapt Elijah Newren's changes to common tmp-objdir API\n - show, log: provide a --remerge-diff capability\n - merge-ort: capture and print ll-merge warnings in our preferred fashion\n - ll-merge: add API for capturing warnings in a strbuf instead of stderr\n - merge-ort: add ability to record conflict messages in a file\n - merge-ort: mark a few more conflict messages as omittable\n - Merge branch 'ns/tmp-objdir' into ns/remerge-diff\n - Merge branch 'ns/tmp-objdir' into ns/remerge-diff\n (this branch uses ns/tmp-objdir.)\n\n A new presentation for two-parent merge \"--remerge-diff\" can be\n used to show the difference between mechanical (and possibly\n conflicted) merge results and the recorded resolution.\n\n On hold.\n This is Elijah's remerge-diff rebased on ns/tmp-objdir to share the\n \"create objects temporarily, only to discard without committing\n them to longer-term storage\" infrastructure with another topic.\n\n\n* ns/tmp-objdir (2021-10-27) 4 commits\n - fixup! tmp-objdir: new API for creating temporary writable databases\n - fixup! tmp-objdir: new API for creating temporary writable databases\n - tmp-objdir: disable ref updates when replacing the primary odb\n - tmp-objdir: new API for creating temporary writable databases\n (this branch is used by ns/batched-fsync and ns/remerge-diff.)\n\n New interface into the tmp-objdir API to help in-core use of the\n quarantine feature.\n\n On hold.\n cf. <xmqqo87auqda.fsf@gitster.g>\n\n\n* vd/sparse-reset (2021-11-29) 8 commits\n - unpack-trees: improve performance of next_cache_entry\n - reset: make --mixed sparse-aware\n - reset: make sparse-aware (except --mixed)\n - reset: integrate with sparse index\n - reset: expand test coverage for sparse checkouts\n - sparse-index: update command for expand/collapse test\n - reset: preserve skip-worktree bit in mixed reset\n - reset: rename is_missing to !is_in_reset_tree\n (this branch is used by ds/fetch-pull-with-sparse-index and ld/sparse-diff-blame.)\n\n Various operating modes of \"git reset\" have been made to work\n better with the sparse index.\n\n Will merge to 'next'.\n\n\n* pw/fix-some-issues-in-reset-head (2021-10-01) 12 commits\n - rebase -m: don't fork git checkout\n - rebase --apply: set ORIG_HEAD correctly\n - rebase --apply: fix reflog\n - reset_head(): take struct rebase_head_opts\n - rebase: cleanup reset_head() calls\n - reset_head(): make default_reflog_action optional\n - reset_head(): factor out ref updates\n - reset_head(): remove action parameter\n - reset_head(): don't run checkout hook if there is an error\n - reset_head(): fix checkout\n - rebase: factor out checkout for up to date branch\n - Merge branch 'pw/rebase-of-a-tag-fix' into pw/fix-some-issues-in-reset-head\n\n Fix \"some issues\" in a helper function reset_head().\n\n Expecting a reroll.\n Needs a lot better explanation, including what the issues are,\n which codepaths the helper is used and to do what, and tests to\n protect the fixes.\n\n\n* es/superproject-aware-submodules (2021-11-18) 5 commits\n - submodule: use config to find superproject worktree\n - submodule: record superproject gitdir during 'update'\n - submodule: record superproject gitdir during absorbgitdirs\n - introduce submodule.superprojectGitDir record\n - t7400-submodule-basic: modernize inspect() helper\n\n A configuration variable in a submodule points at the location of\n the superproject it is bound to (RFC).\n\n\n* ns/batched-fsync (2021-10-27) 9 commits\n - Merge branch 'ns/tmp-objdir' into ns/batched-fsync\n - core.fsyncobjectfiles: performance tests for add and stash\n - core.fsyncobjectfiles: tests for batch mode\n - unpack-objects: use the bulk-checkin infrastructure\n - update-index: use the bulk-checkin infrastructure\n - core.fsyncobjectfiles: add windows support for batch mode\n - core.fsyncobjectfiles: batched disk flushes\n - bulk-checkin: rename 'state' variable and separate 'plugged' boolean\n - Merge branch 'ns/tmp-objdir' into ns/batched-fsync\n (this branch uses ns/tmp-objdir.)\n\n The \"core.fsyncobjectfiles\" configuration variable can now be set\n to \"batch\" for improved performance.\n\n On hold.\n cf. <xmqqo87auqda.fsf@gitster.g>\n\n\n* en/zdiff3 (2021-09-20) 2 commits\n - update documentation for new zdiff3 conflictStyle\n - xdiff: implement a zealous diff3, or \"zdiff3\"\n\n \"Zealous diff3\" style of merge conflict presentation has been added.\n\n What's the status of this thing?\n\n\n* js/scalar (2021-11-19) 17 commits\n - scalar: implement the `version` command\n - scalar: implement the `delete` command\n - scalar: teach 'reconfigure' to optionally handle all registered enlistments\n - scalar: allow reconfiguring an existing enlistment\n - scalar: implement the `run` command\n - scalar: teach 'clone' to support the --single-branch option\n - scalar: implement the `clone` subcommand\n - scalar: implement 'scalar list'\n - scalar: let 'unregister' handle a deleted enlistment directory gracefully\n - scalar: 'unregister' stops background maintenance\n - scalar: 'register' sets recommended config and starts maintenance\n - ci: also run the `scalar` tests\n - cmake: optionally build `scalar`, too\n - scalar: create test infrastructure\n - scalar: start documenting the command\n - scalar: create a rudimentary executable\n - scalar: add a README with a roadmap\n\n Add pieces from \"scalar\" to contrib/.\n\n\n* ms/customizable-ident-expansion (2021-09-01) 1 commit\n - keyword expansion: make \"$Id$\" string configurable\n\n Instead of \"$Id$\", user-specified string (like $FreeBSD$) can be\n used as an in-blob placeholder for keyword expansion.\n\n\n* ab/only-single-progress-at-once (2021-11-03) 8 commits\n - progress.c: add & assert a \"global_progress\" variable\n - various *.c: use isatty(0|2), not isatty(STDIN_FILENO|STDERR_FILENO)\n - pack-bitmap-write.c: don't return without stop_progress()\n - progress.c: add temporary variable from progress struct\n - progress.c tests: test some invalid usage\n - progress.c tests: make start/stop commands on stdin\n - progress.c test helper: add missing braces\n - leak tests: fix a memory leaks in \"test-progress\" helper\n\n Further tweaks on progress API.\n\n\n* hn/reftable (2021-10-08) 19 commits\n - Add \"test-tool dump-reftable\" command.\n - reftable: add dump utility\n - reftable: implement stack, a mutable database of reftable files.\n - reftable: implement refname validation\n - reftable: add merged table view\n - reftable: add a heap-based priority queue for reftable records\n - reftable: reftable file level tests\n - reftable: read reftable files\n - reftable: generic interface to tables\n - reftable: write reftable files\n - reftable: a generic binary tree implementation\n - reftable: reading/writing blocks\n - Provide zlib's uncompress2 from compat/zlib-compat.c\n - reftable: (de)serialization for the polymorphic record type.\n - reftable: add blocksource, an abstraction for random access reads\n - reftable: utility functions\n - reftable: add error related functionality\n - reftable: add LICENSE\n - hash.h: provide constants for the hash IDs\n\n The \"reftable\" backend for the refs API, without integrating into\n the refs subsystem.\n\n Will merge to 'next'.\n"},{"id":"442615","messageId":"YaXTxTW9ihC1/deN@coredump.intra.peff.net","threadId":"56998","inReplyTo":"xmqqzgpm2xrd.fsf@gitster.g","subject":"jk/loosen-urlmatch, was What's cooking in git.git (Nov 2021, #07; Mon, 29)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2021-11-30T07:33:25Z","receivedAt":"2021-11-30T07:33:33Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Nov 29, 2021 at 06:16:54PM -0800, Junio C Hamano wrote:\n\n> --------------------------------------------------\n> [Graduated to 'master']\n>\n> [...]\n> * jk/loosen-urlmatch (2021-10-12) 1 commit\n>   (merged to 'next' on 2021-10-25 at f66ca39ebe)\n>  + urlmatch: add underscore to URL_HOST_CHARS\n> \n>  Treat \"_\" as any other URL-valid characters in an URL when matching\n>  the per-URL configuration variable names.\n\nSorry, I hadn't noticed that this one had even made it to 'next', and\nwas surprised to see it graduate.\n\nI think brian corrected my assertion in the commit message that RFC 1738\nsays that underscores are OK. They are for URIs in general, but not the\nspecific case of hostnames in HTTP schemes.\n\nNow that isn't strictly a reason to drop the patch. Even though\nunderscores aren't allowed, they do work in some limited circumstances,\nand curl is happy to take them. So in some sense this is harmonizing our\nurlmatch behavior with curl for an iffy-but-workable practice, and there\nmay be value in that. But it does take us further away from the\nstandards, which could possibly have surprising consequences down the\nroad.\n\nI don't have a strong feeling either way on reverting it at this point.\nBut I wanted to make sure that if we kept it in, we were doing so\nconsciously, and not just because folks involved in the discussion\ndidn't realize it was still working its way through the process.\n\nI.e., if brian is likewise surprised and wants to object, this is now\nthe time. :)\n\n-Peff\n"},{"id":"442647","messageId":"YaYkcLNPODqzQNgu@camp.crustytoothpaste.net","threadId":"56998","inReplyTo":"YaXTxTW9ihC1/deN@coredump.intra.peff.net","subject":"Re: jk/loosen-urlmatch, was What's cooking in git.git (Nov 2021, #07; Mon, 29)","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2021-11-30T13:17:36Z","receivedAt":"2021-11-30T13:17:41Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2021-11-30 at 07:33:25, Jeff King wrote:\n> On Mon, Nov 29, 2021 at 06:16:54PM -0800, Junio C Hamano wrote:\n> \n> > --------------------------------------------------\n> > [Graduated to 'master']\n> >\n> > [...]\n> > * jk/loosen-urlmatch (2021-10-12) 1 commit\n> >   (merged to 'next' on 2021-10-25 at f66ca39ebe)\n> >  + urlmatch: add underscore to URL_HOST_CHARS\n> > \n> >  Treat \"_\" as any other URL-valid characters in an URL when matching\n> >  the per-URL configuration variable names.\n> \n> Sorry, I hadn't noticed that this one had even made it to 'next', and\n> was surprised to see it graduate.\n> \n> I think brian corrected my assertion in the commit message that RFC 1738\n> says that underscores are OK. They are for URIs in general, but not the\n> specific case of hostnames in HTTP schemes.\n\nFrom my memory of the research I did, they're okay for URIs according to\nthe grammar, but they're acceptable only if you're using something that\nisn't DNS, which as a practical matter is never the case.\n\n> Now that isn't strictly a reason to drop the patch. Even though\n> underscores aren't allowed, they do work in some limited circumstances,\n> and curl is happy to take them. So in some sense this is harmonizing our\n> urlmatch behavior with curl for an iffy-but-workable practice, and there\n> may be value in that. But it does take us further away from the\n> standards, which could possibly have surprising consequences down the\n> road.\n> \n> I don't have a strong feeling either way on reverting it at this point.\n> But I wanted to make sure that if we kept it in, we were doing so\n> consciously, and not just because folks involved in the discussion\n> didn't realize it was still working its way through the process.\n\nI don't think it's necessarily worth reverting, but we should avoid\ncontinuing to make further improvements in this area.  In other words,\nwe shouldn't take this as an opportunity to support more of this.\n-- \nbrian m. carlson (he/him or they/them)\nToronto, Ontario, CA\n"},{"id":"442684","messageId":"211130.86k0gpcpy2.gmgdl@evledraar.gmail.com","threadId":"56998","inReplyTo":"xmqqzgpm2xrd.fsf@gitster.g","subject":"ab/run-command + em/missing-pager (was: What's cooking in git.git (Nov 2021, #07; Mon, 29))","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2021-11-30T20:54:33Z","receivedAt":"2021-11-30T21:07:55Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Mon, Nov 29 2021, Junio C Hamano wrote:\n\n> * ab/run-command (2021-11-25) 9 commits\n>  - run-command API: remove \"env\" member, always use \"env_array\"\n>  - difftool: use \"env_array\" to simplify memory management\n>  - run-command API: remove \"argv\" member, always use \"args\"\n>  - run-command API users: use strvec_push(), not argv construction\n>  - run-command API users: use strvec_pushl(), not argv construction\n>  - run-command tests: use strvec_pushv(), not argv assignment\n>  - run-command API users: use strvec_pushv(), not argv assignment\n>  - upload-archive: use regular \"struct child_process\" pattern\n>  - worktree: stop being overly intimate with run_command() internals\n\nI think the only outstanding thing for this topic is Eric's [1] comment\n(on his own code). I think that variable shadowing is OK.\n\n1/2 of that patch will also be rewritten in the in-flight hook topic\n(but the \"reset --hard\" shadowing is left in place).\n\n> * em/missing-pager (2021-11-24) 1 commit\n> - pager: fix crash when pager program doesn't exist\n\nAs noted in [2] I'm happy to get this more isolated fix first. I'd\nmissed that there was a re-submission[3] until now (since In-Reply-To\nwasn't maintained).\n\nThe code change in [3] isn't needed anymore when combined with my\nab/run-command.\n\nDepending on how you're planning to advance these perhaps you'd like to\nrevert that as it's merged with ab/run-command, or I can re-roll\nab/run-command on top of it if you'd like.\n\nWe could also just leave that now-redundant child_process_init() in\npager.c, but having something that'll amount to cargo-culting to get\naround a bug in dead code doesn't seem ideal. It would be nice to have\nthe API use reflect \"argv\" and \"env\" being gone.\n\n1. https://lore.kernel.org/git/CAPig+cRi6SeuV7k_+9JCcnf79daLZp5B=EyHK-KxC1VGN0B4ig@mail.gmail.com/\n2. https://lore.kernel.org/git/211124.865ysie2br.gmgdl@evledraar.gmail.com/\n3. https://lore.kernel.org/git/20211125000239.2336-1-ematsumiya@suse.de\n"},{"id":"442686","messageId":"211130.86fsrdcps0.gmgdl@evledraar.gmail.com","threadId":"56998","inReplyTo":"xmqqzgpm2xrd.fsf@gitster.g","subject":"ab/ci-updates (was: What's cooking in git.git (Nov 2021, #07; Mon, 29))","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2021-11-30T21:08:05Z","receivedAt":"2021-11-30T21:11:33Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Mon, Nov 29 2021, Junio C Hamano wrote:\n\n> * ab/ci-updates (2021-11-23) 5 commits\n>  - CI: don't run \"make test\" twice in one job\n>  - CI: use \"$runs_on_pool\", not \"$jobname\" to select packages & config\n>  - CI: rename the \"Linux32\" job to lower-case \"linux32\"\n>  - CI: use shorter names that fit in UX tooltips\n>  - CI: remove Travis CI support\n\nIt looked like there was general happiness with the approach of having\nthe dead code gone and the GitHub tooltips being more useful.\n\nGiven that this is relatively trivial, and if it was causing trouble\nwe'd likely know by now it would be nice to get this merged down sooner\nthan later.\n\nAs noted in the latest thread on js/scalar there's outstanding\ninteractions with that larger topic (including some semantic merge\n\"conflicts\"). So having it in \"master\" to base on would also remove its\ninteraction with that topic & any other CI modification as a variable.\n\n1. https://lore.kernel.org/git/211130.86mtlleqhm.gmgdl@evledraar.gmail.com/\n"},{"id":"442688","messageId":"211130.86bl21cpkd.gmgdl@evledraar.gmail.com","threadId":"56998","inReplyTo":"xmqqzgpm2xrd.fsf@gitster.g","subject":"ab/config-based-hooks-2 (was: What's cooking in git.git (Nov 2021, #07; Mon, 29))","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2021-11-30T21:12:23Z","receivedAt":"2021-11-30T21:16:07Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Mon, Nov 29 2021, Junio C Hamano wrote:\n\n> * ab/config-based-hooks-2 (2021-11-24) 18 commits\n>  - run-command: remove old run_hook_{le,ve}() hook API\n>  - receive-pack: convert push-to-checkout hook to hook.h\n>  - read-cache: convert post-index-change to use hook.h\n>  - commit: convert {pre-commit,prepare-commit-msg} hook to hook.h\n>  - git-p4: use 'git hook' to run hooks\n>  - send-email: use 'git hook run' for 'sendemail-validate'\n>  - git hook run: add an --ignore-missing flag\n>  - hooks: convert worktree 'post-checkout' hook to hook library\n>  - hooks: convert non-worktree 'post-checkout' hook to hook library\n>  - merge: convert post-merge to use hook.h\n>  - am: convert applypatch-msg to use hook.h\n>  - rebase: convert pre-rebase to use hook.h\n>  - hook API: add a run_hooks_l() wrapper\n>  - am: convert {pre,post}-applypatch to use hook.h\n>  - gc: use hook library for pre-auto-gc hook\n>  - hook API: add a run_hooks() wrapper\n>  - hook: add 'run' subcommand\n>  - Merge branch 'ab/config-based-hooks-1' into ab/config-based-hooks-2\n>\n>  More \"config-based hooks\".\n\nI know Emily's keen to get to the conclusion of the \"config-based-hooks\"\nstory. I think it's gotten a lot of careful review already, and it would\nbe nice to have it land soon in this cycle so the follow-up topics can\nbe queued after it.\n\nI re-rolled it a ~week ago[1], but that was a trivial change to save you\nfrom dealing with a compilation error as it got merged with my own\n\"ab/run-command\" (it was using \"env\", not \"env_array\")[1]. Other than\nthat there's been no change to it for the last month since the v4[2].\n\n1. https://lore.kernel.org/git/cover-v5-00.17-00000000000-20211123T114206Z-avarab@gmail.com/\n2. https://lore.kernel.org/git/cover-v4-00.17-00000000000-20211101T184938Z-avarab@gmail.com/\n"},{"id":"442689","messageId":"YaaU/OyVZI2uDLjy@coredump.intra.peff.net","threadId":"56998","inReplyTo":"211130.86k0gpcpy2.gmgdl@evledraar.gmail.com","subject":"Re: ab/run-command + em/missing-pager (was: What's cooking in git.git (Nov 2021, #07; Mon, 29))","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2021-11-30T21:17:48Z","receivedAt":"2021-11-30T21:18:09Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Nov 30, 2021 at 09:54:33PM +0100, Ævar Arnfjörð Bjarmason wrote:\n\n> > * em/missing-pager (2021-11-24) 1 commit\n> > - pager: fix crash when pager program doesn't exist\n> \n> As noted in [2] I'm happy to get this more isolated fix first. I'd\n> missed that there was a re-submission[3] until now (since In-Reply-To\n> wasn't maintained).\n> \n> The code change in [3] isn't needed anymore when combined with my\n> ab/run-command.\n> \n> Depending on how you're planning to advance these perhaps you'd like to\n> revert that as it's merged with ab/run-command, or I can re-roll\n> ab/run-command on top of it if you'd like.\n> \n> We could also just leave that now-redundant child_process_init() in\n> pager.c, but having something that'll amount to cargo-culting to get\n> around a bug in dead code doesn't seem ideal. It would be nice to have\n> the API use reflect \"argv\" and \"env\" being gone.\n\nIMHO that extra init is still doing the right thing, because it means\nthe struct is in the same known state in every run of setup_pager().\nFixing the argv/env thing stops the immediate bug, but there are other\npotential ones. E.g., starting the command will overwrite the in/out/err\nparameters; we're OK in this instance because we unconditionally\noverwrite them.\n\nSo I think reusing a child_process struct without reinitializing it is\nalways a bit iffy, though it _usually_ works in practice. We should\nmodel good use of the API by initializing on each use.\n\n-Peff\n"},{"id":"442690","messageId":"211130.867dcpcpgh.gmgdl@evledraar.gmail.com","threadId":"56998","inReplyTo":"xmqqzgpm2xrd.fsf@gitster.g","subject":"fs/test-prereq (was: What's cooking in git.git (Nov 2021, #07; Mon, 29))","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2021-11-30T21:17:02Z","receivedAt":"2021-11-30T21:19:36Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Mon, Nov 29 2021, Junio C Hamano wrote:\n\n> * fs/test-prereq (2021-11-20) 3 commits\n>  - test-lib: make BAIL_OUT() work in tests and prereq\n>  - test-lib: introduce required prereq for test runs\n>  - test-lib: show missing prereq summary\n>\n>  The test framework learns to list unsatisfied test prerequisites,\n>  and optionally error out when prerequisites that are expected to be\n>  satisfied are not.\n>\n>  Will merge to 'next'?\n\nMy reading of\nhttps://lore.kernel.org/git/20211130143821.7dz5jj2z2x2q2ytn@fs/ is that\nFabian's planning to re-roll it.\n\nI replied today to that to clarify some edge cases around TAP.\n"},{"id":"442691","messageId":"211130.8635ndcpcg.gmgdl@evledraar.gmail.com","threadId":"56998","inReplyTo":"xmqqzgpm2xrd.fsf@gitster.g","subject":"jc/c99-var-decl-in-for-loop (was: What's cooking in git.git (Nov 2021, #07; Mon, 29))","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2021-11-30T21:18:40Z","receivedAt":"2021-11-30T21:21:06Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Mon, Nov 29 2021, Junio C Hamano wrote:\n\n> * jc/c99-var-decl-in-for-loop (2021-11-22) 1 commit\n>  - revision: use C99 declaration of variable in for() loop\n>\n>  Weather balloon to break compilers that do not grok variable\n>  declaration in the for() loop.\n>\n>  Will merge to 'next'?\n\nI think that sounds good!\n\nThe change is trivial, and due to the nature of it having it sooner than\nlater this cycle can only be better, in case there's some obscure system\nwe didn't consider, catching that before the next release would be\npreferable.\n"},{"id":"442711","messageId":"CAPig+cSvFgJTiq8pXrWy_7ukQwE1y9ZGwMgKmyjWuQHdNGxiDQ@mail.gmail.com","threadId":"56998","inReplyTo":"211130.86k0gpcpy2.gmgdl@evledraar.gmail.com","subject":"Re: ab/run-command + em/missing-pager (was: What's cooking in git.git (Nov 2021, #07; Mon, 29))","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2021-11-30T22:09:58Z","receivedAt":"2021-11-30T22:10:28Z","isPatch":false,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Tue, Nov 30, 2021 at 4:07 PM Ævar Arnfjörð Bjarmason\n<avarab@gmail.com> wrote:\n> On Mon, Nov 29 2021, Junio C Hamano wrote:\n> > * ab/run-command (2021-11-25) 9 commits\n> >  - worktree: stop being overly intimate with run_command() internals\n>\n> I think the only outstanding thing for this topic is Eric's [1] comment\n> (on his own code). I think that variable shadowing is OK.\n>\n> 1. https://lore.kernel.org/git/CAPig+cRi6SeuV7k_+9JCcnf79daLZp5B=EyHK-KxC1VGN0B4ig@mail.gmail.com/\n\nI'm also fine with the variable shadowing and don't consider it an\noutstanding issue with the topic (it was just a minor observation in\ncase anyone complained). I didn't see anything else worth commenting\non in the remainder of the series.\n"},{"id":"442717","messageId":"CABPp-BHq4DnkCZZ+HcnGiZYKHpWJgzMBjMDuWbbTFYPesm2sXA@mail.gmail.com","threadId":"56998","inReplyTo":"xmqqzgpm2xrd.fsf@gitster.g","subject":"ns/tmp-objdir and ns/remerge-diff","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2021-11-30T23:07:32Z","receivedAt":"2021-11-30T23:07:52Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Tue, Nov 30, 2021 at 6:49 AM Junio C Hamano <gitster@pobox.com> wrote:\n>\n> The exception is 'ns/tmp-objdir' and a few topics that depend on it,\n> which are kicked out of 'next' to give the base topic a chance to\n> lose the two \"fixup!\" band-aid.  Careful re-reading of the topic by\n> somebody with a fresh set of eyes (meaning, everybody, as this has\n> been dormant for almost a month) is very much appreciated to move\n> things forward.\n\nns/tmp-objdir had a re-roll that has not been picked up, at [1] --\nperhaps because it's an combination of ns/tmp-objdir and\nns/batched-fsync (it'd be nicer to have those two split).  I gave the\nns/tmp-objdir part another read over and was only able to spot two\nsmall things.  I think you should mark it as expecting a reroll based\non [2] (\"Good catch. I'll fix this.\") and [3] (\"I'll take this\nsuggestion.\"), but I think it could be merged to next quickly after\nthat.\n\n[1] https://lore.kernel.org/git/pull.1076.v9.git.git.1637020263.gitgitgadget@gmail.com/\n[2] https://lore.kernel.org/git/CANQDOddCC7+gGUy1VBxxwvN7ieP+N8mQhbxK2xx6ySqZc6U7-g@mail.gmail.com/\n[3] https://lore.kernel.org/git/CANQDOdd7EHUqD_JBdO9ArpvOQYUnU9GSL6EVR7W7XXgNASZyhQ@mail.gmail.com/\n\n>  Also ns/remerge-diff that is Neeraj's rebase of the\n> remerge-diff topic needs Elijah's Ack at least.\n\nMark it as expecting a re-roll; I've been waiting for ns/tmp-objdir to\nsettle so I can rebase on it.\n"},{"id":"442720","messageId":"CABPp-BE=NhC0W7H2uF3LuSNOEXfdLw7KH11YXVz6G53QF6gE8A@mail.gmail.com","threadId":"56998","inReplyTo":"xmqqzgpm2xrd.fsf@gitster.g","subject":"Re: What's cooking in git.git (Nov 2021, #07; Mon, 29)","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2021-11-30T23:35:53Z","receivedAt":"2021-11-30T23:36:10Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"Not sure if it help/hurts/matters, but thought I'd send a thumbs up on\nseveral of the topics.  For topics I have comments other than a thumbs\nup for, I'll post separate messages...\n\nOn Tue, Nov 30, 2021 at 6:49 AM Junio C Hamano <gitster@pobox.com> wrote:\n>\n> * pw/xdiff-classify-record-in-histogram (2021-11-18) 3 commits\n> ...\n>  Will merge to 'next'.\n>\n>\n> * ab/mark-leak-free-tests-even-more (2021-11-01) 15 commits\n> ...\n>  Will merge to 'next'.\n>\n>\n> * pw/diff-color-moved-fix (2021-10-27) 15 commits\n> ...\n>  Will merge to 'next'.\n>\n>\n> * vd/sparse-sparsity-fix-on-read (2021-11-24) 4 commits\n> ...\n>  Will merge to 'next'.\n\nThumb up on all these from me.\n\n> * vd/sparse-reset (2021-11-29) 8 commits\n> ...\n>  Will merge to 'next'.\n\nThere were two tiny issues pointed out at\nhttps://lore.kernel.org/git/9c5b7067-b0e3-0153-5cd3-042bae92f91e@github.com/,\nbut it'd be fine to merge the series as-is and consider those as later\npotential improvements.\n"},{"id":"442721","messageId":"CABPp-BE4uYBFnb-AgVJhNo6iK4da5hiEFEBhd=7Ea3Ov=4K4zw@mail.gmail.com","threadId":"56998","inReplyTo":"xmqqzgpm2xrd.fsf@gitster.g","subject":"Re: What's cooking in git.git (Nov 2021, #07; Mon, 29)","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2021-11-30T23:45:34Z","receivedAt":"2021-11-30T23:45:48Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Tue, Nov 30, 2021 at 6:49 AM Junio C Hamano <gitster@pobox.com> wrote:\n>\n> * xw/am-empty (2021-11-22) 2 commits\n>  - am: support --empty=<option> to handle empty patches\n>  - doc: git-format-patch: describe the option --always\n>\n>  \"git am\" learns \"--empty=(die|drop|keep)\" option to tweak what is\n>  done to a piece of e-mail without a patch in it.\n>\n>  Will merge to 'next'.\n\nPlease don't, at least not this version.  There have been newer\nsubmissions with three commits.\n\nI also still find the word 'die' confusing, since to me it suggests\naborting the whole am operation, and the documentation does not dispel\nthat concern.  Even if you don't like 'ask' (for consistency with\ngit-rebase), I think 'stop' or 'interrupt' would be much better\noptions than 'die'.  If you really want it to be 'die', I think the\nbehavior needs to be explained in the documentation, rather than just\nassumed that users will understand it (because I didn't understand it\nuntil I read the code).\n"},{"id":"442722","messageId":"CABPp-BERnA+tyP0RTQ-iXcm5wwO5GbjasP3O-MjqSHGauyibFQ@mail.gmail.com","threadId":"56998","inReplyTo":"xmqqzgpm2xrd.fsf@gitster.g","subject":"en/zdiff3 (was: Re: What's cooking in git.git (Nov 2021, #07; Mon, 29))","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2021-11-30T23:52:13Z","receivedAt":"2021-11-30T23:52:27Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Tue, Nov 30, 2021 at 6:49 AM Junio C Hamano <gitster@pobox.com> wrote:\n>\n> * en/zdiff3 (2021-09-20) 2 commits\n>  - update documentation for new zdiff3 conflictStyle\n>  - xdiff: implement a zealous diff3, or \"zdiff3\"\n>\n>  \"Zealous diff3\" style of merge conflict presentation has been added.\n>\n>  What's the status of this thing?\n\nI resubmitted it before you added this question, and have pointed out\nthe resubmission in response to the past \"What's cooking\" emails, but\nperhaps it'll be easier for me to just resubmit with no changes.  I'll\ndo that.\n"},{"id":"442733","messageId":"d95f092.3f.17d73a85761.Coremail.pwxu@coremail.cn","threadId":"56998","inReplyTo":"CABPp-BE4uYBFnb-AgVJhNo6iK4da5hiEFEBhd=7Ea3Ov=4K4zw@mail.gmail.com","subject":"Re: What's cooking in git.git (Nov 2021, #07; Mon, 29)","fromName":"Aleen 徐沛文","fromEmail":"pwxu@coremail.cn","sentAt":"2021-12-01T01:42:32Z","receivedAt":"2021-12-01T01:43:06Z","isPatch":false,"sender":{"key":"pwxu@coremail.cn","avatar":null},"body":"> Please don't, at least not this version.  There have been newer\n> submissions with three commits.\n> \n> I also still find the word 'die' confusing, since to me it suggests\n> aborting the whole am operation, and the documentation does not dispel\n> that concern.  Even if you don't like 'ask' (for consistency with\n> git-rebase), I think 'stop' or 'interrupt' would be much better\n> options than 'die'.  If you really want it to be 'die', I think the\n> behavior needs to be explained in the documentation, rather than just\n> assumed that users will understand it (because I didn't understand it\n> until I read the code).\n\nDears Newren,\n\n    I don't think 'stop' and 'interrupt' words are better to explain more than 'die'\n    because they still indicate that it will stop or interrupt the whole am session,\n    rather than stop in the middle of it. It may be a good choice to just add an\n    additional description about the behaviour when not passing the '--empty' option\n    or passing '--empty=die'.\n\nAleen"},{"id":"442761","messageId":"20211201085357.2ecorbu3rfw5ctaa@fs","threadId":"56998","inReplyTo":"211130.867dcpcpgh.gmgdl@evledraar.gmail.com","subject":"Re: fs/test-prereq (was: What's cooking in git.git (Nov 2021, #07; Mon, 29))","fromName":"Fabian Stelzer","fromEmail":"fs@gigacodes.de","sentAt":"2021-12-01T08:53:57Z","receivedAt":"2021-12-01T08:54:06Z","isPatch":false,"sender":{"key":"fs@gigacodes.de","avatar":"https://avatars.githubusercontent.com/u/564858?v=4"},"body":"On 30.11.2021 22:17, Ævar Arnfjörð Bjarmason wrote:\n>\n>On Mon, Nov 29 2021, Junio C Hamano wrote:\n>\n>> * fs/test-prereq (2021-11-20) 3 commits\n>>  - test-lib: make BAIL_OUT() work in tests and prereq\n>>  - test-lib: introduce required prereq for test runs\n>>  - test-lib: show missing prereq summary\n>>\n>>  The test framework learns to list unsatisfied test prerequisites,\n>>  and optionally error out when prerequisites that are expected to be\n>>  satisfied are not.\n>>\n>>  Will merge to 'next'?\n>\n>My reading of\n>https://lore.kernel.org/git/20211130143821.7dz5jj2z2x2q2ytn@fs/ is that\n>Fabian's planning to re-roll it.\n>\n>I replied today to that to clarify some edge cases around TAP.\n\nYes, thanks for that. I resubmitted a new version with the better comment.\n\nThanks\n"},{"id":"442762","messageId":"20211201085912.gkwmlo5br73aft27@fs","threadId":"56998","inReplyTo":"xmqqzgpm2xrd.fsf@gitster.g","subject":"Re: What's cooking in git.git (Nov 2021, #07; Mon, 29)","fromName":"Fabian Stelzer","fromEmail":"fs@gigacodes.de","sentAt":"2021-12-01T08:59:12Z","receivedAt":"2021-12-01T08:59:51Z","isPatch":false,"sender":{"key":"fs@gigacodes.de","avatar":"https://avatars.githubusercontent.com/u/564858?v=4"},"body":"On 29.11.2021 18:16, Junio C Hamano wrote:\n>\n> * fs/ssh-signing-other-keytypes (2021-11-19) 2 commits\n> - ssh signing: make sign/amend test more resilient\n> - ssh signing: support non ssh-* keytypes\n>\n\nI will send a rebased version of this one on top of\nfs/ssh-signing-key-lifetime. Otherwise those two will result in a\n(simple) merge conflict in the test prereqs.\n\n>\n> * fs/ssh-signing-key-lifetime (2021-11-18) 10 commits\n> - ssh signing: verify ssh-keygen in test prereq\n> - ssh signing: make fmt-merge-msg consider key lifetime\n> - ssh signing: make verify-tag consider key lifetime\n> - ssh signing: make git log verify key lifetime\n> - ssh signing: make verify-commit consider key lifetime\n> - ssh signing: add key lifetime test prereqs\n> - ssh signing: use sigc struct to pass payload\n> - Merge branch 'ad/ssh-signing-testfix' into fs/ssh-signing-key-lifetime\n> - Merge branch 'fs/ssh-signing-fix' into fs/ssh-signing-key-lifetime\n> - Merge branch 'fs/ssh-signing' into fs/ssh-signing-key-lifetime\n>\n> Extend the signing of objects with SSH keys and learn to pay\n> attention to the key validity time range when verifying.\n>\n> Will merge to 'next'?\n>\n\nI just resubmitted a new version which cleans up the prereq setup.\n\nThanks\n"},{"id":"442790","messageId":"afdf6810-3e73-d0f3-ea02-c78ba6f7b908@github.com","threadId":"56998","inReplyTo":"CABPp-BE=NhC0W7H2uF3LuSNOEXfdLw7KH11YXVz6G53QF6gE8A@mail.gmail.com","subject":"Re: What's cooking in git.git (Nov 2021, #07; Mon, 29)","fromName":"Victoria Dye","fromEmail":"vdye@github.com","sentAt":"2021-12-01T19:29:08Z","receivedAt":"2021-12-01T19:30:12Z","isPatch":false,"sender":{"key":"vdye@github.com","avatar":"https://avatars.githubusercontent.com/u/3619353?v=4"},"body":"Elijah Newren wrote:\n>> * vd/sparse-reset (2021-11-29) 8 commits\n>> ...\n>>  Will merge to 'next'.\n> \n> There were two tiny issues pointed out at\n> https://lore.kernel.org/git/9c5b7067-b0e3-0153-5cd3-042bae92f91e@github.com/,\n> but it'd be fine to merge the series as-is and consider those as later\n> potential improvements.\n> \n\nIn the interest of avoiding further delays to (and maintenance burden for)\nthe other in-flight series dependent on this one, I'd prefer including those\nfixups in my next set of sparse index integrations.\n"},{"id":"442801","messageId":"CABPp-BG9jHaJYekDnvZT+8QW_fLGM_bmz-oOqzJswaotyVDFBA@mail.gmail.com","threadId":"56998","inReplyTo":"d95f092.3f.17d73a85761.Coremail.pwxu@coremail.cn","subject":"Re: What's cooking in git.git (Nov 2021, #07; Mon, 29)","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2021-12-01T20:56:34Z","receivedAt":"2021-12-01T20:59:40Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Tue, Nov 30, 2021 at 5:42 PM Aleen 徐沛文 <pwxu@coremail.cn> wrote:\n>\n> > Please don't, at least not this version.  There have been newer\n> > submissions with three commits.\n> >\n> > I also still find the word 'die' confusing, since to me it suggests\n> > aborting the whole am operation, and the documentation does not dispel\n> > that concern.  Even if you don't like 'ask' (for consistency with\n> > git-rebase), I think 'stop' or 'interrupt' would be much better\n> > options than 'die'.  If you really want it to be 'die', I think the\n> > behavior needs to be explained in the documentation, rather than just\n> > assumed that users will understand it (because I didn't understand it\n> > until I read the code).\n>\n> Dears Newren,\n>\n>     I don't think 'stop' and 'interrupt' words are better to explain more than 'die'\n>     because they still indicate that it will stop or interrupt the whole am session,\n>     rather than stop in the middle of it.\n\nSince you've been through several rounds of revisions already, if this\nis the only remaining issue with your series, I wouldn't try to hold\nit up for this issue; I just thought it could be fixed while you were\nworking on the --allow-empty stuff.\n\nHowever, while I don't think it's worth holding up your series for\njust this issue, I would definitely submit a follow-up RFC patch to\nfix the wording, because I do disagree with your assertion here pretty\nstrongly.  Let's look at the meanings of the terms:\n\ndie: connotes something pretty final and irreversible -- people tend\nnot to revive after death as far as recorded history goes; most such\nrecorded instances tend to be causes for people to debate the\ndefinition of 'dead'.\n\nstop: could be final, but is often used in a transitory setting: \"stop\nand go traffic\", \"stopped to catch my breath\",  \"the train will stop\nat this station\", \"stop! I want to get out\", etc.\n\ninterrupt: seems to nearly always be used as a transitory thing\n\nNow, in the computer science context, all three terms come up relative\nto processes.  You can interrupt a process (the kernel does all the\ntime), but it'll usually continue afterwards.  Or you can give it a\nSIGINT (interrupt from keyboard signal), which the process can catch\nand ignore.  You can stop a process (and SIGSTOP cannot be caught),\nbut you can also continue it later.  die essentially means the process\nis going to be gone for good (at least short of some kind of black\nmagic like a reversible debugger such as rr).\n\nSo, I think it's much more likely that 'die' will be misunderstood to\nmean abortion of the entire am-process, than that 'stop' or\n'interrupt' would.\n\n>     It may be a good choice to just add an\n>     additional description about the behaviour when not passing the '--empty' option\n>     or passing '--empty=die'.\n\nThat would be good.\n"},{"id":"442810","messageId":"xmqqpmqgyntm.fsf@gitster.g","threadId":"56998","inReplyTo":"CABPp-BERnA+tyP0RTQ-iXcm5wwO5GbjasP3O-MjqSHGauyibFQ@mail.gmail.com","subject":"Re: en/zdiff3","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-12-01T22:15:01Z","receivedAt":"2021-12-01T22:15:15Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Elijah Newren <newren@gmail.com> writes:\n\n> On Tue, Nov 30, 2021 at 6:49 AM Junio C Hamano <gitster@pobox.com> wrote:\n>>\n>> * en/zdiff3 (2021-09-20) 2 commits\n>>  - update documentation for new zdiff3 conflictStyle\n>>  - xdiff: implement a zealous diff3, or \"zdiff3\"\n>>\n>>  \"Zealous diff3\" style of merge conflict presentation has been added.\n>>\n>>  What's the status of this thing?\n>\n> I resubmitted it before you added this question, and have pointed out\n> the resubmission in response to the past \"What's cooking\" emails, but\n> perhaps it'll be easier for me to just resubmit with no changes.  I'll\n> do that.\n\nThanks.  Yes, for anything that is older than a month, it always is\neasier that way.\n"},{"id":"442927","messageId":"xmqqa6hitrt5.fsf@gitster.g","threadId":"56998","inReplyTo":"xmqqzgpm2xrd.fsf@gitster.g","subject":"Re: What's cooking in git.git (Nov 2021, #07; Mon, 29)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-12-03T01:12:22Z","receivedAt":"2021-12-03T01:12:34Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"As of this evening, my tree is not yet in a good enough shape to\nissue the next iteration of \"What's cooking\" report, but I've\nmanaged to merge some topics to 'next'.  No, nothing exciting is in\nthere.  This first batch of topics consists of stuff that would have\nbeen in 'next' or even in the release if the previous cycle were\nlonger by a week or two.\n\nI plan to reserve time for picking and trial-merging other topics\nthat we want to have in 'next' tomorrow, so that I can finish the\n\"What's cooking\" report with more topics marked for 'next'.\n\nTo make sure I can make progress, I'll promise that I will not look\nat or comment on patches that are sent to the list tomorrow (or in\nthe coming few days), except that a reroll of an existing topic will\nbe taken as a sign that the stale version I have in my tree needs to\nbe replaced before it can be merged to 'next' (but I won't pick the\nnew iteration up---I know from experience that it would stall and\ndelay me).\n\n\n\n"},{"id":"442931","messageId":"Yammtm+pIkMu43zZ@coredump.intra.peff.net","threadId":"56998","inReplyTo":"xmqqzgpm2xrd.fsf@gitster.g","subject":"[PATCH 0/3] unused-parameter cleanups on top of pw/xdiff-classify-record-in-histogram","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2021-12-03T05:10:14Z","receivedAt":"2021-12-03T05:10:16Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Nov 29, 2021 at 06:16:54PM -0800, Junio C Hamano wrote:\n\n> * pw/xdiff-classify-record-in-histogram (2021-11-18) 3 commits\n>  - xdiff: simplify comparison\n>  - xdiff: avoid unnecessary memory allocations\n>  - diff histogram: intern strings\n> \n>  \"diff --histogram\" optimization.\n> \n>  Will merge to 'next'.\n\nThis being merged to 'next' tickled my -Wunused-parameter topic, so\nthere were a few more opportunities for cleanup.\n\nDefinitely not urgent, but I think worth doing. Prepared on top of the\ntopic branch.\n\n  [1/3]: xdiff: drop CMP_ENV macro from xhistogram\n  [2/3]: xdiff: drop xpparam_t parameter from histogram cmp_recs()\n  [3/3]: xdiff: drop unused flags parameter from recs_match\n\n xdiff/xdiffi.c     | 18 +++++++++---------\n xdiff/xhistogram.c |  8 ++------\n 2 files changed, 11 insertions(+), 15 deletions(-)\n\n-Peff\n"},{"id":"442932","messageId":"Yamm8xoakNHjEx0E@coredump.intra.peff.net","threadId":"56998","inReplyTo":"Yammtm+pIkMu43zZ@coredump.intra.peff.net","subject":"[PATCH 1/3] xdiff: drop CMP_ENV macro from xhistogram","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2021-12-03T05:11:15Z","receivedAt":"2021-12-03T05:11:18Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"This macro has been unused since 43ca7530df (xdiff/xhistogram: rely on\nxdl_trim_ends(), 2011-08-01). The function that called it went away\nthere, and its use in the CMP() macro was inlined. It probably should\nhave been deleted then, but nobody noticed.\n\nSigned-off-by: Jeff King <peff@peff.net>\n---\nThis one isn't strictly enabled by Phillip's new patches, but it cleans\nup an unused caller of cmp_recs() so we don't have to worry about it in\nthe next patch.\n\n xdiff/xhistogram.c | 3 ---\n 1 file changed, 3 deletions(-)\n\ndiff --git a/xdiff/xhistogram.c b/xdiff/xhistogram.c\nindex 6c1c88a69a..399cc236d7 100644\n--- a/xdiff/xhistogram.c\n+++ b/xdiff/xhistogram.c\n@@ -95,9 +95,6 @@ static int cmp_recs(xpparam_t const *xpp,\n \n }\n \n-#define CMP_ENV(xpp, env, s1, l1, s2, l2) \\\n-\t(cmp_recs(xpp, REC(env, s1, l1), REC(env, s2, l2)))\n-\n #define CMP(i, s1, l1, s2, l2) \\\n \t(cmp_recs(i->xpp, REC(i->env, s1, l1), REC(i->env, s2, l2)))\n \n-- \n2.34.1.436.g8c445b282e\n\n"},{"id":"442933","messageId":"YamnDMhk5GlTcaoZ@coredump.intra.peff.net","threadId":"56998","inReplyTo":"Yammtm+pIkMu43zZ@coredump.intra.peff.net","subject":"[PATCH 2/3] xdiff: drop xpparam_t parameter from histogram cmp_recs()","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2021-12-03T05:11:40Z","receivedAt":"2021-12-03T05:11:48Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"Since 663c5ad035 (diff histogram: intern strings, 2021-11-17), our\ncmp_recs() does not call xdl_recmatch(), and thus no longer needs an\nxpparam_t struct from which to get the flags. We can drop the unused\nparameter from the function, as well as the macro which wraps it.\n\nThere's no functional change here; it's just simplifying things (and\nmaking -Wunused-parameter happier).\n\nSigned-off-by: Jeff King <peff@peff.net>\n---\n xdiff/xhistogram.c | 5 ++---\n 1 file changed, 2 insertions(+), 3 deletions(-)\n\ndiff --git a/xdiff/xhistogram.c b/xdiff/xhistogram.c\nindex 399cc236d7..80794748b0 100644\n--- a/xdiff/xhistogram.c\n+++ b/xdiff/xhistogram.c\n@@ -88,15 +88,14 @@ struct region {\n #define REC(env, s, l) \\\n \t(env->xdf##s.recs[l - 1])\n \n-static int cmp_recs(xpparam_t const *xpp,\n-\txrecord_t *r1, xrecord_t *r2)\n+static int cmp_recs(xrecord_t *r1, xrecord_t *r2)\n {\n \treturn r1->ha == r2->ha;\n \n }\n \n #define CMP(i, s1, l1, s2, l2) \\\n-\t(cmp_recs(i->xpp, REC(i->env, s1, l1), REC(i->env, s2, l2)))\n+\t(cmp_recs(REC(i->env, s1, l1), REC(i->env, s2, l2)))\n \n #define TABLE_HASH(index, side, line) \\\n \tXDL_HASHLONG((REC(index->env, side, line))->ha, index->table_bits)\n-- \n2.34.1.436.g8c445b282e\n\n"},{"id":"442934","messageId":"YamnIeXz+EscCTZC@coredump.intra.peff.net","threadId":"56998","inReplyTo":"Yammtm+pIkMu43zZ@coredump.intra.peff.net","subject":"[PATCH 3/3] xdiff: drop unused flags parameter from recs_match","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2021-12-03T05:12:01Z","receivedAt":"2021-12-03T05:12:03Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"Since 6b13bc3232 (xdiff: simplify comparison, 2021-11-17), we do not\ncall xdl_recmatch() from xdiffi.c's recs_match(), so we no longer need\nthe \"flags\" parameter. That in turn lets us drop the flags parameters\nfrom the group-slide functions which call it.\n\nThere's no functional change here; it's just making these functions a\nlittle simpler.\n\nSigned-off-by: Jeff King <peff@peff.net>\n---\n xdiff/xdiffi.c | 18 +++++++++---------\n 1 file changed, 9 insertions(+), 9 deletions(-)\n\ndiff --git a/xdiff/xdiffi.c b/xdiff/xdiffi.c\nindex 6a3b9280be..69689fab24 100644\n--- a/xdiff/xdiffi.c\n+++ b/xdiff/xdiffi.c\n@@ -390,7 +390,7 @@ static xdchange_t *xdl_add_change(xdchange_t *xscr, long i1, long i2, long chg1,\n }\n \n \n-static int recs_match(xrecord_t *rec1, xrecord_t *rec2, long flags)\n+static int recs_match(xrecord_t *rec1, xrecord_t *rec2)\n {\n \treturn (rec1->ha == rec2->ha);\n }\n@@ -756,10 +756,10 @@ static inline int group_previous(xdfile_t *xdf, struct xdlgroup *g)\n  * following group, expand this group to include it. Return 0 on success or -1\n  * if g cannot be slid down.\n  */\n-static int group_slide_down(xdfile_t *xdf, struct xdlgroup *g, long flags)\n+static int group_slide_down(xdfile_t *xdf, struct xdlgroup *g)\n {\n \tif (g->end < xdf->nrec &&\n-\t    recs_match(xdf->recs[g->start], xdf->recs[g->end], flags)) {\n+\t    recs_match(xdf->recs[g->start], xdf->recs[g->end])) {\n \t\txdf->rchg[g->start++] = 0;\n \t\txdf->rchg[g->end++] = 1;\n \n@@ -777,10 +777,10 @@ static int group_slide_down(xdfile_t *xdf, struct xdlgroup *g, long flags)\n  * into a previous group, expand this group to include it. Return 0 on success\n  * or -1 if g cannot be slid up.\n  */\n-static int group_slide_up(xdfile_t *xdf, struct xdlgroup *g, long flags)\n+static int group_slide_up(xdfile_t *xdf, struct xdlgroup *g)\n {\n \tif (g->start > 0 &&\n-\t    recs_match(xdf->recs[g->start - 1], xdf->recs[g->end - 1], flags)) {\n+\t    recs_match(xdf->recs[g->start - 1], xdf->recs[g->end - 1])) {\n \t\txdf->rchg[--g->start] = 1;\n \t\txdf->rchg[--g->end] = 0;\n \n@@ -830,7 +830,7 @@ int xdl_change_compact(xdfile_t *xdf, xdfile_t *xdfo, long flags) {\n \t\t\tend_matching_other = -1;\n \n \t\t\t/* Shift the group backward as much as possible: */\n-\t\t\twhile (!group_slide_up(xdf, &g, flags))\n+\t\t\twhile (!group_slide_up(xdf, &g))\n \t\t\t\tif (group_previous(xdfo, &go))\n \t\t\t\t\tBUG(\"group sync broken sliding up\");\n \n@@ -845,7 +845,7 @@ int xdl_change_compact(xdfile_t *xdf, xdfile_t *xdfo, long flags) {\n \n \t\t\t/* Now shift the group forward as far as possible: */\n \t\t\twhile (1) {\n-\t\t\t\tif (group_slide_down(xdf, &g, flags))\n+\t\t\t\tif (group_slide_down(xdf, &g))\n \t\t\t\t\tbreak;\n \t\t\t\tif (group_next(xdfo, &go))\n \t\t\t\t\tBUG(\"group sync broken sliding down\");\n@@ -872,7 +872,7 @@ int xdl_change_compact(xdfile_t *xdf, xdfile_t *xdfo, long flags) {\n \t\t\t * other file that it can align with.\n \t\t\t */\n \t\t\twhile (go.end == go.start) {\n-\t\t\t\tif (group_slide_up(xdf, &g, flags))\n+\t\t\t\tif (group_slide_up(xdf, &g))\n \t\t\t\t\tBUG(\"match disappeared\");\n \t\t\t\tif (group_previous(xdfo, &go))\n \t\t\t\t\tBUG(\"group sync broken sliding to match\");\n@@ -915,7 +915,7 @@ int xdl_change_compact(xdfile_t *xdf, xdfile_t *xdfo, long flags) {\n \t\t\t}\n \n \t\t\twhile (g.end > best_shift) {\n-\t\t\t\tif (group_slide_up(xdf, &g, flags))\n+\t\t\t\tif (group_slide_up(xdf, &g))\n \t\t\t\t\tBUG(\"best shift unreached\");\n \t\t\t\tif (group_previous(xdfo, &go))\n \t\t\t\t\tBUG(\"group sync broken sliding to blank line\");\n-- \n2.34.1.436.g8c445b282e\n"},{"id":"443014","messageId":"211203.861r2tsfej.gmgdl@evledraar.gmail.com","threadId":"56998","inReplyTo":"CABPp-BG9jHaJYekDnvZT+8QW_fLGM_bmz-oOqzJswaotyVDFBA@mail.gmail.com","subject":"Re: What's cooking in git.git (Nov 2021, #07; Mon, 29)","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2021-12-03T18:21:57Z","receivedAt":"2021-12-03T18:38:00Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Wed, Dec 01 2021, Elijah Newren wrote:\n\n> On Tue, Nov 30, 2021 at 5:42 PM Aleen 徐沛文 <pwxu@coremail.cn> wrote:\n>>\n>> > Please don't, at least not this version.  There have been newer\n>> > submissions with three commits.\n>> >\n>> > I also still find the word 'die' confusing, since to me it suggests\n>> > aborting the whole am operation, and the documentation does not dispel\n>> > that concern.  Even if you don't like 'ask' (for consistency with\n>> > git-rebase), I think 'stop' or 'interrupt' would be much better\n>> > options than 'die'.  If you really want it to be 'die', I think the\n>> > behavior needs to be explained in the documentation, rather than just\n>> > assumed that users will understand it (because I didn't understand it\n>> > until I read the code).\n>>\n>> Dears Newren,\n>>\n>>     I don't think 'stop' and 'interrupt' words are better to explain more than 'die'\n>>     because they still indicate that it will stop or interrupt the whole am session,\n>>     rather than stop in the middle of it.\n>\n> Since you've been through several rounds of revisions already, if this\n> is the only remaining issue with your series, I wouldn't try to hold\n> it up for this issue; I just thought it could be fixed while you were\n> working on the --allow-empty stuff.\n\nFWIW I think it's worth getting the UX issue right, tweaking it is\nrelatively easy, and if we can decide on what the thing is called\nthen...\n\n> However, while I don't think it's worth holding up your series for\n> just this issue, I would definitely submit a follow-up RFC patch to\n> fix the wording, because I do disagree with your assertion here pretty\n> strongly.  Let's look at the meanings of the terms:\n>\n> die: connotes something pretty final and irreversible -- people tend\n> not to revive after death as far as recorded history goes; most such\n> recorded instances tend to be causes for people to debate the\n> definition of 'dead'.\n>\n> stop: could be final, but is often used in a transitory setting: \"stop\n> and go traffic\", \"stopped to catch my breath\",  \"the train will stop\n> at this station\", \"stop! I want to get out\", etc.\n>\n> interrupt: seems to nearly always be used as a transitory thing\n>\n> Now, in the computer science context, all three terms come up relative\n> to processes.  You can interrupt a process (the kernel does all the\n> time), but it'll usually continue afterwards.  Or you can give it a\n> SIGINT (interrupt from keyboard signal), which the process can catch\n> and ignore.  You can stop a process (and SIGSTOP cannot be caught),\n> but you can also continue it later.  die essentially means the process\n> is going to be gone for good (at least short of some kind of black\n> magic like a reversible debugger such as rr).\n>\n> So, I think it's much more likely that 'die' will be misunderstood to\n> mean abortion of the entire am-process, than that 'stop' or\n> 'interrupt' would.\n\nWhy are we exposing an --empty=die at all? It's what we do by default,\nso why have it? The user can just not provide the \"--empty\" option, then\nthey'll get the current behavior of die_user_resolve(), which seems to\nhave inpired the name for this \"die\" (it exits with code 128, just like\ndie()).\n\nOnce we get rid of \"die\" the rest of the UI can follow the example of\nthe existing \"git rebase\" options:\n\n    --empty={drop,keep,ask}\n\nI.e. the \"drop\" and \"keep\" will be the same, no \"ask\" currently, but it\ncan be implemented in the future.\n\nMaybe I'm missing something, I haven't used \"am\" in this way (or rebase\nwith --empty=*), but this just seems to me to be needlessly exposing a\n\"die\" (or \"stop\" or whatever) because it's how we implement this.\n\nWhereas for the UX we don't need to call it anything except the absence\nof an --empty option, or perhaps --no-empty.\n"},{"id":"443017","messageId":"xmqqa6hhsdee.fsf@gitster.g","threadId":"56998","inReplyTo":"CABPp-BHq4DnkCZZ+HcnGiZYKHpWJgzMBjMDuWbbTFYPesm2sXA@mail.gmail.com","subject":"Re: ns/tmp-objdir and ns/remerge-diff","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-12-03T19:21:13Z","receivedAt":"2021-12-03T19:21:17Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Elijah Newren <newren@gmail.com> writes:\n\n> ns/tmp-objdir had a re-roll that has not been picked up, at [1] --\n> perhaps because it's an combination of ns/tmp-objdir and\n> ns/batched-fsync (it'd be nicer to have those two split).  I gave the\n> ns/tmp-objdir part another read over and was only able to spot two\n> small things.  I think you should mark it as expecting a reroll based\n> on [2] (\"Good catch. I'll fix this.\") and [3] (\"I'll take this\n> suggestion.\"), but I think it could be merged to next quickly after\n> that.\n>\n> [1] https://lore.kernel.org/git/pull.1076.v9.git.git.1637020263.gitgitgadget@gmail.com/\n> [2] https://lore.kernel.org/git/CANQDOddCC7+gGUy1VBxxwvN7ieP+N8mQhbxK2xx6ySqZc6U7-g@mail.gmail.com/\n> [3] https://lore.kernel.org/git/CANQDOdd7EHUqD_JBdO9ArpvOQYUnU9GSL6EVR7W7XXgNASZyhQ@mail.gmail.com/\n>\n>>  Also ns/remerge-diff that is Neeraj's rebase of the\n>> remerge-diff topic needs Elijah's Ack at least.\n>\n> Mark it as expecting a re-roll; I've been waiting for ns/tmp-objdir to\n> settle so I can rebase on it.\n\nI took a quick look at the rerolled one on list, and I agree that\nkeeping tmp-objdir and batched-fsync as two separate topics makes\nsense, since the former can graduate much more smoothly and quickly,\nand it can have other dependant topics.\n\nSo I'll mark all three (ns/tmp-objdir, ns/batched-fsync and\nremerge-diff) as \"Expecting a reroll\".\n\nAs I announced, I won't be taking any new topics or new rerolls\ntoday (or possibly tomorrow) until I can sift the topics I've\nalready seen to come up with a tested set of candidate topics to\nmerge to 'next', so there is no need to rush.\n\nThanks.\n"},{"id":"443019","messageId":"CABPp-BGE5Ff=adH3nREMDm38DGLEmtRTcPwuJowHw-ckwpbmqQ@mail.gmail.com","threadId":"56998","inReplyTo":"211203.861r2tsfej.gmgdl@evledraar.gmail.com","subject":"Re: What's cooking in git.git (Nov 2021, #07; Mon, 29)","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2021-12-03T19:28:44Z","receivedAt":"2021-12-03T19:28:58Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Fri, Dec 3, 2021 at 10:37 AM Ævar Arnfjörð Bjarmason\n<avarab@gmail.com> wrote:\n>\n> On Wed, Dec 01 2021, Elijah Newren wrote:\n>\n> > On Tue, Nov 30, 2021 at 5:42 PM Aleen 徐沛文 <pwxu@coremail.cn> wrote:\n> >>\n> >> > Please don't, at least not this version.  There have been newer\n> >> > submissions with three commits.\n> >> >\n> >> > I also still find the word 'die' confusing, since to me it suggests\n> >> > aborting the whole am operation, and the documentation does not dispel\n> >> > that concern.  Even if you don't like 'ask' (for consistency with\n> >> > git-rebase), I think 'stop' or 'interrupt' would be much better\n> >> > options than 'die'.  If you really want it to be 'die', I think the\n> >> > behavior needs to be explained in the documentation, rather than just\n> >> > assumed that users will understand it (because I didn't understand it\n> >> > until I read the code).\n> >>\n> >> Dears Newren,\n> >>\n> >>     I don't think 'stop' and 'interrupt' words are better to explain more than 'die'\n> >>     because they still indicate that it will stop or interrupt the whole am session,\n> >>     rather than stop in the middle of it.\n> >\n> > Since you've been through several rounds of revisions already, if this\n> > is the only remaining issue with your series, I wouldn't try to hold\n> > it up for this issue; I just thought it could be fixed while you were\n> > working on the --allow-empty stuff.\n>\n> FWIW I think it's worth getting the UX issue right, tweaking it is\n> relatively easy, and if we can decide on what the thing is called\n> then...\n\n:-)\n\n> > However, while I don't think it's worth holding up your series for\n> > just this issue, I would definitely submit a follow-up RFC patch to\n> > fix the wording, because I do disagree with your assertion here pretty\n> > strongly.  Let's look at the meanings of the terms:\n> >\n> > die: connotes something pretty final and irreversible -- people tend\n> > not to revive after death as far as recorded history goes; most such\n> > recorded instances tend to be causes for people to debate the\n> > definition of 'dead'.\n> >\n> > stop: could be final, but is often used in a transitory setting: \"stop\n> > and go traffic\", \"stopped to catch my breath\",  \"the train will stop\n> > at this station\", \"stop! I want to get out\", etc.\n> >\n> > interrupt: seems to nearly always be used as a transitory thing\n> >\n> > Now, in the computer science context, all three terms come up relative\n> > to processes.  You can interrupt a process (the kernel does all the\n> > time), but it'll usually continue afterwards.  Or you can give it a\n> > SIGINT (interrupt from keyboard signal), which the process can catch\n> > and ignore.  You can stop a process (and SIGSTOP cannot be caught),\n> > but you can also continue it later.  die essentially means the process\n> > is going to be gone for good (at least short of some kind of black\n> > magic like a reversible debugger such as rr).\n> >\n> > So, I think it's much more likely that 'die' will be misunderstood to\n> > mean abortion of the entire am-process, than that 'stop' or\n> > 'interrupt' would.\n>\n> Why are we exposing an --empty=die at all? It's what we do by default,\n> so why have it? The user can just not provide the \"--empty\" option, then\n> they'll get the current behavior of die_user_resolve(), which seems to\n> have inpired the name for this \"die\" (it exits with code 128, just like\n> die()).\n\nThat's an interesting angle to take; I hadn't thought of that.  It's\nworth considering.\n\nWe do often introduce options equivalent to the default as a way to\neither countermand an earlier option (e.g. --do-walk overrides\n--no-walk in git log), or because we want to allow new config options\nthat change the default while allowing the user to explicitly request\nsomething different (e.g. --no-renames was introduced at the same time\nas diff.renames), or because we may want to change the default\nbehavior and want users to be able to explicitly request a certain\ntype of behavior (e.g. rename detection is the default and\n--no-renames overrides).\n\nIt's not clear to me whether that type of flexibility is needed or\nwhether we can just leave it unnamed.  Three points that may affect\nthat decision: (a) the default (and actually, hardcoded) behavior\nbefore this series for git-am was 'drop', (b)  the default behavior\nfor git-rebase is 'drop' (though it only affects commits which become\nempty, something we can't determine in the context of am) and (c)\nthere was one point during the series that the author asked about just\nremoving the 'die' implementation and picking a different default.\n\nThe above three points suggest to me that there might reasonably be\nconfig added to control this or that the default could change, and\nthus that it might be useful to name the interrupt-the-operation\nbehavior so that users can explicitly request it.  But that's\nsomewhere around three levels of chained \"might\" conditions, so...\n:shrug:\n\n> Once we get rid of \"die\" the rest of the UI can follow the example of\n> the existing \"git rebase\" options:\n>\n>     --empty={drop,keep,ask}\n>\n> I.e. the \"drop\" and \"keep\" will be the same, no \"ask\" currently, but it\n> can be implemented in the future.\n\nUm, there are minor contextual differences, but what rebase calls\n\"ask\" (interrupt the operation and tell the users what commands they\ncan use to keep or drop the commit and then resume the operation) _is_\nimplemented by this series -- it's just being called \"die\" here.\n\nThat's the kind of maddening inconsistency in Git that users complain\nabout that I really think we should avoid adding to.  If for some\nreason 'ask' from rebase seems like a bad choice, then I think we\nshould pick a new name for this interrupt-the-operation behavior that\nmakes sense (unlike 'die') for git-am and add it to git-rebase as a\npreferred synonym to 'ask'.\n\n> Maybe I'm missing something, I haven't used \"am\" in this way (or rebase\n> with --empty=*), but this just seems to me to be needlessly exposing a\n> \"die\" (or \"stop\" or whatever) because it's how we implement this.\n>\n> Whereas for the UX we don't need to call it anything except the absence\n> of an --empty option, or perhaps --no-empty.\n\n`--no-empty` would semantically be read by users to mean get rid of\nempty commits, which would be a synonym of 'drop'.  I think it'd be as\nconfusing as 'die' (and maybe even more so) for naming the\ninterrupt-the-operation behavior.\n"},{"id":"443023","messageId":"211203.86wnklqx05.gmgdl@evledraar.gmail.com","threadId":"56998","inReplyTo":"CABPp-BGE5Ff=adH3nREMDm38DGLEmtRTcPwuJowHw-ckwpbmqQ@mail.gmail.com","subject":"Re: What's cooking in git.git (Nov 2021, #07; Mon, 29)","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2021-12-03T19:56:43Z","receivedAt":"2021-12-03T20:00:47Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Fri, Dec 03 2021, Elijah Newren wrote:\n\n> On Fri, Dec 3, 2021 at 10:37 AM Ævar Arnfjörð Bjarmason\n> <avarab@gmail.com> wrote:\n>>\n>> On Wed, Dec 01 2021, Elijah Newren wrote:\n>>\n>> > On Tue, Nov 30, 2021 at 5:42 PM Aleen 徐沛文 <pwxu@coremail.cn> wrote:\n>> >>\n>> >> > Please don't, at least not this version.  There have been newer\n>> >> > submissions with three commits.\n>> >> >\n>> >> > I also still find the word 'die' confusing, since to me it suggests\n>> >> > aborting the whole am operation, and the documentation does not dispel\n>> >> > that concern.  Even if you don't like 'ask' (for consistency with\n>> >> > git-rebase), I think 'stop' or 'interrupt' would be much better\n>> >> > options than 'die'.  If you really want it to be 'die', I think the\n>> >> > behavior needs to be explained in the documentation, rather than just\n>> >> > assumed that users will understand it (because I didn't understand it\n>> >> > until I read the code).\n>> >>\n>> >> Dears Newren,\n>> >>\n>> >>     I don't think 'stop' and 'interrupt' words are better to explain more than 'die'\n>> >>     because they still indicate that it will stop or interrupt the whole am session,\n>> >>     rather than stop in the middle of it.\n>> >\n>> > Since you've been through several rounds of revisions already, if this\n>> > is the only remaining issue with your series, I wouldn't try to hold\n>> > it up for this issue; I just thought it could be fixed while you were\n>> > working on the --allow-empty stuff.\n>>\n>> FWIW I think it's worth getting the UX issue right, tweaking it is\n>> relatively easy, and if we can decide on what the thing is called\n>> then...\n>\n> :-)\n>\n>> > However, while I don't think it's worth holding up your series for\n>> > just this issue, I would definitely submit a follow-up RFC patch to\n>> > fix the wording, because I do disagree with your assertion here pretty\n>> > strongly.  Let's look at the meanings of the terms:\n>> >\n>> > die: connotes something pretty final and irreversible -- people tend\n>> > not to revive after death as far as recorded history goes; most such\n>> > recorded instances tend to be causes for people to debate the\n>> > definition of 'dead'.\n>> >\n>> > stop: could be final, but is often used in a transitory setting: \"stop\n>> > and go traffic\", \"stopped to catch my breath\",  \"the train will stop\n>> > at this station\", \"stop! I want to get out\", etc.\n>> >\n>> > interrupt: seems to nearly always be used as a transitory thing\n>> >\n>> > Now, in the computer science context, all three terms come up relative\n>> > to processes.  You can interrupt a process (the kernel does all the\n>> > time), but it'll usually continue afterwards.  Or you can give it a\n>> > SIGINT (interrupt from keyboard signal), which the process can catch\n>> > and ignore.  You can stop a process (and SIGSTOP cannot be caught),\n>> > but you can also continue it later.  die essentially means the process\n>> > is going to be gone for good (at least short of some kind of black\n>> > magic like a reversible debugger such as rr).\n>> >\n>> > So, I think it's much more likely that 'die' will be misunderstood to\n>> > mean abortion of the entire am-process, than that 'stop' or\n>> > 'interrupt' would.\n>>\n>> Why are we exposing an --empty=die at all? It's what we do by default,\n>> so why have it? The user can just not provide the \"--empty\" option, then\n>> they'll get the current behavior of die_user_resolve(), which seems to\n>> have inpired the name for this \"die\" (it exits with code 128, just like\n>> die()).\n>\n> That's an interesting angle to take; I hadn't thought of that.  It's\n> worth considering.\n>\n> We do often introduce options equivalent to the default as a way to\n> either countermand an earlier option (e.g. --do-walk overrides\n> --no-walk in git log), or because we want to allow new config options\n> that change the default while allowing the user to explicitly request\n> something different (e.g. --no-renames was introduced at the same time\n> as diff.renames), or because we may want to change the default\n> behavior and want users to be able to explicitly request a certain\n> type of behavior (e.g. rename detection is the default and\n> --no-renames overrides).\n>\n> It's not clear to me whether that type of flexibility is needed or\n> whether we can just leave it unnamed.  Three points that may affect\n> that decision: (a) the default (and actually, hardcoded) behavior\n> before this series for git-am was 'drop', (b)  the default behavior\n> for git-rebase is 'drop' (though it only affects commits which become\n> empty, something we can't determine in the context of am) and (c)\n> there was one point during the series that the author asked about just\n> removing the 'die' implementation and picking a different default.\n>\n> The above three points suggest to me that there might reasonably be\n> config added to control this or that the default could change, and\n> thus that it might be useful to name the interrupt-the-operation\n> behavior so that users can explicitly request it.  But that's\n> somewhere around three levels of chained \"might\" conditions, so...\n> :shrug:\n>\n>> Once we get rid of \"die\" the rest of the UI can follow the example of\n>> the existing \"git rebase\" options:\n>>\n>>     --empty={drop,keep,ask}\n>>\n>> I.e. the \"drop\" and \"keep\" will be the same, no \"ask\" currently, but it\n>> can be implemented in the future.\n>\n> Um, there are minor contextual differences, but what rebase calls\n> \"ask\" (interrupt the operation and tell the users what commands they\n> can use to keep or drop the commit and then resume the operation) _is_\n> implemented by this series -- it's just being called \"die\" here.\n>\n> That's the kind of maddening inconsistency in Git that users complain\n> about that I really think we should avoid adding to.  If for some\n> reason 'ask' from rebase seems like a bad choice, then I think we\n> should pick a new name for this interrupt-the-operation behavior that\n> makes sense (unlike 'die') for git-am and add it to git-rebase as a\n> preferred synonym to 'ask'.\n>\n>> Maybe I'm missing something, I haven't used \"am\" in this way (or rebase\n>> with --empty=*), but this just seems to me to be needlessly exposing a\n>> \"die\" (or \"stop\" or whatever) because it's how we implement this.\n>>\n>> Whereas for the UX we don't need to call it anything except the absence\n>> of an --empty option, or perhaps --no-empty.\n>\n> `--no-empty` would semantically be read by users to mean get rid of\n> empty commits, which would be a synonym of 'drop'.  I think it'd be as\n> confusing as 'die' (and maybe even more so) for naming the\n> interrupt-the-operation behavior.\n\nAh, I didn't look into the finer details. Yes if it does maps to \"ask\"\nin rebase we could just use that, so would this be consistent?:\n\n    --empty=die -> --empty=ask\n    --empty=drop -> (ditto, no change)\n    --empty=keep -> (ditto, no change)\n\nI think \"ask\" is a bit of a weird term for this, but I think consistency\ntrumps a while-we're-at-it fix here.\n\nWhatever new synonym we'd come up with (if that would be justified, that\nitself would add to confusion) could be done as a follow-up and\nimplemented for both \"rebase\" and \"am\".\n"},{"id":"443059","messageId":"20211204025820.GA17138@neerajsi-x1.localdomain","threadId":"56998","inReplyTo":"xmqqa6hhsdee.fsf@gitster.g","subject":"Re: ns/tmp-objdir and ns/remerge-diff","fromName":"Neeraj Singh","fromEmail":"nksingh85@gmail.com","sentAt":"2021-12-04T02:58:20Z","receivedAt":"2021-12-04T02:58:24Z","isPatch":false,"sender":{"key":"nksingh85@gmail.com","avatar":null},"body":"On Fri, Dec 03, 2021 at 11:21:13AM -0800, Junio C Hamano wrote:\n> Elijah Newren <newren@gmail.com> writes:\n> \n> > ns/tmp-objdir had a re-roll that has not been picked up, at [1] --\n> > perhaps because it's an combination of ns/tmp-objdir and\n> > ns/batched-fsync (it'd be nicer to have those two split).  I gave the\n> > ns/tmp-objdir part another read over and was only able to spot two\n> > small things.  I think you should mark it as expecting a reroll based\n> > on [2] (\"Good catch. I'll fix this.\") and [3] (\"I'll take this\n> > suggestion.\"), but I think it could be merged to next quickly after\n> > that.\n> >\n> > [1] https://lore.kernel.org/git/pull.1076.v9.git.git.1637020263.gitgitgadget@gmail.com/\n> > [2] https://lore.kernel.org/git/CANQDOddCC7+gGUy1VBxxwvN7ieP+N8mQhbxK2xx6ySqZc6U7-g@mail.gmail.com/\n> > [3] https://lore.kernel.org/git/CANQDOdd7EHUqD_JBdO9ArpvOQYUnU9GSL6EVR7W7XXgNASZyhQ@mail.gmail.com/\n> >\n> >>  Also ns/remerge-diff that is Neeraj's rebase of the\n> >> remerge-diff topic needs Elijah's Ack at least.\n> >\n> > Mark it as expecting a re-roll; I've been waiting for ns/tmp-objdir to\n> > settle so I can rebase on it.\n> \n> I took a quick look at the rerolled one on list, and I agree that\n> keeping tmp-objdir and batched-fsync as two separate topics makes\n> sense, since the former can graduate much more smoothly and quickly,\n> and it can have other dependant topics.\n> \n> So I'll mark all three (ns/tmp-objdir, ns/batched-fsync and\n> remerge-diff) as \"Expecting a reroll\".\n> \n> As I announced, I won't be taking any new topics or new rerolls\n> today (or possibly tomorrow) until I can sift the topics I've\n> already seen to come up with a tested set of candidate topics to\n> merge to 'next', so there is no need to rush.\n> \n> Thanks.\n\nI submitted a new PR (with a new mail thread) for ns/tmp-objdir.  Hopefully\nthat one can sail in smoothly now.\n\nns/batched-fsync will take a bit more time to settle.  I'm going to post a\nnew series called ns/core-fsync, which is focused on the extensible interface\nfor syncing parts of the tree.\n\nThanks,\nNeeraj\n"},{"id":"443067","messageId":"CABPp-BH8grgsKwPpE+7xMVsW5NAeh40y1fHUKvqRD4ZNa2kX1Q@mail.gmail.com","threadId":"56998","inReplyTo":"20211204025820.GA17138@neerajsi-x1.localdomain","subject":"Re: ns/tmp-objdir and ns/remerge-diff","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2021-12-04T05:51:18Z","receivedAt":"2021-12-04T05:51:32Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Fri, Dec 3, 2021 at 6:58 PM Neeraj Singh <nksingh85@gmail.com> wrote:\n>\n> On Fri, Dec 03, 2021 at 11:21:13AM -0800, Junio C Hamano wrote:\n> > Elijah Newren <newren@gmail.com> writes:\n> >\n> > > ns/tmp-objdir had a re-roll that has not been picked up, at [1] --\n> > > perhaps because it's an combination of ns/tmp-objdir and\n> > > ns/batched-fsync (it'd be nicer to have those two split).  I gave the\n> > > ns/tmp-objdir part another read over and was only able to spot two\n> > > small things.  I think you should mark it as expecting a reroll based\n> > > on [2] (\"Good catch. I'll fix this.\") and [3] (\"I'll take this\n> > > suggestion.\"), but I think it could be merged to next quickly after\n> > > that.\n> > >\n> > > [1] https://lore.kernel.org/git/pull.1076.v9.git.git.1637020263.gitgitgadget@gmail.com/\n> > > [2] https://lore.kernel.org/git/CANQDOddCC7+gGUy1VBxxwvN7ieP+N8mQhbxK2xx6ySqZc6U7-g@mail.gmail.com/\n> > > [3] https://lore.kernel.org/git/CANQDOdd7EHUqD_JBdO9ArpvOQYUnU9GSL6EVR7W7XXgNASZyhQ@mail.gmail.com/\n> > >\n> > >>  Also ns/remerge-diff that is Neeraj's rebase of the\n> > >> remerge-diff topic needs Elijah's Ack at least.\n> > >\n> > > Mark it as expecting a re-roll; I've been waiting for ns/tmp-objdir to\n> > > settle so I can rebase on it.\n> >\n> > I took a quick look at the rerolled one on list, and I agree that\n> > keeping tmp-objdir and batched-fsync as two separate topics makes\n> > sense, since the former can graduate much more smoothly and quickly,\n> > and it can have other dependant topics.\n> >\n> > So I'll mark all three (ns/tmp-objdir, ns/batched-fsync and\n> > remerge-diff) as \"Expecting a reroll\".\n> >\n> > As I announced, I won't be taking any new topics or new rerolls\n> > today (or possibly tomorrow) until I can sift the topics I've\n> > already seen to come up with a tested set of candidate topics to\n> > merge to 'next', so there is no need to rush.\n> >\n> > Thanks.\n>\n> I submitted a new PR (with a new mail thread) for ns/tmp-objdir.  Hopefully\n> that one can sail in smoothly now.\n\nThanks for sending that out.  I wasn't cc'ed on them, and I'm dealing\nwith multi-day delay of git emails that I'm not cc'ed on, but I read\nthem over on lore.kernel.org/git and those two patches look good and\nappear to me to be ready for next.  :-)\n\n> ns/batched-fsync will take a bit more time to settle.  I'm going to post a\n> new series called ns/core-fsync, which is focused on the extensible interface\n> for syncing parts of the tree.\n"},{"id":"443127","messageId":"30b4169a.18.17d8d589b6d.Coremail.pwxu@coremail.cn","threadId":"56998","inReplyTo":"211203.86wnklqx05.gmgdl@evledraar.gmail.com","subject":"Re: What's cooking in git.git (Nov 2021, #07; Mon, 29)","fromName":"Aleen 徐沛文","fromEmail":"pwxu@coremail.cn","sentAt":"2021-12-06T01:25:34Z","receivedAt":"2021-12-06T01:25:44Z","isPatch":false,"sender":{"key":"pwxu@coremail.cn","avatar":null},"body":"Dears Hamano,\n\n    In my opinion, the '--empty' should act as a strategy option like the\n    'X' option to 'git-rebase'. Since that the default behaviour of not passing\n    the option is stopped in the middle of an am session, should the 'die' value\n    dies the whole process but not the middle state? It may also make it not\n    confusing.\n\nAleen\n\n> On Fri, Dec 03 2021, Elijah Newren wrote:\n> \n> > On Fri, Dec 3, 2021 at 10:37 AM Ævar Arnfjörð Bjarmason\n> > <avarab@gmail.com> wrote:\n> >>\n> >> On Wed, Dec 01 2021, Elijah Newren wrote:\n> >>\n> >> > On Tue, Nov 30, 2021 at 5:42 PM Aleen 徐沛文 <pwxu@coremail.cn> wrote:\n> >> >>\n> >> >> > Please don't, at least not this version.  There have been newer\n> >> >> > submissions with three commits.\n> >> >> >\n> >> >> > I also still find the word 'die' confusing, since to me it suggests\n> >> >> > aborting the whole am operation, and the documentation does not dispel\n> >> >> > that concern.  Even if you don't like 'ask' (for consistency with\n> >> >> > git-rebase), I think 'stop' or 'interrupt' would be much better\n> >> >> > options than 'die'.  If you really want it to be 'die', I think the\n> >> >> > behavior needs to be explained in the documentation, rather than just\n> >> >> > assumed that users will understand it (because I didn't understand it\n> >> >> > until I read the code).\n> >> >>\n> >> >> Dears Newren,\n> >> >>\n> >> >>     I don't think 'stop' and 'interrupt' words are better to explain more than 'die'\n> >> >>     because they still indicate that it will stop or interrupt the whole am session,\n> >> >>     rather than stop in the middle of it.\n> >> >\n> >> > Since you've been through several rounds of revisions already, if this\n> >> > is the only remaining issue with your series, I wouldn't try to hold\n> >> > it up for this issue; I just thought it could be fixed while you were\n> >> > working on the --allow-empty stuff.\n> >>\n> >> FWIW I think it's worth getting the UX issue right, tweaking it is\n> >> relatively easy, and if we can decide on what the thing is called\n> >> then...\n> >\n> > :-)\n> >\n> >> > However, while I don't think it's worth holding up your series for\n> >> > just this issue, I would definitely submit a follow-up RFC patch to\n> >> > fix the wording, because I do disagree with your assertion here pretty\n> >> > strongly.  Let's look at the meanings of the terms:\n> >> >\n> >> > die: connotes something pretty final and irreversible -- people tend\n> >> > not to revive after death as far as recorded history goes; most such\n> >> > recorded instances tend to be causes for people to debate the\n> >> > definition of 'dead'.\n> >> >\n> >> > stop: could be final, but is often used in a transitory setting: \"stop\n> >> > and go traffic\", \"stopped to catch my breath\",  \"the train will stop\n> >> > at this station\", \"stop! I want to get out\", etc.\n> >> >\n> >> > interrupt: seems to nearly always be used as a transitory thing\n> >> >\n> >> > Now, in the computer science context, all three terms come up relative\n> >> > to processes.  You can interrupt a process (the kernel does all the\n> >> > time), but it'll usually continue afterwards.  Or you can give it a\n> >> > SIGINT (interrupt from keyboard signal), which the process can catch\n> >> > and ignore.  You can stop a process (and SIGSTOP cannot be caught),\n> >> > but you can also continue it later.  die essentially means the process\n> >> > is going to be gone for good (at least short of some kind of black\n> >> > magic like a reversible debugger such as rr).\n> >> >\n> >> > So, I think it's much more likely that 'die' will be misunderstood to\n> >> > mean abortion of the entire am-process, than that 'stop' or\n> >> > 'interrupt' would.\n> >>\n> >> Why are we exposing an --empty=die at all? It's what we do by default,\n> >> so why have it? The user can just not provide the \"--empty\" option, then\n> >> they'll get the current behavior of die_user_resolve(), which seems to\n> >> have inpired the name for this \"die\" (it exits with code 128, just like\n> >> die()).\n> >\n> > That's an interesting angle to take; I hadn't thought of that.  It's\n> > worth considering.\n> >\n> > We do often introduce options equivalent to the default as a way to\n> > either countermand an earlier option (e.g. --do-walk overrides\n> > --no-walk in git log), or because we want to allow new config options\n> > that change the default while allowing the user to explicitly request\n> > something different (e.g. --no-renames was introduced at the same time\n> > as diff.renames), or because we may want to change the default\n> > behavior and want users to be able to explicitly request a certain\n> > type of behavior (e.g. rename detection is the default and\n> > --no-renames overrides).\n> >\n> > It's not clear to me whether that type of flexibility is needed or\n> > whether we can just leave it unnamed.  Three points that may affect\n> > that decision: (a) the default (and actually, hardcoded) behavior\n> > before this series for git-am was 'drop', (b)  the default behavior\n> > for git-rebase is 'drop' (though it only affects commits which become\n> > empty, something we can't determine in the context of am) and (c)\n> > there was one point during the series that the author asked about just\n> > removing the 'die' implementation and picking a different default.\n> >\n> > The above three points suggest to me that there might reasonably be\n> > config added to control this or that the default could change, and\n> > thus that it might be useful to name the interrupt-the-operation\n> > behavior so that users can explicitly request it.  But that's\n> > somewhere around three levels of chained \"might\" conditions, so...\n> > :shrug:\n> >\n> >> Once we get rid of \"die\" the rest of the UI can follow the example of\n> >> the existing \"git rebase\" options:\n> >>\n> >>     --empty={drop,keep,ask}\n> >>\n> >> I.e. the \"drop\" and \"keep\" will be the same, no \"ask\" currently, but it\n> >> can be implemented in the future.\n> >\n> > Um, there are minor contextual differences, but what rebase calls\n> > \"ask\" (interrupt the operation and tell the users what commands they\n> > can use to keep or drop the commit and then resume the operation) _is_\n> > implemented by this series -- it's just being called \"die\" here.\n> >\n> > That's the kind of maddening inconsistency in Git that users complain\n> > about that I really think we should avoid adding to.  If for some\n> > reason 'ask' from rebase seems like a bad choice, then I think we\n> > should pick a new name for this interrupt-the-operation behavior that\n> > makes sense (unlike 'die') for git-am and add it to git-rebase as a\n> > preferred synonym to 'ask'.\n> >\n> >> Maybe I'm missing something, I haven't used \"am\" in this way (or rebase\n> >> with --empty=*), but this just seems to me to be needlessly exposing a\n> >> \"die\" (or \"stop\" or whatever) because it's how we implement this.\n> >>\n> >> Whereas for the UX we don't need to call it anything except the absence\n> >> of an --empty option, or perhaps --no-empty.\n> >\n> > `--no-empty` would semantically be read by users to mean get rid of\n> > empty commits, which would be a synonym of 'drop'.  I think it'd be as\n> > confusing as 'die' (and maybe even more so) for naming the\n> > interrupt-the-operation behavior.\n> \n> Ah, I didn't look into the finer details. Yes if it does maps to \"ask\"\n> in rebase we could just use that, so would this be consistent?:\n> \n>     --empty=die -> --empty=ask\n>     --empty=drop -> (ditto, no change)\n>     --empty=keep -> (ditto, no change)\n> \n> I think \"ask\" is a bit of a weird term for this, but I think consistency\n> trumps a while-we're-at-it fix here.\n> \n> Whatever new synonym we'd come up with (if that would be justified, that\n> itself would add to confusion) could be done as a follow-up and\n> implemented for both \"rebase\" and \"am\"."},{"id":"443136","messageId":"xmqqilw2i6w1.fsf@gitster.g","threadId":"56998","inReplyTo":"30b4169a.18.17d8d589b6d.Coremail.pwxu@coremail.cn","subject":"Re: What's cooking in git.git (Nov 2021, #07; Mon, 29)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-12-06T06:28:46Z","receivedAt":"2021-12-06T06:28:50Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Aleen 徐沛文 <pwxu@coremail.cn> writes:\n\n> Dears Hamano,\n>\n>     In my opinion, the '--empty' should act as a strategy option like the\n>     'X' option to 'git-rebase'. Since that the default behaviour of not passing\n>     the option is stopped in the middle of an am session, should the 'die' value\n>     dies the whole process but not the middle state? It may also make it not\n>     confusing.\n\nHmph, unlike \"git rebase\" or \"git merge\", \"git am\" does not employ\ndifferent strategy backends, so \"-X<option>\" would be out of place,\nI would think.\n\nAmong what we already have, what kills the entire session is called\n\"git am --abort\".  Since I do not find it unnatural to say \"'git am'\ndies\" when it stops and gives control back to the user, so that the\nuser can decide what to do next, I am not sure where the aversion to\nthe word comes from (on the other hand, I find 'ask' highly\nunnatural since we do not ask anything---we just throw the control\nback the user).\n\n"},{"id":"443137","messageId":"6fa17536.18b.17d8e7c7a09.Coremail.pwxu@coremail.cn","threadId":"56998","inReplyTo":"xmqqilw2i6w1.fsf@gitster.g","subject":"Re: What's cooking in git.git (Nov 2021, #07; Mon, 29)","fromName":"Aleen 徐沛文","fromEmail":"pwxu@coremail.cn","sentAt":"2021-12-06T06:44:22Z","receivedAt":"2021-12-06T06:44:32Z","isPatch":false,"sender":{"key":"pwxu@coremail.cn","avatar":null},"body":"The confusing point seems why \"git am\" stops into the middle and gives\ncontrol back to the user when passing \"die\". In common cases, \"die\"\nshould stop the whole process, and is it better to distinguish the case\nwhen passing \"die\" from the default behaviour? Like what the following\nsnippet is implemented:\n\n    case ERR_EMPTY_COMMIT:\n        printf_ln(_(\"Patch is empty.\\n\"\n                    \"If you want to record it as an empty commit, run \\\"git am --allow-empty\\\".\"));\n\tdie_user_resolve(state);\n    case DIE_EMPTY_COMMIT:\n        am_destroy(state);\n        die(_(\"Patch is empty.\"));\n        break;\n\n\n> > Dears Hamano,\n> >\n> >     In my opinion, the '--empty' should act as a strategy option like the\n> >     'X' option to 'git-rebase'. Since that the default behaviour of not passing\n> >     the option is stopped in the middle of an am session, should the 'die' value\n> >     dies the whole process but not the middle state? It may also make it not\n> >     confusing.\n> \n> Hmph, unlike \"git rebase\" or \"git merge\", \"git am\" does not employ\n> different strategy backends, so \"-X<option>\" would be out of place,\n> I would think.\n> \n> Among what we already have, what kills the entire session is called\n> \"git am --abort\".  Since I do not find it unnatural to say \"'git am'\n> dies\" when it stops and gives control back to the user, so that the\n> user can decide what to do next, I am not sure where the aversion to\n> the word comes from (on the other hand, I find 'ask' highly\n> unnatural since we do not ask anything---we just throw the control\n> back the user)."},{"id":"443138","messageId":"62165e8.18e.17d8e7e7909.Coremail.pwxu@coremail.cn","threadId":"56998","inReplyTo":"6fa17536.18b.17d8e7c7a09.Coremail.pwxu@coremail.cn","subject":"Re: What's cooking in git.git (Nov 2021, #07; Mon, 29)","fromName":"Aleen 徐沛文","fromEmail":"pwxu@coremail.cn","sentAt":"2021-12-06T06:46:32Z","receivedAt":"2021-12-06T06:46:38Z","isPatch":false,"sender":{"key":"pwxu@coremail.cn","avatar":null},"body":">     case ERR_EMPTY_COMMIT:\n>         printf_ln(_(\"Patch is empty.\\n\"\n>                     \"If you want to record it as an empty commit, run \\\"git am --allow-empty\\\".\"));\n> \tdie_user_resolve(state);\n\nSorry for the missing \"break\" here.\n\n>     case DIE_EMPTY_COMMIT:\n>         am_destroy(state);\n>         die(_(\"Patch is empty.\"));\n>         break;\n"},{"id":"443178","messageId":"xmqqwnkhhck4.fsf@gitster.g","threadId":"56998","inReplyTo":"6fa17536.18b.17d8e7c7a09.Coremail.pwxu@coremail.cn","subject":"Re: What's cooking in git.git (Nov 2021, #07; Mon, 29)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-12-06T17:23:55Z","receivedAt":"2021-12-06T17:23:59Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Aleen 徐沛文 <pwxu@coremail.cn> writes:\n\n> The confusing point seems why \"git am\" stops into the middle and gives\n> control back to the user when passing \"die\". In common cases, \"die\"\n> should stop the whole process, and is it better to distinguish the case\n> when passing \"die\" from the default behaviour? Like what the following\n> snippet is implemented:\n>\n>     case ERR_EMPTY_COMMIT:\n>         printf_ln(_(\"Patch is empty.\\n\"\n>                     \"If you want to record it as an empty commit, run \\\"git am --allow-empty\\\".\"));\n> \tdie_user_resolve(state);\n>     case DIE_EMPTY_COMMIT:\n>         am_destroy(state);\n>         die(_(\"Patch is empty.\"));\n>         break;\n\nSorry, but I am afraid that I still don't get it.  \n\nAs we can see, the ERR_EMPTY_COMMIT case already exists and that is\nthe behaviour we want when we say \"create commits from the messages\nwith patches, stop and give me control back when you see an empty\ncommit, so that I can decide what to do\".  And one of the things you\ncan do at that point is \"am --abort\" that causes the am_destroy() to\nbe called.\n\nThat is very much in line with the behaviour the users are used to\nsee from \"git am\" when it detects conditions other than \"there is no\npatch\" that needs to stop and give control back to the user,\ne.g. when the patch does not apply cleanly or the log message did\nnot pass msg hook.  am_destroy() is destructive, and limiting such a\ndestructive operation to \"am --abort\" would avoid mistakes and\nsurprises.  I do not know where you got \"In common cases, die should\nstop the whole\" from, but it is not a friendly thing to do to our\nusers.\n\nWhy should the \"in addition, stop when there is no patch\", which is\nwhat we already handle just fine, needs to become different?  More\nimportantly, is it worth forcing the users to be aware of the\ndifference and be extra careful to avoid it?\n\nIt is my understanding that the ONLY reason the patch proposes to\nadd an option other than \"skip the step\" and \"create an empty\ncommit\" is to allow an earlier \"--empty=skip\" on the command line to\nbe overridden by a later \"--empty=die\".  If that option does not\nmake the command behave identically to \"--empty=<anything>\" option\non the command line, i.e. ERR_EMPTY_COMMIT case, it does not serve\nthe intended purpose of overriding the earlier option to revert the\nbehaviour back to the default.\n\nBy the way, I agree with an earlier comment (I think it was from Dscho)\nthat these names should say \"${DO_THIS}_ON_EMPTY_COMMIT\"; the above\nwithout \"ON\" feels somewhat strange.\n\nThanks.\n"},{"id":"443181","messageId":"CABPp-BGk9fYqtuYTACmzdXakpV7TP635eqHtHxkoHRT3aa4qFQ@mail.gmail.com","threadId":"56998","inReplyTo":"xmqqilw2i6w1.fsf@gitster.g","subject":"Re: What's cooking in git.git (Nov 2021, #07; Mon, 29)","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2021-12-06T17:37:35Z","receivedAt":"2021-12-06T17:37:49Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Sun, Dec 5, 2021 at 10:28 PM Junio C Hamano <gitster@pobox.com> wrote:\n>\n> Aleen 徐沛文 <pwxu@coremail.cn> writes:\n>\n> > Dears Hamano,\n> >\n> >     In my opinion, the '--empty' should act as a strategy option like the\n> >     'X' option to 'git-rebase'. Since that the default behaviour of not passing\n> >     the option is stopped in the middle of an am session, should the 'die' value\n> >     dies the whole process but not the middle state? It may also make it not\n> >     confusing.\n>\n> Hmph, unlike \"git rebase\" or \"git merge\", \"git am\" does not employ\n> different strategy backends, so \"-X<option>\" would be out of place,\n> I would think.\n>\n> Among what we already have, what kills the entire session is called\n> \"git am --abort\".  Since I do not find it unnatural to say \"'git am'\n> dies\" when it stops and gives control back to the user, so that the\n> user can decide what to do next, I am not sure where the aversion to\n> the word comes from\n\nWhen I first read the documentation, it sounded to me like it was\nimplying an abort.  I find 'die' very unnatural as a way to explain\nthis behavior; it's too strong of a word.\n\n> (on the other hand, I find 'ask' highly\n> unnatural since we do not ask anything---we just throw the control\n> back the user).\n\nOkay, but what about my previous suggestions of 'stop' or 'interrupt'?\n"},{"id":"443183","messageId":"xmqqlf0xhbcc.fsf@gitster.g","threadId":"56998","inReplyTo":"CABPp-BGk9fYqtuYTACmzdXakpV7TP635eqHtHxkoHRT3aa4qFQ@mail.gmail.com","subject":"Re: What's cooking in git.git (Nov 2021, #07; Mon, 29)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-12-06T17:50:11Z","receivedAt":"2021-12-06T17:50:15Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Elijah Newren <newren@gmail.com> writes:\n\n> When I first read the documentation, it sounded to me like it was\n> implying an abort.  I find 'die' very unnatural as a way to explain\n> this behavior; it's too strong of a word.\n\nThe way we currently document \"git am\", we have no word \"die\" used\nanywhere in the page.  The existing mention of the behaviour are\nfound in these places:\n\n    --continue::\n    -r::\n    --resolved::\n            After a patch failure (e.g. attempting to apply\n            conflicting patch), the user has applied it by hand and\n            the index file stores the result of the application.\n            Make a commit using the authorship and commit log\n            extracted from the e-mail message and the current index\n            file, and continue.\n\nThis uses \"failure\", and \"the user has applied\" implies that the\nuser somehow got control back.  We give \"error:\" messages to state\nthat the patch does not apply from apply.c::apply_all_patches() and\nthe caller silently exits, without calling die.\n\n    --show-current-patch[=(diff|raw)]::\n            Show the message at which `git am` has stopped due to\n            conflicts.  If `raw` is specified, show the raw contents of\n            the e-mail message; if `diff`, show the diff portion only.\n            Defaults to `raw`.\n\nThis uses \"has stopped\" to describe the same situation.\n\n>> (on the other hand, I find 'ask' highly\n>> unnatural since we do not ask anything---we just throw the control\n>> back the user).\n>\n> Okay, but what about my previous suggestions of 'stop' or 'interrupt'?\n\nI agree that \"stop\" would be a good word that is already used to\ndescribe \"the command cannot make further progress without\nassistance by the user, so it stops and gives control back\".\n\nAfter that, the user can say \"am --skip\", \"am --abort\", or edit plus\n\"am --continue\".\n\nThanks.\n"},{"id":"443188","messageId":"f91879b0-7767-5406-cd36-885b4b53deab@gmail.com","threadId":"56998","inReplyTo":"Yammtm+pIkMu43zZ@coredump.intra.peff.net","subject":"Re: [PATCH 0/3] unused-parameter cleanups on top of pw/xdiff-classify-record-in-histogram","fromName":"Phillip Wood","fromEmail":"phillip.wood123@gmail.com","sentAt":"2021-12-06T18:59:07Z","receivedAt":"2021-12-06T18:59:12Z","isPatch":true,"sender":{"key":"phillip.wood@dunelm.org.uk","avatar":null},"body":"Hi Peff\n\nOn 03/12/2021 05:10, Jeff King wrote:\n> On Mon, Nov 29, 2021 at 06:16:54PM -0800, Junio C Hamano wrote:\n> \n>> * pw/xdiff-classify-record-in-histogram (2021-11-18) 3 commits\n>>   - xdiff: simplify comparison\n>>   - xdiff: avoid unnecessary memory allocations\n>>   - diff histogram: intern strings\n>>\n>>   \"diff --histogram\" optimization.\n>>\n>>   Will merge to 'next'.\n> \n> This being merged to 'next' tickled my -Wunused-parameter topic, so\n> there were a few more opportunities for cleanup.\n> \n> Definitely not urgent, but I think worth doing. Prepared on top of the\n> topic branch.\n> \n>    [1/3]: xdiff: drop CMP_ENV macro from xhistogram\n>    [2/3]: xdiff: drop xpparam_t parameter from histogram cmp_recs()\n>    [3/3]: xdiff: drop unused flags parameter from recs_match\n\nThanks, all three patches look good to me\n\nBest Wishes\n\nPhillip\n\n>   xdiff/xdiffi.c     | 18 +++++++++---------\n>   xdiff/xhistogram.c |  8 ++------\n>   2 files changed, 11 insertions(+), 15 deletions(-)\n> \n> -Peff\n> \n\n"},{"id":"443217","messageId":"584bbe43.e.17d926d909f.Coremail.pwxu@coremail.cn","threadId":"56998","inReplyTo":"xmqqwnkhhck4.fsf@gitster.g","subject":"Re: What's cooking in git.git (Nov 2021, #07; Mon, 29)","fromName":"Aleen 徐沛文","fromEmail":"pwxu@coremail.cn","sentAt":"2021-12-07T01:06:33Z","receivedAt":"2021-12-07T01:06:44Z","isPatch":false,"sender":{"key":"pwxu@coremail.cn","avatar":null},"body":"Dears Hamano,\n\n    I have doubted that since that the default behaviour is that stopping\n    when meeting commit messages lacking a patch and giving control back\n    to the user, is that necessary to provide duplicated '--empty=die'?\n    Should we just provide '--empty=(drop|keep)'?\n\nAleen\n\n> Sorry, but I am afraid that I still don't get it.  \n> \n> As we can see, the ERR_EMPTY_COMMIT case already exists and that is\n> the behaviour we want when we say \"create commits from the messages\n> with patches, stop and give me control back when you see an empty\n> commit, so that I can decide what to do\".  And one of the things you\n> can do at that point is \"am --abort\" that causes the am_destroy() to\n> be called.\n> \n> That is very much in line with the behaviour the users are used to\n> see from \"git am\" when it detects conditions other than \"there is no\n> patch\" that needs to stop and give control back to the user,\n> e.g. when the patch does not apply cleanly or the log message did\n> not pass msg hook.  am_destroy() is destructive, and limiting such a\n> destructive operation to \"am --abort\" would avoid mistakes and\n> surprises.  I do not know where you got \"In common cases, die should\n> stop the whole\" from, but it is not a friendly thing to do to our\n> users.\n> \n> Why should the \"in addition, stop when there is no patch\", which is\n> what we already handle just fine, needs to become different?  More\n> importantly, is it worth forcing the users to be aware of the\n> difference and be extra careful to avoid it?\n> \n> It is my understanding that the ONLY reason the patch proposes to\n> add an option other than \"skip the step\" and \"create an empty\n> commit\" is to allow an earlier \"--empty=skip\" on the command line to\n> be overridden by a later \"--empty=die\".  If that option does not\n> make the command behave identically to \"--empty=<anything>\" option\n> on the command line, i.e. ERR_EMPTY_COMMIT case, it does not serve\n> the intended purpose of overriding the earlier option to revert the\n> behaviour back to the default.\n> \n> By the way, I agree with an earlier comment (I think it was from Dscho)\n> that these names should say \"${DO_THIS}_ON_EMPTY_COMMIT\"; the above\n> without \"ON\" feels somewhat strange.\n> \n> Thanks.\n"},{"id":"443219","messageId":"xmqqa6hdb3sx.fsf@gitster.g","threadId":"56998","inReplyTo":"584bbe43.e.17d926d909f.Coremail.pwxu@coremail.cn","subject":"Re: What's cooking in git.git (Nov 2021, #07; Mon, 29)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-12-07T01:29:34Z","receivedAt":"2021-12-07T01:31:54Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Aleen 徐沛文 <pwxu@coremail.cn> writes:\n\n>> It is my understanding that the ONLY reason the patch proposes to\n>> add an option other than \"skip the step\" and \"create an empty\n>> commit\" is to allow an earlier \"--empty=skip\" on the command line to\n>> be overridden by a later \"--empty=die\".  If that option does not\n>> make the command behave identically to \"--empty=<anything>\" option\n>> on the command line, i.e. ERR_EMPTY_COMMIT case, it does not serve\n>> the intended purpose of overriding the earlier option to revert the\n>> behaviour back to the default.\n\n[jc: do not top-post, as people read from top to bottom]\n\n>     I have doubted that since that the default behaviour is that stopping\n>     when meeting commit messages lacking a patch and giving control back\n>     to the user, is that necessary to provide duplicated '--empty=die'?\n>     Should we just provide '--empty=(drop|keep)'?\n\nAdding an option that aborts and trashes the state directory is much\nworse than not having a choice other than drop and keep, which is in\nturn a bit worse than having a way to countermand an option that was\ngiven earlier on the command line.\n\nIf we were to have an option other than drop/keep, as Elijah\nsuggested, it may make sense to call it \"stop\" rather than \"die\" (I\nthink \"ask\" is a mistake, as we do not ask anything to the user).\n\n>> By the way, I agree with an earlier comment (I think it was from Dscho)\n>> that these names should say \"${DO_THIS}_ON_EMPTY_COMMIT\"; the above\n>> without \"ON\" feels somewhat strange.\n\nThis still stands, too.\n\nThanks.\n"},{"id":"443220","messageId":"1f1d7b66.4a.17d929d357c.Coremail.pwxu@coremail.cn","threadId":"56998","inReplyTo":"xmqqa6hdb3sx.fsf@gitster.g","subject":"Re: What's cooking in git.git (Nov 2021, #07; Mon, 29)","fromName":"Aleen 徐沛文","fromEmail":"pwxu@coremail.cn","sentAt":"2021-12-07T01:58:36Z","receivedAt":"2021-12-07T01:59:05Z","isPatch":false,"sender":{"key":"pwxu@coremail.cn","avatar":null},"body":"> Adding an option that aborts and trashes the state directory is much\n> worse than not having a choice other than drop and keep, which is in\n> turn a bit worse than having a way to countermand an option that was\n> given earlier on the command line.\n\nAnother option to countermand an option is only meaningful when it can be\napplied as a resume value but not in such a case, I think. \"--empty=<option>\"\nis only kept in each am session, and it seems we can't countermand the option\nafter the session."}]}