{"thread":{"id":"56101","subject":"What's cooking in git.git (Jul 2021, #03; Tue, 13)","startedAt":"2021-07-14T01:07:18Z","lastAt":"2021-08-12T08:35:42Z","messageCount":43,"participants":["Junio C Hamano","Eric Sunshine","Han-Wen Nienhuys","Ævar Arnfjörð Bjarmason","Derrick Stolee","Taylor Blau","Johannes Schindelin","Felipe Contreras","Patrick Steinhardt","Jeff King","Bagas Sanjaya"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"429979","messageId":"xmqqmtqpzosf.fsf@gitster.g","threadId":"56101","inReplyTo":null,"subject":"What's cooking in git.git (Jul 2021, #03; Tue, 13)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-07-14T01:07:12Z","receivedAt":"2021-07-14T01:07:18Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Here 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\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/describe-tests-fix (2021-05-11) 5 commits\n  (merged to 'next' on 2021-07-06 at ba1f7c0364)\n + describe tests: support -C in \"check_describe\"\n + describe tests: fix nested \"test_expect_success\" call\n + describe tests: don't rely on err.actual from \"check_describe\"\n + describe tests: refactor away from glob matching\n + describe tests: improve test for --work-tree & --dirty\n\n Various updates to tests around \"git describe\"\n\n\n* ab/pickaxe-pcre2 (2021-05-11) 22 commits\n  (merged to 'next' on 2021-07-06 at fdb4fdc245)\n + xdiff-interface: replace discard_hunk_line() with a flag\n + xdiff users: use designated initializers for out_line\n + pickaxe -G: don't special-case create/delete\n + pickaxe -G: terminate early on matching lines\n + xdiff-interface: allow early return from xdiff_emit_line_fn\n + xdiff-interface: prepare for allowing early return\n + pickaxe -S: slightly optimize contains()\n + pickaxe: rename variables in has_changes() for brevity\n + pickaxe -S: support content with NULs under --pickaxe-regex\n + pickaxe: assert that we must have a needle under -G or -S\n + pickaxe: refactor function selection in diffcore-pickaxe()\n + perf: add performance test for pickaxe\n + pickaxe/style: consolidate declarations and assignments\n + diff.h: move pickaxe fields together again\n + pickaxe: die when --find-object and --pickaxe-all are combined\n + pickaxe: die when -G and --pickaxe-regex are combined\n + pickaxe tests: add missing test for --no-pickaxe-regex being an error\n + pickaxe tests: test for -G, -S and --find-object incompatibility\n + pickaxe tests: add test for \"log -S\" not being a regex\n + pickaxe tests: add test for diffgrep_consume() internals\n + pickaxe tests: refactor to use test_commit --append --printf\n + grep/pcre2 tests: reword comments referring to kwset\n\n Rewrite the backend for \"diff -G/-S\" to use pcre2 engine when\n available.\n\n\n* ab/pre-auto-gc-hook-test (2021-06-16) 1 commit\n  (merged to 'next' on 2021-07-06 at 305a15ee1d)\n + gc tests: add a test for the \"pre-auto-gc\" hook\n\n Test fix.\n\n\n* bk/doc-commit-typofix (2021-06-28) 1 commit\n  (merged to 'next' on 2021-07-06 at 88580c54ed)\n + Documentation: fix typo in the --patch option of the commit command\n\n Doc typo/grammo-fix.\n\n\n* dc/p4-binary-submit-fix (2021-06-28) 1 commit\n  (merged to 'next' on 2021-07-06 at dec280fdc6)\n + git-p4: fix failed submit by skip non-text data files\n\n Prevent \"git p4\" from failing to submit changes to binary file.\n\n\n* fc/push-simple-updates (2021-06-02) 7 commits\n  (merged to 'next' on 2021-07-06 at 95c114f930)\n + doc: push: explain default=simple correctly\n + push: remove unused code in setup_push_upstream()\n + push: simplify setup_push_simple()\n + push: reorganize setup_push_simple()\n + push: copy code to setup_push_simple()\n + push: hedge code of default=simple\n + push: rename !triangular to same_remote\n (this branch is used by fc/push-simple-updates-cleanup.)\n\n Some code and doc clarification around \"git push\".\n\n\n* fc/push-simple-updates-cleanup (2021-06-02) 13 commits\n  (merged to 'next' on 2021-07-06 at da7fab5dc4)\n + push: don't get a full remote object\n + push: only check same_remote when needed\n + push: remove trivial function\n + push: remove redundant check\n + push: factor out the typical case\n + push: get rid of all the setup_push_* functions\n + push: trivial simplifications\n + push: make setup_push_* return the dst\n + push: only get the branch when needed\n + push: factor out null branch check\n + push: split switch cases\n + push: return immediately in trivial switch case\n + push: create new get_upstream_ref() helper\n (this branch uses fc/push-simple-updates.)\n\n Some more code and doc clarification around \"git push\".\n\n\n* hn/prep-tests-for-reftable (2021-06-02) 22 commits\n  (merged to 'next' on 2021-07-06 at 0d6f79d079)\n + t1415: set REFFILES for test specific to storage format\n + t4202: mark bogus head hash test with REFFILES\n + t7003: check reflog existence only for REFFILES\n + t7900: stop checking for loose refs\n + t1404: mark tests that muck with .git directly as REFFILES.\n + t2017: mark --orphan/logAllRefUpdates=false test as REFFILES\n + t1414: mark corruption test with REFFILES\n + t1407: require REFFILES for for_each_reflog test\n + test-lib: provide test prereq REFFILES\n + t5304: use \"reflog expire --all\" to clear the reflog\n + t5304: restyle: trim empty lines, drop ':' before >\n + t7003: use rev-parse rather than FS inspection\n + t5000: inspect HEAD using git-rev-parse\n + t5000: reformat indentation to the latest fashion\n + t1301: fix typo in error message\n + t1413: use tar to save and restore entire .git directory\n + t1401-symbolic-ref: avoid direct filesystem access\n + t1401: use tar to snapshot and restore repo state\n + t5601: read HEAD using rev-parse\n + t9300: check ref existence using test-helper rather than a file system check\n + t/helper/ref-store: initialize oid in resolve-ref\n + t4202: split testcase for invalid HEAD symref and HEAD hash\n\n Preliminary clean-up of tests before the main reftable changes\n hits the codebase.\n\n\n* jk/union-merge-binary (2021-06-11) 3 commits\n  (merged to 'next' on 2021-07-06 at 5e77055895)\n + ll_union_merge(): rename path_unused parameter\n + ll_union_merge(): pass name labels to ll_xdl_merge()\n + ll_binary_merge(): handle XDL_MERGE_FAVOR_UNION\n\n The \"union\" conflict resolution variant misbehaved when used with\n binary merge driver.\n\n\n* mr/cmake (2021-06-11) 3 commits\n  (merged to 'next' on 2021-07-06 at efc86eb8fb)\n + cmake: add warning for ignored MSGFMT_EXE\n + cmake: create compile_commands.json by default\n + cmake: add knob to disable vcpkg\n\n CMake update.\n\n\n* rs/grep-parser-fix (2021-06-30) 1 commit\n  (merged to 'next' on 2021-07-06 at 8c582fcd64)\n + grep: report missing left operand of --and\n\n \"git grep --and -e foo\" ought to have been diagnosed as an error\n but instead segfaulted, which has been corrected.\n\n\n* zh/cat-file-batch-fix (2021-06-04) 2 commits\n  (merged to 'next' on 2021-07-01 at 28b788e905)\n + cat-file: merge two block into one\n + cat-file: handle trivial --batch format with --batch-all-objects\n (this branch is used by zh/ref-filter-raw-data.)\n\n \"git cat-file --batch-all-objects\"\" misbehaved when \"--batch\" is in\n use and did not ask for certain object traits.\n\n--------------------------------------------------\n[New Topics]\n\n* dl/packet-read-response-end-fix (2021-07-09) 1 commit\n - pkt-line: replace \"stateless separator\" with \"response end\"\n\n Error message update.\n\n Will merge to 'next'.\n\n\n* hj/commit-allow-empty-message (2021-07-09) 2 commits\n - commit: remove irrelavent prompt on `--allow-empty-message`\n - commit: reorganise commit hint strings\n\n \"git commit --allow-empty-message\" won't abort the operation upon\n an empty message, but the hint shown in the editor said otherwise.\n\n Will merge to 'next'.\n\n\n* ab/attribute-format (2021-07-13) 6 commits\n - strbuf.h: add a comment about \"missing\" strftime() checking\n - advice.h: add missing __attribute__((format)) & fix usage\n - *.h: add a few missing __attribute__((format))\n - *.c static functions: add missing __attribute__((format))\n - sequencer.c: move static function to avoid forward decl\n - *.c static functions: don't forward-declare __attribute__\n\n Many \"printf\"-like helper functions we have have been annotated\n with __attribute__() to catch placeholder/parameter mismatches.\n\n Will merge to 'next'.\n\n\n* dl/diff-merge-base (2021-07-12) 1 commit\n - git-diff: fix missing --merge-base docs\n\n \"git diff --merge-base\" documentation has been updated.\n\n Will merge to 'next'.\n\n\n* en/rename-limits-doc (2021-07-12) 3 commits\n - diff: correct warning message when renameLimit exceeded\n - doc: document the special handling of -l0\n - doc: clarify documentation for rename/copy limits\n\n Update documentation on \"git diff -l<n>\" and diff.renameLimit.\n\n Expecting a reroll.\n cf. <c25e29a9-3a15-4079-43fd-b77746927b16@gmail.com>\n cf. <CAPig+cTFoLaUd8+VRsaJuP24C7fnbTTFx0i7PizyasES7K2jdg@mail.gmail.com>\n cf. <CABPp-BHF3Os7fOeaF_EQOo+Bs7f1DXbYr26WmAQrPjv63nq1Pg@mail.gmail.com>\n\n\n* jk/typofix (2021-07-13) 1 commit\n  (merged to 'next' on 2021-07-13 at cce3caa34e)\n + doc/rev-list-options: fix duplicate word typo\n\n Typofix.\n\n Will merge to 'master'.\n\n--------------------------------------------------\n[Stalled]\n\n* hn/reftable (2021-05-20) 27 commits\n . t1404: annotate test cases with REFFILES\n . t1401,t2011: parameterize HEAD.lock for REFTABLE\n . t1301: document what needs to be done for REFTABLE\n . Add \"test-tool dump-reftable\" command.\n . git-prompt: prepare for reftable refs backend\n . Reftable support for git-core\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 . init-db: set the_repository->hash_algo early on\n . hash.h: provide constants for the hash IDs\n . refs/debug: trace into reflog expiry too\n . refs: document reflog_expire_fn's flag argument\n (this branch uses hn/refs-iterator-peel-returns-boolean.)\n\n The \"reftable\" backend for the refs API.\n\n\n* ao/p4-avoid-decoding (2021-04-12) 2 commits\n - git-p4: do not decode data from perforce by default\n - git-p4: avoid decoding more data from perforce\n\n \"git p4\" in Python-2 days used to accept a lot more kinds of data\n from Perforce server as uninterrupted byte sequence, but after\n switching to Python-3, too many things are expected to be in UTF-8,\n which broke traditional use cases.\n\n Waiting for reviews.\n\n\n* tv/p4-fallback-encoding (2021-04-30) 1 commit\n - git-p4: git-p4.fallbackEncoding to specify non UTF-8 charset\n\n \"git p4\" learns the fallbackEncoding configuration variable to\n safely accept changeset descriptions that aren't written in UTF-8.\n\n Waiting for reviews.\n\n--------------------------------------------------\n[Cooking]\n\n* ab/gitignore-discovery-doc (2021-07-06) 1 commit\n  (merged to 'next' on 2021-07-13 at 02f3b3deab)\n + docs: .gitignore parsing is to the top of the repo\n\n Doc update.\n\n Will merge to 'master'.\n\n\n* bc/rev-list-without-commit-line (2021-07-12) 1 commit\n  (merged to 'next' on 2021-07-13 at 1ceed60061)\n + rev-list: add option for --pretty=format without header\n\n \"git rev-list\" learns to omit the \"commit <object-name>\" header\n lines from the output with the `--no-commit-header` option.\n\n Will merge to 'master'.\n\n\n* ab/imap-send-read-everything-simplify (2021-07-07) 1 commit\n  (merged to 'next' on 2021-07-13 at ab59128bfb)\n + imap-send.c: use less verbose strbuf_fread() idiom\n\n Code simplification.\n\n Will merge to 'master'.\n\n\n* ab/pkt-line-tests (2021-07-12) 5 commits\n - test-lib-functions.sh: remove unused [de]packetize() functions\n - tests: replace remaining packetize() with \"test-tool pkt-line\"\n - tests: replace [de]packetize() shell+perl test-tool pkt-line\n - serve tests: use test_cmp in \"protocol violations\" test\n - serve tests: add missing \"extra delim\" test\n\n Update tests to cover a bit more protocol bits and unify two\n similar test helpers into one.\n\n Expecting a reroll for a couple of small \"correctness\" things...\n cf.<YO3+3F5fRONVtqTI@coredump.intra.peff.net>\n\n\n* ab/lib-subtest (2021-07-01) 8 commits\n - test-lib tests: assert 1 exit code, not non-zero\n - test-lib tests: refactor common part of check_sub_test_lib_test*()\n - test-lib tests: avoid subshell for \"test_cmp\" for readability\n - test-lib tests: get rid of copy/pasted mock test code\n - test-lib tests: don't provide a description for the sub-tests\n - test-lib tests: stop using a subshell in write_sub_test_lib_test()\n - test-lib tests: split up \"write and run\" into two functions\n - test-lib tests: move \"run_sub_test\" to a new lib-subtest.sh\n\n Refactor tests on test framework.\n\n Needs review.\n\n\n* ab/struct-init (2021-07-01) 5 commits\n  (merged to 'next' on 2021-07-09 at 8aec33fe39)\n + string-list.h users: change to use *_{nodup,dup}()\n + string-list.[ch]: add a string_list_init_{nodup,dup}()\n + dir.[ch]: replace dir_init() with DIR_INIT\n + *.c *_init(): define in terms of corresponding *_INIT macro\n + *.h: move some *_INIT to designated initializers\n\n Code cleanup around struct_type_init() functions.\n\n Will merge to 'master'.\n\n\n* bc/inactive-submodules (2021-07-02) 1 commit\n - submodule: mark submodules with update=none as inactive\n\n Usability update for inactive submodules.\n\n Under review.\n cf. <fc5ec100-1d42-4199-236e-7a99c9218f38@gmail.com>\n cf. <bf1893ee-6973-d8b2-659e-bb239a0a9ae2@gmail.com>\n\n\n* en/ort-perf-batch-14 (2021-07-13) 7 commits\n - merge-ort: restart merge with cached renames to reduce process entry cost\n - merge-ort: avoid recursing into directories when we don't need to\n - merge-ort: defer recursing into directories when merge base is matched\n - merge-ort: add a handle_deferred_entries() helper function\n - merge-ort: add data structures for allowable trivial directory resolves\n - merge-ort: add some more explanations in collect_merge_info_callback()\n - merge-ort: resolve paths early when we have sufficient information\n\n Further optimization on \"merge -sort\" backend.\n\n Reviews?\n\n\n* ar/help-micro-cleanup (2021-07-06) 1 commit\n  (merged to 'next' on 2021-07-09 at d8e428c6fd)\n + help: convert git_cmd to page in one place\n\n Tiny code clean-up.\n\n Will merge to 'master'.\n\n\n* ar/submodule-helper-include-cleanup (2021-07-06) 1 commit\n  (merged to 'next' on 2021-07-09 at 7e1d15fb86)\n + submodule--helper: remove redundant include\n\n Code clean-up.\n\n Will merge to 'master'.\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 Expecting a reroll.\n\n\n* dd/test-stdout-count-lines (2021-07-06) 3 commits\n  (merged to 'next' on 2021-07-09 at 19200fa2e0)\n + t6402: preserve git exit status code\n + t6400: preserve git ls-files exit status code\n + test-lib-functions: introduce test_stdout_line_count\n\n Tiny test clean-up.\n\n Will merge to 'master'.\n\n\n* hn/refs-iterator-peel-returns-boolean (2021-05-20) 1 commit\n  (merged to 'next' on 2021-07-08 at b9b35881ba)\n + refs: make explicit that ref_iterator_peel returns boolean\n (this branch is used by hn/reftable.)\n\n Tiny API tweak.\n\n Will merge to 'master'.\n\n\n* hn/refs-test-cleanup (2021-07-06) 2 commits\n  (merged to 'next' on 2021-07-09 at ae08de6afc)\n + t7509: avoid direct file access for writing CHERRY_PICK_HEAD\n + t1415: avoid direct filesystem access for writing refs\n\n Test clean-up.\n\n Will merge to 'master'.\n\n\n* ps/perf-with-separate-output-directory (2021-07-02) 1 commit\n - perf: fix when running with TEST_OUTPUT_DIRECTORY\n\n Test update.\n\n What's the status of this one?\n\n\n* rs/khash-alloc-cleanup (2021-07-06) 1 commit\n  (merged to 'next' on 2021-07-09 at a01d1bb8c9)\n + khash: clarify that allocations never fail\n\n Code clean-up.\n\n Will merge to 'master'.\n\n\n* sm/worktree-add-lock (2021-07-12) 3 commits\n - worktree: teach `add` to accept --reason <string> with --lock\n - worktree: mark lock strings with `_()` for translation\n - t2400: clean up '\"add\" worktree with lock' test\n\n \"git worktree add --lock\" learned to record why the worktree is\n locked with a custom message.\n\n Ready?\n\n\n* ab/bundle-doc (2021-07-02) 3 commits\n - bundle doc: elaborate on rev<->ref restriction\n - bundle doc: elaborate on object prerequisites\n - bundle doc: rewrite the \"DESCRIPTION\" section\n\n Doc update.\n\n Expecting a reroll.\n at least for the second patch.\n\n\n* ab/pack-stdin-packs-fix (2021-07-09) 2 commits\n - pack-objects: fix segfault in --stdin-packs option\n - pack-objects tests: cover blindspots in stdin handling\n\n Input validation of \"git pack-objects --stdin-packs\" has been\n corrected.\n\n Ack?\n cf. <YND3h2l10PlnSNGJ@nand.local>\n\n\n* ds/commit-and-checkout-with-sparse-index (2021-07-12) 5 commits\n - checkout: stop expanding sparse indexes\n - sparse-index: recompute cache-tree\n - commit: integrate with sparse-index\n - p2000: compress repo names\n - p2000: add 'git checkout -' test and decrease depth\n (this branch uses ds/status-with-sparse-index.)\n\n \"git checkout\" and \"git commit\" learn to work without unnecessarily\n expanding sparse indexes.\n\n Ready?\n\n\n* en/merge-dir-rename-corner-case-fix (2021-06-30) 3 commits\n  (merged to 'next' on 2021-07-08 at cf7087576e)\n + merge-recursive: handle rename-to-self case\n + merge-ort: ensure we consult df_conflict and path_conflicts\n + t6423: test directory renames causing rename-to-self\n\n The merge code had funny interactions between content based rename\n detection and directory rename detection.\n\n Will merge to 'master'.\n\n\n* ew/many-alternate-optim (2021-07-07) 5 commits\n - oidtree: a crit-bit tree for odb_loose_cache\n - oidcpy_with_padding: constify `src' arg\n - make object_directory.loose_objects_subdir_seen a bitmap\n - avoid strlen via strbuf_addstr in link_alt_odb_entry\n - speed up alt_odb_usable() with many alternates\n\n Optimization for repositories with many alternate object store.\n\n Will merge to 'next'?\n\n\n* jk/log-decorate-optim (2021-07-13) 7 commits\n - load_ref_decorations(): fix decoration with tags\n  (merged to 'next' on 2021-07-08 at a3b6f978ab)\n + add_ref_decoration(): rename s/type/deco_type/\n + load_ref_decorations(): avoid parsing non-tag objects\n + object.h: add lookup_object_by_type() function\n + object.h: expand docstring for lookup_unknown_object()\n + log: avoid loading decorations for userformats that don't need it\n + pretty.h: update and expand docstring for userformat_find_requirements()\n\n Optimize \"git log\" for cases where we wasted cycles to load ref\n decoration data that may not be needed.\n\n Will merge to 'next'.\n\n\n* js/ci-windows-update (2021-07-06) 7 commits\n  (merged to 'next' on 2021-07-13 at 329771e960)\n + ci: accelerate the checkout\n + ci (vs-build): build with NO_GETTEXT\n + artifacts-tar: respect NO_GETTEXT\n + ci (windows): transfer also the Git-tracked files to the test jobs\n + ci: upgrade to using actions/{up,down}load-artifacts v2\n + ci (vs-build): use `cmd` to copy the DLLs, not `powershell`\n + ci: use the new GitHub Action to download git-sdk-64-minimal\n\n GitHub Actions / CI update.\n\n Will merge to 'master'.\n\n\n* js/config-mak-windows-pcre-fix (2021-06-28) 1 commit\n  (merged to 'next' on 2021-07-08 at fe457da682)\n + config.mak.uname: PCRE1 cleanup\n\n Whitespace fix.\n\n Will merge to 'master'.\n\n\n* js/gfw-system-config-loc-fix (2021-06-28) 3 commits\n  (merged to 'next' on 2021-07-08 at 91a090ab50)\n + config: normalize the path of the system gitconfig\n + cmake(windows): set correct path to the system Git config\n + mingw: move Git for Windows' system config where users expect it\n\n Update the location of system-side configuration file on Windows.\n\n Will merge to 'master'.\n\n\n* jt/push-negotiation-fixes (2021-06-28) 3 commits\n - fetch: die on invalid --negotiation-tip hash\n - send-pack: fix push nego. when remote has refs\n - send-pack: fix push.negotiate with remote helper\n\n Bugfix for common ancestor negotiation recently introduced in \"git\n push\" codepath.\n\n Needs review.\n\n\n* ks/submodule-cleanup (2021-06-28) 1 commit\n  (merged to 'next' on 2021-07-08 at 03ba93067f)\n + submodule: remove unnecessary `prefix` based option logic\n\n Code cleanup.\n\n Will merge to 'master'.\n\n\n* tb/midx-use-checksum (2021-06-28) 4 commits\n  (merged to 'next' on 2021-07-08 at bbaac9c721)\n + midx: report checksum mismatches during 'verify'\n + midx: don't reuse corrupt MIDXs when writing\n + commit-graph: rewrite to use checksum_valid()\n + csum-file: introduce checksum_valid()\n\n When rebuilding the multi-pack index file reusing an existing one,\n we used to blindly trust the existing file and ended up carrying\n corrupted data into the updated file, which has been corrected.\n\n Will merge to 'master'.\n\n\n* ab/bundle-updates (2021-07-06) 3 commits\n  (merged to 'next' on 2021-07-08 at 0c9c54fad7)\n + bundle: remove \"ref_list\" in favor of string-list.c API\n + bundle.c: use a temporary variable for OIDs and names\n + bundle cmd: stop leaking memory from parse_options_cmd_bundle()\n\n Code clean-up and leak plugging in \"git bundle\".\n\n Will merge to 'master'.\n\n\n* ab/fetch-negotiate-segv-fix (2021-07-08) 3 commits\n  (merged to 'next' on 2021-07-08 at 30dcd90ea6)\n + fetch: fix segfault in --negotiate-only without --negotiation-tip=*\n + fetch: document the --negotiate-only option\n + send-pack.c: move \"no refs in common\" abort earlier\n\n Code recently added to support common ancestry negotiation during\n \"git push\" did not sanity check its arguments carefully enough.\n\n Will merge to 'master'.\n\n\n* ab/make-delete-on-error (2021-06-29) 1 commit\n  (merged to 'next' on 2021-07-08 at 787d70d2d6)\n + Makefile: add and use the \".DELETE_ON_ERROR\" flag\n\n Use \".DELETE_ON_ERROR\" pseudo target to simplify our Makefile.\n\n Will merge to 'master'.\n\n\n* ab/make-tags-cleanup (2021-06-29) 5 commits\n - Makefile: normalize clobbering & xargs for tags targets\n - Makefile: don't use \"FORCE\" for tags targets\n - Makefile: fix \"cscope\" target to refer to cscope.out\n - Makefile: add QUIET_GEN to \"cscope\" target\n - Makefile: move \".PHONY: cscope\" near its target\n\n Build clean-up for \"make tags\" and friends.\n\n Expecting a reroll.\n Hopefully with a final reroll it would become good enough shape for 'next'?\n cf. <YN5AwdVC3QAcy2tA@coredump.intra.peff.net>\n cf. <67c45b13-df8f-8065-377a-fbd2f80992ee@ramsayjones.plus.com>\n\n\n* ew/mmap-failures (2021-06-29) 1 commit\n  (merged to 'next' on 2021-07-08 at e0e19d5d26)\n + xmmap: inform Linux users of tuning knobs on ENOMEM\n\n Error message update.\n\n Will merge to 'master'.\n\n\n* tb/multi-pack-bitmaps (2021-06-28) 24 commits\n - p5326: perf tests for MIDX bitmaps\n - p5310: extract full and partial bitmap tests\n - midx: respect 'GIT_TEST_MULTI_PACK_INDEX_WRITE_BITMAP'\n - t7700: update to work with MIDX bitmap test knob\n - t5319: don't write MIDX bitmaps in t5319\n - t5310: disable GIT_TEST_MULTI_PACK_INDEX_WRITE_BITMAP\n - t0410: disable GIT_TEST_MULTI_PACK_INDEX_WRITE_BITMAP\n - t5326: test multi-pack bitmap behavior\n - t/helper/test-read-midx.c: add --checksum mode\n - t5310: move some tests to lib-bitmap.sh\n - pack-bitmap: write multi-pack bitmaps\n - pack-bitmap: read multi-pack bitmaps\n - pack-bitmap.c: introduce 'bitmap_is_preferred_refname()'\n - pack-bitmap.c: introduce 'nth_bitmap_object_oid()'\n - pack-bitmap.c: introduce 'bitmap_num_objects()'\n - midx: infer preferred pack when not given one\n - midx: respect 'core.multiPackIndex' when writing\n - midx: clear auxiliary .rev after replacing the MIDX\n - midx: make a number of functions non-static\n - Documentation: describe MIDX-based bitmaps\n - Documentation: build 'technical/bitmap-format' by default\n - pack-bitmap-write.c: free existing bitmaps\n - pack-bitmap-write.c: gracefully fail to write non-closed bitmaps\n - pack-bitmap.c: harden 'test_bitmap_walk()' to check type bitmaps\n\n The reachability bitmap file used to be generated only for a single\n pack, but now we've learned to generate bitmaps for history that\n span across multiple packfiles.\n\n Comments?\n\n\n* ds/status-with-sparse-index (2021-07-12) 15 commits\n - fsmonitor: integrate with sparse index\n - wt-status: expand added sparse directory entries\n - status: use sparse-index throughout\n - status: skip sparse-checkout percentage with sparse-index\n - diff-lib: handle index diffs with sparse dirs\n - dir.c: accept a directory as part of cone-mode patterns\n - unpack-trees: unpack sparse directory entries\n - unpack-trees: rename unpack_nondirectories()\n - unpack-trees: compare sparse directories correctly\n - unpack-trees: preserve cache_bottom\n - t1092: add tests for status/add and sparse files\n - t1092: expand repository data shape\n - t1092: replace incorrect 'echo' with 'cat'\n - sparse-index: include EXTENDED flag when expanding\n - sparse-index: skip indexes with unmerged entries\n (this branch is used by ds/commit-and-checkout-with-sparse-index.)\n\n \"git status\" codepath learned to work with sparsely populated index\n without hydrating it fully.\n\n Expecting a final reroll.\n cf. <e7199fc6-bc7b-f556-c10c-12dee04af287@gmail.com>\n\n\n* ab/config-based-hooks-base (2021-06-29) 33 commits\n - hooks: fix a TOCTOU in \"did we run a hook?\" heuristic\n - receive-pack: convert receive hooks to hook.h\n - post-update: use hook.h library\n - receive-pack: convert 'update' hook to hook.h\n - hooks: allow callers to capture output\n - run-command: allow capturing of collated output\n - reference-transaction: use hook.h to run hooks\n - transport: convert pre-push hook to use config\n - hook: convert 'post-rewrite' hook in sequencer.c to hook.h\n - hook: provide stdin by string_list or callback\n - run-command: add stdin callback for parallelization\n - am: convert 'post-rewrite' hook to hook.h\n - hook: support passing stdin to hooks\n - run-command: allow stdin for run_processes_parallel\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 hook to use config\n - commit: use hook.h to execute hooks\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 - merge: use config-based hooks for post-merge hook\n - hooks: convert 'post-checkout' hook to hook library\n - am: convert applypatch hooks to use config\n - rebase: teach pre-rebase to use hook.h\n - gc: use hook library for pre-auto-gc hook\n - hook: add 'run' subcommand\n - hook-list.h: add a generated list of hooks, like config-list.h\n - hook.c: add a hook_exists() wrapper and use it in bugreport.c\n - hook.[ch]: move find_hook() to this new library\n - Makefile: remove an out-of-date comment\n - Makefile: stop hardcoding {command,config}-list.h\n - Makefile: mark \"check\" target as .PHONY\n\n Restructuring of (a subset of) Emily's config-based-hooks series,\n to demonstrate that a series can be presented as a more logical and\n focused progression.\n\n Waiting for reviews.\n\n\n* ab/doc-retire-alice-bob (2021-06-16) 6 commits\n - pack-protocol doc: use \"www-data\" in place of \"alice\"\n - doc: replace \"alice\" and \"bob\" with \"jdoe\" and \"msmith\"\n - fast-import doc: change \"bob\" in an example to \"file.txt\"\n - daemon doc + code comments: reword \"alice\" example\n - gitcvs-migration doc: replace \"alice\" and \"bob\" with \"you\" and \"www-data\"\n - gittutorial doc: replace \"alice\" and \"bob\" with \"you\" and \"www-data\"\n\n Documentation update to avoid Alice and Bob in contexts where Eve\n does not appear in.\n\n Will discard.\n Let's shelve this one for now, as it does not seem to solve any\n real problems (other than ceasing to use Alice and Bob in contexts\n that do not call for Eve).\n\n\n* en/ort-perf-batch-13 (2021-06-28) 5 commits\n  (merged to 'next' on 2021-07-08 at 39aad121d3)\n + merge-ort: add prefetching for content merges\n + diffcore-rename: use a different prefetch for basename comparisons\n + diffcore-rename: allow different missing_object_cb functions\n + t6421: add tests checking for excessive object downloads during merge\n + promisor-remote: output trace2 statistics for number of objects fetched\n\n Performance tweaks of \"git merge -sort\" around lazy fetching of objects.\n\n Will merge to 'master'.\n\n\n* ab/serve-cleanup (2021-06-28) 8 commits\n - upload-pack.c: convert to new serve.c \"startup\" config cb\n - serve: add support for a \"startup\" git_config() callback\n - serve.c: add trace2 regions for advertise & command\n - serve.c: add call_{advertise,command}() indirection\n - serve: use designated initializers\n - transport: use designated initializers\n - transport: rename \"fetch\" in transport_vtable to \"fetch_refs\"\n - serve: mark has_capability() as static\n\n Code clean-up around \"git serve\".\n\n Expecting a reroll.\n cf. <cover-0.8-00000000000-20210628T191634Z-avarab@gmail.com>\n\n\n* jt/partial-clone-submodule-1 (2021-06-28) 5 commits\n  (merged to 'next' on 2021-07-09 at 2bc8c2c4dd)\n + promisor-remote: teach lazy-fetch in any repo\n + run-command: refactor subprocess env preparation\n + submodule: refrain from filtering GIT_CONFIG_COUNT\n + promisor-remote: support per-repository config\n + repository: move global r_f_p_c to repo struct\n\n Prepare the internals for lazily fetching objects in submodules\n from their promisor remotes.\n\n Will merge to 'master'.\n\n\n* ab/mktag-tests (2021-06-28) 6 commits\n  (merged to 'next' on 2021-07-08 at bfd55b0a38)\n + mktag tests: test fast-export\n + mktag tests: test for-each-ref\n + mktag tests: test update-ref and reachable fsck\n + mktag tests: test hash-object --literally and unreachable fsck\n + mktag tests: invert --no-strict test\n + mktag tests: parse out options in helper\n\n Fill test gaps.\n\n Will merge to 'master'.\n\n\n* ab/show-branch-tests (2021-06-28) 4 commits\n  (merged to 'next' on 2021-07-08 at 47f90868cf)\n + show-branch tests: add missing tests\n + show-branch: don't <COLOR></RESET> for space characters\n + show-branch tests: modernize test code\n + show-branch tests: rename the one \"show-branch\" test file\n\n Fill test gaps.\n\n Will merge to 'master'.\n\n\n* es/superproject-aware-submodules (2021-06-16) 5 commits\n - SQUASH???\n - submodule: cache superproject gitdir during 'update'\n - submodule: cache superproject gitdir during absorbgitdirs\n - introduce submodule.superprojectGitDir cache\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 Waiting for reviews.\n\n\n* en/zdiff3 (2021-06-15) 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 Expecting a reroll.\n cf. <CABPp-BE7-E03+x38EK-=AE5mwwdST+d50hiiud2eY2Nsf3rM5g@mail.gmail.com>\n\n\n* pw/diff-color-moved-fix (2021-06-15) 10 commits\n - diff --color-moved: intern strings\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 zebra coloring\n - diff --color-moved=zebra: fix alternate coloring\n\n Long-overdue correctness and performance update to \"diff\n --color-moved\" feature.\n\n Expecting a reroll.\n cf. <094f5e5f-d447-8867-a9a7-be5c8827bba6@gmail.com>\n\n\n* hn/refs-errno-cleanup (2021-07-07) 6 commits\n - refs: make errno output explicit for refs_resolve_ref_unsafe\n - refs: explicitly return failure_errno from parse_loose_ref_contents\n - refs: add failure_errno to refs_read_raw_ref() signature\n - refs: make errno output explicit for read_raw_ref_fn\n - refs/files-backend: stop setting errno from lock_ref_oid_basic\n - refs: remove EINVAL errno output from specification of read_raw_ref_fn\n\n Futz with the way 'errno' is relied on in the refs API to carry the\n failure modes up the callchain.\n\n Expecting a (hopefully final) reroll.\n cf. <CAFQ2z_NzykfcBSvtHQ10RZWxLP48+qArZk9HbDJQB4tNX-GtYA@mail.gmail.com>\n\n\n* ab/test-tool-cache-cleanup (2021-06-08) 4 commits\n - read-cache perf: add a perf test for refresh_index()\n - test-tool: migrate read-cache-again to parse_options()\n - test-tool: migrate read-cache-perf to parse_options()\n - test-tool: split up test-tool read-cache\n\n Test code shuffling.\n\n Waiting for reviews.\n\n\n* ab/pack-objects-stdin (2021-07-09) 5 commits\n - pack-objects.c: make use of REV_INFO_STDIN_LINE_PROCESS\n - pack-objects.c: do stdin parsing via revision.c's API\n - revision.[ch]: add a \"handle_stdin_line\" API\n - revision.h: refactor \"disable_stdin\" and \"read_from_stdin\"\n - upload-pack: run is_repository_shallow() before setup_revisions()\n\n Introduce handle_stdin_line callback to revision API and uses it.\n\n\n* ar/submodule-add (2021-07-12) 4 commits\n - submodule--helper: introduce add-clone subcommand\n - submodule--helper: refactor module_clone()\n - submodule: prefix die messages with 'fatal'\n - t7400: test failure to add submodule in tracked path\n\n Rewrite of \"git submodule\" in C continues.\n\n Will merge to 'next'.\n\n\n* ds/gender-neutral-doc (2021-06-16) 3 commits\n  (merged to 'next' on 2021-07-09 at 57bb445576)\n + *: fix typos\n + comments: avoid using the gender of our users\n + doc: avoid using the gender of other people\n (this branch is used by ds/gender-neutral-doc-guidelines.)\n\n Update the documentation not to assume users are of certain gender\n and adds to guidelines to do so.\n\n Will merge to 'master'.\n\n\n* ds/gender-neutral-doc-guidelines (2021-06-16) 2 commits\n - SQUASH??? replace neutering tips with that of Æver\n - CodingGuidelines: recommend singular they\n (this branch uses ds/gender-neutral-doc.)\n\n Attempt to give a guideline for gender neutral documentation.\n\n Comments?\n\n\n* gh/gitweb-branch-sort (2021-06-10) 1 commit\n - gitweb: use HEAD as secondary sort key in git_get_heads_list()\n\n Tie-break branches that point at the same object in the list of\n branches on GitWeb to show the one pointed at by HEAD early.\n\n Waiting for reviews.\n\n\n* lh/systemd-timers (2021-07-02) 3 commits\n - maintenance: add support for systemd timers on Linux\n - maintenance: `git maintenance run` learned `--scheduler=<scheduler>`\n - cache.h: Introduce a generic \"xdg_config_home_for(…)\" function\n\n \"git maintenance\" scheduler learned to use systemd timers as a\n possible backend.\n\n Waiting for reviews.\n\n\n* fc/completion-updates (2021-06-07) 4 commits\n - completion: bash: add correct suffix in variables\n - completion: bash: fix for multiple dash commands\n - completion: bash: fix for suboptions with value\n - completion: bash: fix prefix detection in branch.*\n\n Command line completion updates.\n\n Expecting a reroll.\n cf. <60be6f7fa4435_db80d208f2@natae.notmuch>\n\n\n* ab/update-submitting-patches (2021-06-08) 3 commits\n - SubmittingPatches: remove pine-specific hints from MUA hints\n - SubmittingPatches: replace discussion of Travis with GitHub Actions\n - SubmittingPatches: move discussion of Signed-off-by above \"send\"\n\n Reorganize and update the SubmitingPatches document.\n\n Expecting a reroll.\n cf. <20210607172542.GA6312@szeder.dev>\n cf. <nycvar.QRO.7.76.6.2106072346560.55@tvgsbejvaqbjf.bet>\n\n\n* en/ort-perf-batch-12 (2021-06-09) 4 commits\n  (merged to 'next' on 2021-07-08 at 4807694598)\n + merge-ort: miscellaneous touch-ups\n + Fix various issues found in comments\n + diffcore-rename: avoid unnecessary strdup'ing in break_idx\n + merge-ort: replace string_list_df_name_compare with faster alternative\n\n More fix-ups and optimization to \"merge -sort\".\n\n Will merge to 'master'.\n\n\n* zh/ref-filter-raw-data (2021-07-12) 18 commits\n - cat-file: use fast path when using default_format\n - cat-file: create p1006-cat-file.sh\n - ref-filter: remove grab_oid() function\n - cat-file: re-implement --textconv, --filters options\n - cat-file: reuse err buf in batch_object_write()\n - cat-file: reuse ref-filter logic\n - cat-file: change batch_objects parameter name\n - cat-file: add has_object_file() check\n - ref-filter: modify the error message and value in get_object\n - ref-filter: introduce reject_atom()\n - ref-filter: introduce free_ref_array_item_value() function\n - ref-filter: pass get_object() return value to their callers\n - ref-filter: add %(rest) atom\n - ref-filter: use non-const ref_format in *_atom_parser()\n - ref-filter: --format=%(raw) re-support --perl\n - ref-filter: add %(raw) atom\n - ref-filter: add obj-type check in grab contents\n - Merge branch 'zh/cat-file-batch-fix' into zh/ref-filter-raw-data\n\n Prepare the \"ref-filter\" machinery that drives the \"--format\"\n option of \"git for-each-ref\" and its friends to be used in \"git\n cat-file --batch\".\n\n Heavy performance degradation has been observed with this series.\n\n\n* jh/builtin-fsmonitor (2021-07-12) 35 commits\n - BANDAID: sparse fixes\n - t7527: test FS event reporing on MacOS WRT case and Unicode\n - fsmonitor: handle shortname for .git\n - t7527: test status with untracked-cache and fsmonitor--daemon\n - fsmonitor: force update index after large responses\n - fsmonitor: enhance existing comments\n - fsmonitor--daemon: use a cookie file to sync with file system\n - fsmonitor--daemon: periodically truncate list of modified files\n - t7527: create test for fsmonitor--daemon\n - t/perf/p7519: add fsmonitor--daemon test cases\n - t/perf: avoid copying builtin fsmonitor files into test repo\n - t/perf/p7519: speed up test using \"test-tool touch\"\n - t/helper/test-touch: add helper to touch a series of files\n - fsmonitor--daemon: implement handle_client callback\n - fsmonitor-fs-listen-macos: implement FSEvent listener on MacOS\n - fsmonitor-fs-listen-macos: add macos header files for FSEvent\n - fsmonitor-fs-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: do not try to operate on bare repos\n - fsmonitor--daemon: implement 'start' command\n - fsmonitor--daemon: implement 'run' command\n - fsmonitor-fs-listen-macos: stub in backend for MacOS\n - fsmonitor-fs-listen-win32: stub in backend for Windows\n - t/helper/fsmonitor-client: create IPC client to talk to FSMonitor Daemon\n - fsmonitor--daemon: implement 'stop' and 'status' commands\n - fsmonitor--daemon: add a built-in fsmonitor daemon\n - fsmonitor: use IPC to query the builtin FSMonitor daemon\n - fsmonitor: config settings are repository-specific\n - help: include fsmonitor--daemon feature flag in version info\n - fsmonitor-ipc: create client routines for git-fsmonitor--daemon\n - fsmonitor--daemon: update fsmonitor documentation\n - fsmonitor--daemon: man page\n - simple-ipc: preparations for supporting binary messages.\n\n An attempt to write and ship with a watchman equivalent tailored\n for our use.\n\n\n* es/trace2-log-parent-process-name (2021-06-09) 1 commit\n - tr2: log parent process name\n\n trace2 logs learned to show parent process name to see in what\n context Git was invoked.\n\n Expecting a reroll.\n cf. <YNux62he9Mk43Y1B@google.com>\n\n\n* ab/send-email-optim (2021-05-28) 13 commits\n  (merged to 'next' on 2021-07-08 at 35ac315894)\n + perl: nano-optimize by replacing Cwd::cwd() with Cwd::getcwd()\n + send-email: move trivial config handling to Perl\n + perl: lazily load some common Git.pm setup code\n + send-email: lazily load modules for a big speedup\n + send-email: get rid of indirect object syntax\n + send-email: use function syntax instead of barewords\n + send-email: lazily shell out to \"git var\"\n + send-email: lazily load config for a big speedup\n + send-email: copy \"config_regxp\" into git-send-email.perl\n + send-email: refactor sendemail.smtpencryption config parsing\n + send-email: remove non-working support for \"sendemail.smtpssl\"\n + send-email tests: test for boolean variables without a value\n + send-email tests: support GIT_TEST_PERL_FATAL_WARNINGS=true\n\n \"git send-email\" optimization.\n\n Will merge to 'master'.\n\n\n* ab/fsck-unexpected-type (2021-07-12) 21 commits\n - fsck: report invalid object type-path combinations\n - fsck: report invalid types recorded in objects\n - object-store.h: move read_loose_object() below 'struct object_info'\n - fsck: don't hard die on invalid object types\n - object-file.c: return -2 on \"header too long\" in unpack_loose_header()\n - object-file.c: return -1, not \"status\" from unpack_loose_header()\n - object-file.c: guard against future bugs in loose_object_info()\n - object-file.c: stop dying in parse_loose_header()\n - object-file.c: split up ternary in parse_loose_header()\n - object-file.c: simplify unpack_loose_short_header()\n - object-file.c: add missing braces to loose_object_info()\n - object-file.c: make parse_loose_header_extended() public\n - object-file.c: don't set \"typep\" when returning non-zero\n - cache.h: move object functions to object-store.h\n - cat-file tests: test for current --allow-unknown-type behavior\n - cat-file tests: add corrupt loose object test\n - rev-list tests: test for behavior with invalid object types\n - cat-file tests: test that --allow-unknown-type isn't on by default\n - cat-file tests: test for missing object with -t and -s\n - fsck tests: add test for fsck-ing an unknown type\n - fsck tests: refactor one test to use a sub-repo\n\n \"git fsck\" has been taught to report mismatch between expected and\n actual types of an object better.\n\n Needs review.\n"},{"id":"429991","messageId":"CAPig+cQfsACHAQhCrXDs==18p1Ds8MtMRZDmSfso9HsO6dF-qg@mail.gmail.com","threadId":"56101","inReplyTo":"xmqqmtqpzosf.fsf@gitster.g","subject":"Re: What's cooking in git.git (Jul 2021, #03; Tue, 13)","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2021-07-14T02:16:54Z","receivedAt":"2021-07-14T02:17:08Z","isPatch":false,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Tue, Jul 13, 2021 at 9:07 PM Junio C Hamano <gitster@pobox.com> wrote:\n> * sm/worktree-add-lock (2021-07-12) 3 commits\n>  - worktree: teach `add` to accept --reason <string> with --lock\n>  - worktree: mark lock strings with `_()` for translation\n>  - t2400: clean up '\"add\" worktree with lock' test\n>\n>  \"git worktree add --lock\" learned to record why the worktree is\n>  locked with a custom message.\n>\n>  Ready?\n\nI think this series is ready and gave my Reviewed-by: here[1]. One of\nthe new tests contains an unnecessary but harmless `test -f`[2], but\nit's such a minor nit that I doubt it's worth demanding a re-roll.\n\n[1]: https://lore.kernel.org/git/CAPig+cSVsJ9AtAMqtRQpyuosCDCGi+mu2C1PJUK49WTb5KvcWQ@mail.gmail.com/\n[2]: https://lore.kernel.org/git/CAPig+cQVSUg1aqry_hMydJ=Uo=-VhOog6TUTpG=0on0LUcw8Dg@mail.gmail.com/\n"},{"id":"430003","messageId":"CAFQ2z_P=9Suh0kO6E44hUOyNFOAKcmcUg_x6AQFP9jhHrBA6RQ@mail.gmail.com","threadId":"56101","inReplyTo":"xmqqmtqpzosf.fsf@gitster.g","subject":"Re: What's cooking in git.git (Jul 2021, #03; Tue, 13)","fromName":"Han-Wen Nienhuys","fromEmail":"hanwen@google.com","sentAt":"2021-07-14T08:42:24Z","receivedAt":"2021-07-14T08:42:41Z","isPatch":false,"sender":{"key":"hanwen@google.com","avatar":"https://avatars.githubusercontent.com/u/31547?v=4"},"body":"On Wed, Jul 14, 2021 at 3:07 AM Junio C Hamano <gitster@pobox.com> wrote:\n> [Stalled]\n>\n> * hn/reftable (2021-05-20) 27 commits\n\nI have some updates for the series pending, but I'm waiting for the\npreliminaries (test fixes, the errno stuff) to hit master.\n\nHow do other folks deal with dependencies between topics?\n\n> * hn/refs-errno-cleanup (2021-07-07) 6 commits\n>  - refs: make errno output explicit for refs_resolve_ref_unsafe\n>  - refs: explicitly return failure_errno from parse_loose_ref_contents\n>  - refs: add failure_errno to refs_read_raw_ref() signature\n>  - refs: make errno output explicit for read_raw_ref_fn\n>  - refs/files-backend: stop setting errno from lock_ref_oid_basic\n>  - refs: remove EINVAL errno output from specification of read_raw_ref_fn\n>\n>  Futz with the way 'errno' is relied on in the refs API to carry the\n>  failure modes up the callchain.\n>\n>  Expecting a (hopefully final) reroll.\n>  cf. <CAFQ2z_NzykfcBSvtHQ10RZWxLP48+qArZk9HbDJQB4tNX-GtYA@mail.gmail.com>\n\nAEvar posted the corrected patch as part of his follow-up series.\n(https://public-inbox.org/git/patch-04.17-270cda29c3a-20210711T162803Z-avarab@gmail.com/).\nWould that work for you?\n\n--\nHan-Wen Nienhuys - Google Munich\nI work 80%. Don't expect answers from me on Fridays.\n--\nGoogle Germany GmbH, Erika-Mann-Strasse 33, 80636 Munich\nRegistergericht und -nummer: Hamburg, HRB 86891\nSitz der Gesellschaft: Hamburg\nGeschäftsführer: Paul Manicle, Halimah DeLaine Prado\n"},{"id":"430023","messageId":"87im1d156t.fsf@evledraar.gmail.com","threadId":"56101","inReplyTo":"CAFQ2z_P=9Suh0kO6E44hUOyNFOAKcmcUg_x6AQFP9jhHrBA6RQ@mail.gmail.com","subject":"Re: What's cooking in git.git (Jul 2021, #03; Tue, 13)","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2021-07-14T11:53:01Z","receivedAt":"2021-07-14T11:54:32Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Wed, Jul 14 2021, Han-Wen Nienhuys wrote:\n\n> On Wed, Jul 14, 2021 at 3:07 AM Junio C Hamano <gitster@pobox.com> wrote:\n>> [Stalled]\n>>\n>> * hn/reftable (2021-05-20) 27 commits\n>\n> I have some updates for the series pending, but I'm waiting for the\n> preliminaries (test fixes, the errno stuff) to hit master.\n>\n> How do other folks deal with dependencies between topics?\n>\n>> * hn/refs-errno-cleanup (2021-07-07) 6 commits\n>>  - refs: make errno output explicit for refs_resolve_ref_unsafe\n>>  - refs: explicitly return failure_errno from parse_loose_ref_contents\n>>  - refs: add failure_errno to refs_read_raw_ref() signature\n>>  - refs: make errno output explicit for read_raw_ref_fn\n>>  - refs/files-backend: stop setting errno from lock_ref_oid_basic\n>>  - refs: remove EINVAL errno output from specification of read_raw_ref_fn\n>>\n>>  Futz with the way 'errno' is relied on in the refs API to carry the\n>>  failure modes up the callchain.\n>>\n>>  Expecting a (hopefully final) reroll.\n>>  cf. <CAFQ2z_NzykfcBSvtHQ10RZWxLP48+qArZk9HbDJQB4tNX-GtYA@mail.gmail.com>\n>\n> AEvar posted the corrected patch as part of his follow-up series.\n> (https://public-inbox.org/git/patch-04.17-270cda29c3a-20210711T162803Z-avarab@gmail.com/).\n> Would that work for you?\n\nI re-rolled this just now as depending on:\n\n    https://lore.kernel.org/git/patch-1.1-de0838fe99-20210714T111351Z-avarab@gmail.com\n\nAnd submitted a s/v6\\?/v7/g at:\nhttps://lore.kernel.org/git/cover-0.6-0000000000-20210714T114301Z-avarab@gmail.com\n"},{"id":"430024","messageId":"87fswh14ta.fsf@evledraar.gmail.com","threadId":"56101","inReplyTo":"CAFQ2z_P=9Suh0kO6E44hUOyNFOAKcmcUg_x6AQFP9jhHrBA6RQ@mail.gmail.com","subject":"Re: What's cooking in git.git (Jul 2021, #03; Tue, 13)","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2021-07-14T11:54:57Z","receivedAt":"2021-07-14T12:02:40Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Wed, Jul 14 2021, Han-Wen Nienhuys wrote:\n\n> On Wed, Jul 14, 2021 at 3:07 AM Junio C Hamano <gitster@pobox.com> wrote:\n>> [Stalled]\n>>\n>> * hn/reftable (2021-05-20) 27 commits\n>\n> I have some updates for the series pending, but I'm waiting for the\n> preliminaries (test fixes, the errno stuff) to hit master.\n>\n> How do other folks deal with dependencies between topics?\n\nNot very well, but maybe this works for you.\n\nIf I had say a \"ab/reftable\" locally and it depended on\n\"ab/refs-errno-fixes\" I'd rebase ab/refs-errno-fixes on top of\nab/reftable, and set the upstream info (\"git branch --set-upstream-to\")\nto my pushed version of ab/reftable.\n\nThus \"git log @{u}..\" in \"ab/reftable\" gives me changes as of the\n\"ab/refs-errno-fixes\" \"base\" topic, and git-format-patch/send-email will\nsend patches as of that topic.\n\nOf course when you send this to the list you need to make that\ndependency relationship clear, as in my just-submitted re-roll of\nyour/my refs.c errno changes:\nhttps://lore.kernel.org/git/87im1d156t.fsf@evledraar.gmail.com/\n\nI have no idea if/how this would work with gitgitgadget, which I think\nyou exclusively use.\n\n"},{"id":"430037","messageId":"2c7f188a-6ebe-b116-8299-86ca3732d79a@gmail.com","threadId":"56101","inReplyTo":"xmqqmtqpzosf.fsf@gitster.g","subject":"Re: What's cooking in git.git (Jul 2021, #03; Tue, 13)","fromName":"Derrick Stolee","fromEmail":"stolee@gmail.com","sentAt":"2021-07-14T13:11:52Z","receivedAt":"2021-07-14T13:11:59Z","isPatch":false,"sender":{"key":"stolee@gmail.com","avatar":"https://avatars.githubusercontent.com/u/570044?v=4"},"body":"On 7/13/2021 9:07 PM, Junio C Hamano wrote:\n...\n> * en/ort-perf-batch-14 (2021-07-13) 7 commits\n>  - merge-ort: restart merge with cached renames to reduce process entry cost\n>  - merge-ort: avoid recursing into directories when we don't need to\n>  - merge-ort: defer recursing into directories when merge base is matched\n>  - merge-ort: add a handle_deferred_entries() helper function\n>  - merge-ort: add data structures for allowable trivial directory resolves\n>  - merge-ort: add some more explanations in collect_merge_info_callback()\n>  - merge-ort: resolve paths early when we have sufficient information\n> \n>  Further optimization on \"merge -sort\" backend.\n> \n>  Reviews?\n\nI saw a v2 re-roll, so I will review that this week.\n\n> * ds/commit-and-checkout-with-sparse-index (2021-07-12) 5 commits\n>  - checkout: stop expanding sparse indexes\n>  - sparse-index: recompute cache-tree\n>  - commit: integrate with sparse-index\n>  - p2000: compress repo names\n>  - p2000: add 'git checkout -' test and decrease depth\n>  (this branch uses ds/status-with-sparse-index.)\n> \n>  \"git checkout\" and \"git commit\" learn to work without unnecessarily\n>  expanding sparse indexes.\n> \n>  Ready?\n\nLet's mark this as \"expecting a re-roll\" because of the\ndirectory/file conflict issue. I'm trying to see if there\nis a quick way to resolve the current behavior change that\nElijah pointed out.\n\n> * ds/status-with-sparse-index (2021-07-12) 15 commits\n>  - fsmonitor: integrate with sparse index\n>  - wt-status: expand added sparse directory entries\n>  - status: use sparse-index throughout\n>  - status: skip sparse-checkout percentage with sparse-index\n>  - diff-lib: handle index diffs with sparse dirs\n>  - dir.c: accept a directory as part of cone-mode patterns\n>  - unpack-trees: unpack sparse directory entries\n>  - unpack-trees: rename unpack_nondirectories()\n>  - unpack-trees: compare sparse directories correctly\n>  - unpack-trees: preserve cache_bottom\n>  - t1092: add tests for status/add and sparse files\n>  - t1092: expand repository data shape\n>  - t1092: replace incorrect 'echo' with 'cat'\n>  - sparse-index: include EXTENDED flag when expanding\n>  - sparse-index: skip indexes with unmerged entries\n>  (this branch is used by ds/commit-and-checkout-with-sparse-index.)\n> \n>  \"git status\" codepath learned to work with sparsely populated index\n>  without hydrating it fully.\n> \n>  Expecting a final reroll.\n>  cf. <e7199fc6-bc7b-f556-c10c-12dee04af287@gmail.com>\n\nFinal re-roll inbound.\n\n> * ds/gender-neutral-doc-guidelines (2021-06-16) 2 commits\n>  - SQUASH??? replace neutering tips with that of Æver\n>  - CodingGuidelines: recommend singular they\n>  (this branch uses ds/gender-neutral-doc.)\n> \n>  Attempt to give a guideline for gender neutral documentation.\n> \n>  Comments?\n\nI've said before and will repeat here that the draft in your\nSQUASH??? commit looks like a good compromise to me. It can\nreplace the other commit in this branch.\n\nThanks,\n-Stolee\n"},{"id":"430056","messageId":"87czrl0wob.fsf@evledraar.gmail.com","threadId":"56101","inReplyTo":"2c7f188a-6ebe-b116-8299-86ca3732d79a@gmail.com","subject":"Re: What's cooking in git.git (Jul 2021, #03; Tue, 13)","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2021-07-14T14:32:30Z","receivedAt":"2021-07-14T14:58:27Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Wed, Jul 14 2021, Derrick Stolee wrote:\n\n> On 7/13/2021 9:07 PM, Junio C Hamano wrote:\n> [...]\n>> * ds/gender-neutral-doc-guidelines (2021-06-16) 2 commits\n>>  - SQUASH??? replace neutering tips with that of Æver\n>>  - CodingGuidelines: recommend singular they\n>>  (this branch uses ds/gender-neutral-doc.)\n>> \n>>  Attempt to give a guideline for gender neutral documentation.\n>> \n>>  Comments?\n>\n> I've said before and will repeat here that the draft in your\n> SQUASH??? commit looks like a good compromise to me. It can\n> replace the other commit in this branch.\n\nJust doing that would leave the commit message that says \"change X\",\nwhen we're now changing X, Y and Z. I.e.  With the squash it changes\nfrom narrowly focusing on the pronoun question into a start of a general\nprose and style guide for our documentation.\n\nWhatever anyone thinks about the proposed end-result I'd say that's a\nbit too much work to dump in Junio's lap.\n\nI also had a question for you here >2 weeks ago:\nhttps://lore.kernel.org/git/87o8bog7li.fsf@evledraar.gmail.com/\n"},{"id":"430069","messageId":"xmqqlf68yi1z.fsf@gitster.g","threadId":"56101","inReplyTo":"CAPig+cQfsACHAQhCrXDs==18p1Ds8MtMRZDmSfso9HsO6dF-qg@mail.gmail.com","subject":"Re: What's cooking in git.git (Jul 2021, #03; Tue, 13)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-07-14T16:30:16Z","receivedAt":"2021-07-14T16:30:21Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Eric Sunshine <sunshine@sunshineco.com> writes:\n\n> On Tue, Jul 13, 2021 at 9:07 PM Junio C Hamano <gitster@pobox.com> wrote:\n>> * sm/worktree-add-lock (2021-07-12) 3 commits\n>>  - worktree: teach `add` to accept --reason <string> with --lock\n>>  - worktree: mark lock strings with `_()` for translation\n>>  - t2400: clean up '\"add\" worktree with lock' test\n>>\n>>  \"git worktree add --lock\" learned to record why the worktree is\n>>  locked with a custom message.\n>>\n>>  Ready?\n>\n> I think this series is ready and gave my Reviewed-by: here[1]. One of\n> the new tests contains an unnecessary but harmless `test -f`[2], but\n> it's such a minor nit that I doubt it's worth demanding a re-roll.\n\nI think having \"test -f\" is the right thing to do, so [2] is\nprobably OK as-is.  test_cmp may want to complain about a possible\nbug in the test when given a missing file.  I do agree with you that\nthe unquoted \"why not\" is a bit problematic from the readability's\npoint of view but I agree it is not too huge a deal.\n\nLet me \"rebase -i\"-in your Reviewed-by: before merging it down to\n'next'.\n\nThanks.\n\n\n> [1]: https://lore.kernel.org/git/CAPig+cSVsJ9AtAMqtRQpyuosCDCGi+mu2C1PJUK49WTb5KvcWQ@mail.gmail.com/\n> [2]: https://lore.kernel.org/git/CAPig+cQVSUg1aqry_hMydJ=Uo=-VhOog6TUTpG=0on0LUcw8Dg@mail.gmail.com/\n"},{"id":"430088","messageId":"xmqq4kcwyfda.fsf@gitster.g","threadId":"56101","inReplyTo":"CAFQ2z_P=9Suh0kO6E44hUOyNFOAKcmcUg_x6AQFP9jhHrBA6RQ@mail.gmail.com","subject":"Re: What's cooking in git.git (Jul 2021, #03; Tue, 13)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-07-14T17:28:17Z","receivedAt":"2021-07-14T17:28:22Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Han-Wen Nienhuys <hanwen@google.com> writes:\n\n> AEvar posted the corrected patch as part of his follow-up series.\n> (https://public-inbox.org/git/patch-04.17-270cda29c3a-20210711T162803Z-avarab@gmail.com/).\n> Would that work for you?\n\nIn\n<CAFQ2z_M7FzR6HEea2Xj-j=LiTsjQvpGJc+h+D+GgU=ZEkWm50A@mail.gmail.com>\nyou sounded that you are more-or-less OK with that version but with\nsome comments, so as long as you two can give a \"final\" version that\nboth clearly agree to, I'm OK.  It just is not clear if v7 is that\nversion to me (yet).\n"},{"id":"430118","messageId":"YO9FAwre6cj958D/@nand.local","threadId":"56101","inReplyTo":"xmqqmtqpzosf.fsf@gitster.g","subject":"Re: What's cooking in git.git (Jul 2021, #03; Tue, 13)","fromName":"Taylor Blau","fromEmail":"me@ttaylorr.com","sentAt":"2021-07-14T20:11:47Z","receivedAt":"2021-07-14T20:11:52Z","isPatch":false,"sender":{"key":"me@ttaylorr.com","avatar":"https://avatars.githubusercontent.com/u/301000140?v=4"},"body":"On Tue, Jul 13, 2021 at 06:07:12PM -0700, Junio C Hamano wrote:\n> * tb/midx-use-checksum (2021-06-28) 4 commits\n>   (merged to 'next' on 2021-07-08 at bbaac9c721)\n>  + midx: report checksum mismatches during 'verify'\n>  + midx: don't reuse corrupt MIDXs when writing\n>  + commit-graph: rewrite to use checksum_valid()\n>  + csum-file: introduce checksum_valid()\n>\n>  When rebuilding the multi-pack index file reusing an existing one,\n>  we used to blindly trust the existing file and ended up carrying\n>  corrupted data into the updated file, which has been corrected.\n>\n>  Will merge to 'master'.\n\nThanks.\n\nI had a moment of panic over my week off that the new code wasn't using\nthe right hash for non-SHA-1 repositories. But we check that the hash\nversion the file was written with matches 'the_hash_algo' at runtime,\nand we use 'the_hash_algo->rawsz' to determine the end of the contents,\nso we're all good here.\n\n\n> * tb/multi-pack-bitmaps (2021-06-28) 24 commits\n> [...]\n>\n>  The reachability bitmap file used to be generated only for a single\n>  pack, but now we've learned to generate bitmaps for history that\n>  span across multiple packfiles.\n>\n>  Comments?\n\nI would definitely appreciate some more comments, but I have only\nsporadically been keeping up-to-date with this series. Ævar sent some\nsuggestions which I've been replying to today as I catch back up, but\nthey appear mostly cosmetic (at least, the ones that I've read so far).\n\nI think at this point I'd want a deep review from somebody familiar with\nbitmaps before re-rolling. Peff and I have both looked over the series\nexhaustively within GitHub, but the clean version submitted here should\ndefinitely be checked before merging.\n\nI'm not in a big hurry to merge this, but there are some other good\ntopics that are built on top (and it makes working on other bitmap\nrelated things kind of a pain since there are two choices for what to\nbase it on).\n\nThanks,\nTaylor\n"},{"id":"430150","messageId":"CAPig+cQjyYGidKA3sNc6Xr3aw0mk_t-s_64qaX13ffv5R_CHLA@mail.gmail.com","threadId":"56101","inReplyTo":"xmqqlf68yi1z.fsf@gitster.g","subject":"Re: What's cooking in git.git (Jul 2021, #03; Tue, 13)","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2021-07-14T22:39:27Z","receivedAt":"2021-07-14T22:39:40Z","isPatch":false,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Wed, Jul 14, 2021 at 12:30 PM Junio C Hamano <gitster@pobox.com> wrote:\n> Eric Sunshine <sunshine@sunshineco.com> writes:\n> > I think this series is ready and gave my Reviewed-by: here[1]. One of\n> > the new tests contains an unnecessary but harmless `test -f`[2], but\n> > it's such a minor nit that I doubt it's worth demanding a re-roll.\n>\n> I think having \"test -f\" is the right thing to do, so [2] is\n> probably OK as-is.  test_cmp may want to complain about a possible\n> bug in the test when given a missing file.  [...]\n\nWe tried relatively recently to have test_cmp() complain about a\nmissing file[1], but both Ævar[2] and Peff[3] ran into problems in\nwhich tests (presumably) legitimately called test_cmp() on missing\nfiles, so the suggestion was made to revert the check[4], which is\nindeed what happened[5].\n\n[1]: https://lore.kernel.org/git/20200809174209.15466-1-sunshine@sunshineco.com/\n[2]: https://lore.kernel.org/git/20200921104000.2304-15-avarab@gmail.com/\n[3]: https://lore.kernel.org/git/20201016001704.GA2937048@coredump.intra.peff.net/\n[4]: https://lore.kernel.org/git/CAPig+cSU=1GcQuqZab+0Vff_A-JmD59wEc3RMr3wDojpgRYUuw@mail.gmail.com/\n[5]: https://lore.kernel.org/git/xmqqv9f9ao0v.fsf@gitster.c.googlers.com/\n"},{"id":"430151","messageId":"xmqqo8b4tt05.fsf@gitster.g","threadId":"56101","inReplyTo":"CAPig+cQjyYGidKA3sNc6Xr3aw0mk_t-s_64qaX13ffv5R_CHLA@mail.gmail.com","subject":"Re: What's cooking in git.git (Jul 2021, #03; Tue, 13)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-07-14T22:44:58Z","receivedAt":"2021-07-14T22:45:01Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Eric Sunshine <sunshine@sunshineco.com> writes:\n\n> On Wed, Jul 14, 2021 at 12:30 PM Junio C Hamano <gitster@pobox.com> wrote:\n>> Eric Sunshine <sunshine@sunshineco.com> writes:\n>> > I think this series is ready and gave my Reviewed-by: here[1]. One of\n>> > the new tests contains an unnecessary but harmless `test -f`[2], but\n>> > it's such a minor nit that I doubt it's worth demanding a re-roll.\n>>\n>> I think having \"test -f\" is the right thing to do, so [2] is\n>> probably OK as-is.  test_cmp may want to complain about a possible\n>> bug in the test when given a missing file.  [...]\n>\n> We tried relatively recently to have test_cmp() complain about a\n> missing file[1], but both Ævar[2] and Peff[3] ran into problems in\n> which tests (presumably) legitimately called test_cmp() on missing\n> files, so the suggestion was made to revert the check[4], which is\n> indeed what happened[5].\n\nYes, I know all that, and even with that, having \"test -f\" is the\nright thing to do, so [2] is probably OK as-is.\n\n> [1]: https://lore.kernel.org/git/20200809174209.15466-1-sunshine@sunshineco.com/\n> [2]: https://lore.kernel.org/git/20200921104000.2304-15-avarab@gmail.com/\n> [3]: https://lore.kernel.org/git/20201016001704.GA2937048@coredump.intra.peff.net/\n> [4]: https://lore.kernel.org/git/CAPig+cSU=1GcQuqZab+0Vff_A-JmD59wEc3RMr3wDojpgRYUuw@mail.gmail.com/\n> [5]: https://lore.kernel.org/git/xmqqv9f9ao0v.fsf@gitster.c.googlers.com/\n"},{"id":"430230","messageId":"xmqqk0lrtuh4.fsf_-_@gitster.g","threadId":"56101","inReplyTo":"87czrl0wob.fsf@evledraar.gmail.com","subject":"[PATCH] CodingGuidelines: recommend gender-neutral description","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-07-15T16:25:27Z","receivedAt":"2021-07-15T16:25:34Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:\n\n>> I've said before and will repeat here that the draft in your\n>> SQUASH??? commit looks like a good compromise to me. It can\n>> replace the other commit in this branch.\n>\n> Just doing that would leave the commit message that says \"change X\",\n> when we're now changing X, Y and Z. I.e.  With the squash it changes\n> from narrowly focusing on the pronoun question into a start of a general\n> prose and style guide for our documentation.\n\nYeah, that is a good point.  Perhaps like this?\n\n-- >8 ---- >8 ---- >8 -- cut here -- >8 ---- >8 ---- >8 --\n\nTechnical writing seeks to convey information with minimal\nfriction. One way that a reader can experience friction is if they\nencounter a description of \"a user\" that is later simplified using a\ngendered pronoun. If the reader does not consider that pronoun to\napply to them, then they can experience cognitive dissonance that\nremoves focus from the information.\n\nGive some basic tips to guide us avoid unnecessary of gendered\ndescription.\n\nUsing a gendered pronoun is appropriate when referring to a specific\nperson.\n\nThere are acceptable existing uses of gendered pronouns within the\nGit codebase, such as:\n\n* References to real people (e.g. Linus Torvalds, \"the Git maintainer\").\n  Do not misgender real people. If there is any doubt to the gender of a\n  person, then avoid using pronouns.\n\n* References to fictional people with clear genders (e.g. Alice and\n  Bob).\n\n* Sample text used in test cases (e.g t3702, t6432).\n\n* The official text of the GPL license contains uses of \"he or she\",\n  but using singular \"they\" (or modifying the text in some other\n  way) is not within the scope of the Git project.\n\n* Literal email messages in Documentation/howto/ should not be edited\n  for grammatical concerns such as this, unless we update the entire\n  document to fit the standard documentation format. If such an effort is\n  taken on, then the authorship would change and no longer refer to the\n  exact mail message.\n\n* External projects consumed in contrib/ should not deviate solely for\n  style reasons. Recommended edits should be contributed to those\n  projects directly.\n\nOther cases within the Git project were cleaned up by the previous\nchanges.\n\nCo-authored-by: Junio C Hamano <gitster@pobox.com>\nSigned-off-by: Derrick Stolee <dstolee@microsoft.com>\nSigned-off-by: Junio C Hamano <gitster@pobox.com>\n---\n Documentation/CodingGuidelines | 43 ++++++++++++++++++++++++++++++++++\n 1 file changed, 43 insertions(+)\n\ndiff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines\nindex 45465bc0c9..476b840d30 100644\n--- a/Documentation/CodingGuidelines\n+++ b/Documentation/CodingGuidelines\n@@ -541,6 +541,49 @@ Writing Documentation:\n  documentation, please see the documentation-related advice in the\n  Documentation/SubmittingPatches file).\n \n+ In order to ensure the documentation is inclusive, avoid assuming\n+ that an unspecified example person is male or female, and think\n+ twice before using \"he\", \"him\", \"she\", or \"her\".  Here are some\n+ tips to avoid use of gendered pronouns:\n+\n+  - Prefer succinctness and matter-of-factly describing functionality\n+    in the abstract.  E.g.\n+\n+     --short:: Emit output in the short-format.\n+\n+    and avoid something like these overly verbose alternatives:\n+\n+     --short:: Use this to emit output in the short-format.\n+     --short:: You can use this to get output in the short-format.\n+     --short:: A user who prefers shorter output could....\n+     --short:: Should a person and/or program want shorter output, he\n+               she/they/it can...\n+\n+    This practice often eliminates the need to involve human actors in\n+    your description, but it is a good practice regardless of the\n+    avoidance of gendered pronouns.\n+\n+  - When it becomes awkward to stick to this style, prefer \"you\" when\n+    addressing the the hypothetical user, and possibly \"we\" when\n+    discussing how the program might react to the user.  E.g.\n+\n+      You can use this option instead of --xyz, but we might remove\n+      support for it in future versions.\n+\n+    while keeping in mind that you can probably be less verbose, e.g.\n+\n+      Use this instead of --xyz. This option might be removed in future\n+      versions.\n+\n+  - If you still need to refer to an example person that is\n+    third-person singular, you may resort to \"singular they\" to avoid\n+    \"he/she/him/her\", e.g.\n+\n+      A contributor asks their upstream to pull from them.\n+\n+    Note that this sounds ungrammatical and unnatural to those who\n+    learned English as a second language in some parts of the world.\n+\n  Every user-visible change should be reflected in the documentation.\n  The same general rule as for code applies -- imitate the existing\n  conventions.\n-- \n2.32.0-443-g7e6d7322bf\n\n"},{"id":"430234","messageId":"CAPig+cT24=jy65C1cQ4WarakJHKm4F8_78nDm=jWOnHxfhtcRw@mail.gmail.com","threadId":"56101","inReplyTo":"xmqqk0lrtuh4.fsf_-_@gitster.g","subject":"Re: [PATCH] CodingGuidelines: recommend gender-neutral description","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2021-07-15T16:35:30Z","receivedAt":"2021-07-15T16:35:43Z","isPatch":true,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Thu, Jul 15, 2021 at 12:25 PM Junio C Hamano <gitster@pobox.com> wrote:\n> Technical writing seeks to convey information with minimal\n> friction. One way that a reader can experience friction is if they\n> encounter a description of \"a user\" that is later simplified using a\n> gendered pronoun. If the reader does not consider that pronoun to\n> apply to them, then they can experience cognitive dissonance that\n> removes focus from the information.\n>\n> Give some basic tips to guide us avoid unnecessary of gendered\n> description.\n\nSome words seem to be missing from this sentence.\n\n> diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines\n> @@ -541,6 +541,49 @@ Writing Documentation:\n> +      A contributor asks their upstream to pull from them.\n> +\n> +    Note that this sounds ungrammatical and unnatural to those who\n> +    learned English as a second language in some parts of the world.\n\nIt also sounds ungrammatical and unnatural to this native English speaker.\n"},{"id":"430236","messageId":"YPBmv7x3zUbuQ2uy@nand.local","threadId":"56101","inReplyTo":"CAPig+cT24=jy65C1cQ4WarakJHKm4F8_78nDm=jWOnHxfhtcRw@mail.gmail.com","subject":"Re: [PATCH] CodingGuidelines: recommend gender-neutral description","fromName":"Taylor Blau","fromEmail":"me@ttaylorr.com","sentAt":"2021-07-15T16:47:59Z","receivedAt":"2021-07-15T16:48:03Z","isPatch":true,"sender":{"key":"me@ttaylorr.com","avatar":"https://avatars.githubusercontent.com/u/301000140?v=4"},"body":"On Thu, Jul 15, 2021 at 12:35:30PM -0400, Eric Sunshine wrote:\n> On Thu, Jul 15, 2021 at 12:25 PM Junio C Hamano <gitster@pobox.com> wrote:\n> > Technical writing seeks to convey information with minimal\n> > friction. One way that a reader can experience friction is if they\n> > encounter a description of \"a user\" that is later simplified using a\n> > gendered pronoun. If the reader does not consider that pronoun to\n> > apply to them, then they can experience cognitive dissonance that\n> > removes focus from the information.\n> >\n> > Give some basic tips to guide us avoid unnecessary of gendered\n> > description.\n>\n> Some words seem to be missing from this sentence.\n\nI assume that it's supposed to read \"guide us [to] avoid unnecessary\n[uses] of gendered description\".\n\n>\n> > diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines\n> > @@ -541,6 +541,49 @@ Writing Documentation:\n> > +      A contributor asks their upstream to pull from them.\n> > +\n> > +    Note that this sounds ungrammatical and unnatural to those who\n> > +    learned English as a second language in some parts of the world.\n>\n> It also sounds ungrammatical and unnatural to this native English speaker.\n\nApologies if this suggestion has been made earlier in the thread, but\nthis article\n\n    https://apastyle.apa.org/style-grammar-guidelines/grammar/singular-they\n\ndocument from the APA's style guide helps convince me that this is\ngrammatical.\n\nThanks,\nTaylor\n"},{"id":"430247","messageId":"2bdd27b7-cbe1-6952-eca0-f6fcecdaec8c@gmail.com","threadId":"56101","inReplyTo":"CAPig+cT24=jy65C1cQ4WarakJHKm4F8_78nDm=jWOnHxfhtcRw@mail.gmail.com","subject":"Re: [PATCH] CodingGuidelines: recommend gender-neutral description","fromName":"Derrick Stolee","fromEmail":"stolee@gmail.com","sentAt":"2021-07-15T17:27:55Z","receivedAt":"2021-07-15T17:28:01Z","isPatch":true,"sender":{"key":"stolee@gmail.com","avatar":"https://avatars.githubusercontent.com/u/570044?v=4"},"body":"On 7/15/2021 12:35 PM, Eric Sunshine wrote:\n> On Thu, Jul 15, 2021 at 12:25 PM Junio C Hamano <gitster@pobox.com> wrote:\n>> diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines\n>> @@ -541,6 +541,49 @@ Writing Documentation:\n>> +      A contributor asks their upstream to pull from them.\n>> +\n>> +    Note that this sounds ungrammatical and unnatural to those who\n>> +    learned English as a second language in some parts of the world.\n> \n> It also sounds ungrammatical and unnatural to this native English speaker.\n\nA way to adapt this idea more generally would be to pull a phrase\nfrom my commit message in v3:\n\n  Note that this sounds ungrammatical and unnatural to readers\n  who learned English in a way that dictated \"they\" as always plural.\n\nLearning English as a second language is one example of how one could\nfind it ungrammatical. We could call it out explicitly:\n\n  Note that this sounds ungrammatical and unnatural to readers\n  who learned English in a way that dictated \"they\" as always plural,\n  especially those who learned English as a second language.\n\nThanks,\n-Stolee\n"},{"id":"430257","messageId":"xmqq35sftpzn.fsf@gitster.g","threadId":"56101","inReplyTo":"YPBmv7x3zUbuQ2uy@nand.local","subject":"Re: [PATCH] CodingGuidelines: recommend gender-neutral description","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-07-15T18:02:20Z","receivedAt":"2021-07-15T18:02:25Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Taylor Blau <me@ttaylorr.com> writes:\n\n> On Thu, Jul 15, 2021 at 12:35:30PM -0400, Eric Sunshine wrote:\n>> On Thu, Jul 15, 2021 at 12:25 PM Junio C Hamano <gitster@pobox.com> wrote:\n>> > Technical writing seeks to convey information with minimal\n>> > friction. One way that a reader can experience friction is if they\n>> > encounter a description of \"a user\" that is later simplified using a\n>> > gendered pronoun. If the reader does not consider that pronoun to\n>> > apply to them, then they can experience cognitive dissonance that\n>> > removes focus from the information.\n>> >\n>> > Give some basic tips to guide us avoid unnecessary of gendered\n>> > description.\n>>\n>> Some words seem to be missing from this sentence.\n>\n> I assume that it's supposed to read \"guide us [to] avoid unnecessary\n> [uses] of gendered description\".\n\nThanks.  Last-minute edit always screwes me up.\n\n>> > +    Note that this sounds ungrammatical and unnatural to those who\n>> > +    learned English as a second language in some parts of the world.\n>>\n>> It also sounds ungrammatical and unnatural to this native English speaker.\n>\n> Apologies if this suggestion has been made earlier in the thread, but\n> this article\n>\n>     https://apastyle.apa.org/style-grammar-guidelines/grammar/singular-they\n>\n> document from the APA's style guide helps convince me that this is\n> grammatical.\n\nYes, the language is living and drifting---and that is why it\nmatters when and where you learned ;-)\n"},{"id":"430343","messageId":"nycvar.QRO.7.76.6.2107161709310.59@tvgsbejvaqbjf.bet","threadId":"56101","inReplyTo":"2bdd27b7-cbe1-6952-eca0-f6fcecdaec8c@gmail.com","subject":"Re: [PATCH] CodingGuidelines: recommend gender-neutral description","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2021-07-16T15:11:51Z","receivedAt":"2021-07-16T15:12:07Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 15 Jul 2021, Derrick Stolee wrote:\n\n> On 7/15/2021 12:35 PM, Eric Sunshine wrote:\n> > On Thu, Jul 15, 2021 at 12:25 PM Junio C Hamano <gitster@pobox.com> wrote:\n> >> diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines\n> >> @@ -541,6 +541,49 @@ Writing Documentation:\n> >> +      A contributor asks their upstream to pull from them.\n> >> +\n> >> +    Note that this sounds ungrammatical and unnatural to those who\n> >> +    learned English as a second language in some parts of the world.\n> >\n> > It also sounds ungrammatical and unnatural to this native English speaker.\n>\n> A way to adapt this idea more generally would be to pull a phrase\n> from my commit message in v3:\n>\n>   Note that this sounds ungrammatical and unnatural to readers\n>   who learned English in a way that dictated \"they\" as always plural.\n>\n> Learning English as a second language is one example of how one could\n> find it ungrammatical. We could call it out explicitly:\n>\n>   Note that this sounds ungrammatical and unnatural to readers\n>   who learned English in a way that dictated \"they\" as always plural,\n>   especially those who learned English as a second language.\n\nI like the latter form.\n\nCiao,\nDscho \"who will never stop learning English because learning never ends\"\n"},{"id":"430371","messageId":"xmqqv95aqeyh.fsf_-_@gitster.g","threadId":"56101","inReplyTo":"xmqqk0lrtuh4.fsf_-_@gitster.g","subject":"[PATCH v2] CodingGuidelines: recommend gender-neutral description","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-07-16T18:41:10Z","receivedAt":"2021-07-16T18:41:24Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Technical writing seeks to convey information with minimal\nfriction. One way that a reader can experience friction is if they\nencounter a description of \"a user\" that is later simplified using a\ngendered pronoun. If the reader does not consider that pronoun to\napply to them, then they can experience cognitive dissonance that\nremoves focus from the information.\n\nGive some basic tips to guide us avoid unnecessary uses of gendered\ndescription.\n\nUsing a gendered pronoun is appropriate when referring to a specific\nperson.\n\nThere are acceptable existing uses of gendered pronouns within the\nGit codebase, such as:\n\n* References to real people (e.g. Linus Torvalds, \"the Git maintainer\").\n  Do not misgender real people. If there is any doubt to the gender of a\n  person, then avoid using pronouns.\n\n* References to fictional people with clear genders (e.g. Alice and\n  Bob).\n\n* Sample text used in test cases (e.g t3702, t6432).\n\n* The official text of the GPL license contains uses of \"he or she\",\n  but using singular \"they\" (or modifying the text in some other\n  way) is not within the scope of the Git project.\n\n* Literal email messages in Documentation/howto/ should not be edited\n  for grammatical concerns such as this, unless we update the entire\n  document to fit the standard documentation format. If such an effort is\n  taken on, then the authorship would change and no longer refer to the\n  exact mail message.\n\n* External projects consumed in contrib/ should not deviate solely for\n  style reasons. Recommended edits should be contributed to those\n  projects directly.\n\nOther cases within the Git project were cleaned up by the previous\nchanges.\n\nCo-authored-by: Junio C Hamano <gitster@pobox.com>\nSigned-off-by: Derrick Stolee <dstolee@microsoft.com>\nSigned-off-by: Junio C Hamano <gitster@pobox.com>\n---\n\n The only change relative to the previous one is that this\n explicitly calls out that some are taught that 'they' is only used\n for third-person plural.  As we already say that some foreigners\n find it ungrammatical and unnatural to use 'they', I actually do\n not think it is necessary, but I'd prefer not to leave easy loose\n end hanging untied, so let's close this round and let others polish\n on top if they wanted to after the dust settls.\n\n Documentation/CodingGuidelines | 45 ++++++++++++++++++++++++++++++++++\n 1 file changed, 45 insertions(+)\n\ndiff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines\nindex 45465bc0c9..b1f199b1fe 100644\n--- a/Documentation/CodingGuidelines\n+++ b/Documentation/CodingGuidelines\n@@ -541,6 +541,51 @@ Writing Documentation:\n  documentation, please see the documentation-related advice in the\n  Documentation/SubmittingPatches file).\n \n+ In order to ensure the documentation is inclusive, avoid assuming\n+ that an unspecified example person is male or female, and think\n+ twice before using \"he\", \"him\", \"she\", or \"her\".  Here are some\n+ tips to avoid use of gendered pronouns:\n+\n+  - Prefer succinctness and matter-of-factly describing functionality\n+    in the abstract.  E.g.\n+\n+     --short:: Emit output in the short-format.\n+\n+    and avoid something like these overly verbose alternatives:\n+\n+     --short:: Use this to emit output in the short-format.\n+     --short:: You can use this to get output in the short-format.\n+     --short:: A user who prefers shorter output could....\n+     --short:: Should a person and/or program want shorter output, he\n+               she/they/it can...\n+\n+    This practice often eliminates the need to involve human actors in\n+    your description, but it is a good practice regardless of the\n+    avoidance of gendered pronouns.\n+\n+  - When it becomes awkward to stick to this style, prefer \"you\" when\n+    addressing the the hypothetical user, and possibly \"we\" when\n+    discussing how the program might react to the user.  E.g.\n+\n+      You can use this option instead of --xyz, but we might remove\n+      support for it in future versions.\n+\n+    while keeping in mind that you can probably be less verbose, e.g.\n+\n+      Use this instead of --xyz. This option might be removed in future\n+      versions.\n+\n+  - If you still need to refer to an example person that is\n+    third-person singular, you may resort to \"singular they\" to avoid\n+    \"he/she/him/her\", e.g.\n+\n+      A contributor asks their upstream to pull from them.\n+\n+    Note that this sounds ungrammatical and unnatural to those who\n+    learned that \"they\" is only used for third-person plural, e.g.\n+    those who learn English as a second language in some parts of the\n+    world.\n+\n  Every user-visible change should be reflected in the documentation.\n  The same general rule as for code applies -- imitate the existing\n  conventions.\n-- \n2.32.0-454-g0dabea483d\n\n"},{"id":"430377","messageId":"2f39c467-1d95-8f74-5e4b-6889c4352f9b@gmail.com","threadId":"56101","inReplyTo":"xmqqv95aqeyh.fsf_-_@gitster.g","subject":"Re: [PATCH v2] CodingGuidelines: recommend gender-neutral description","fromName":"Derrick Stolee","fromEmail":"stolee@gmail.com","sentAt":"2021-07-16T19:05:58Z","receivedAt":"2021-07-16T19:06:04Z","isPatch":true,"sender":{"key":"stolee@gmail.com","avatar":"https://avatars.githubusercontent.com/u/570044?v=4"},"body":"On 7/16/2021 2:41 PM, Junio C Hamano wrote:\n>  The only change relative to the previous one is that this\n>  explicitly calls out that some are taught that 'they' is only used\n>  for third-person plural.  As we already say that some foreigners\n>  find it ungrammatical and unnatural to use 'they', I actually do\n>  not think it is necessary, but I'd prefer not to leave easy loose\n>  end hanging untied, so let's close this round and let others polish\n>  on top if they wanted to after the dust settls.\n...\n> +    Note that this sounds ungrammatical and unnatural to those who\n> +    learned that \"they\" is only used for third-person plural, e.g.\n> +    those who learn English as a second language in some parts of the\n> +    world.\n\nPerfect. Thank you.\n\n-Stolee\n"},{"id":"430381","messageId":"87pmvivz8j.fsf@evledraar.gmail.com","threadId":"56101","inReplyTo":"xmqqv95aqeyh.fsf_-_@gitster.g","subject":"Re: [PATCH v2] CodingGuidelines: recommend gender-neutral description","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2021-07-16T19:11:36Z","receivedAt":"2021-07-16T19:24:15Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Fri, Jul 16 2021, Junio C Hamano wrote:\n\n> Technical writing seeks to convey information with minimal\n> friction. One way that a reader can experience friction is if they\n> encounter a description of \"a user\" that is later simplified using a\n> gendered pronoun. If the reader does not consider that pronoun to\n> apply to them, then they can experience cognitive dissonance that\n> removes focus from the information.\n>\n> Give some basic tips to guide us avoid unnecessary uses of gendered\n> description.\n>\n> Using a gendered pronoun is appropriate when referring to a specific\n> person.\n>\n> There are acceptable existing uses of gendered pronouns within the\n> Git codebase, such as:\n>\n> * References to real people (e.g. Linus Torvalds, \"the Git maintainer\").\n>   Do not misgender real people. If there is any doubt to the gender of a\n>   person, then avoid using pronouns.\n>\n> * References to fictional people with clear genders (e.g. Alice and\n>   Bob).\n>\n> * Sample text used in test cases (e.g t3702, t6432).\n>\n> * The official text of the GPL license contains uses of \"he or she\",\n>   but using singular \"they\" (or modifying the text in some other\n>   way) is not within the scope of the Git project.\n>\n> * Literal email messages in Documentation/howto/ should not be edited\n>   for grammatical concerns such as this, unless we update the entire\n>   document to fit the standard documentation format. If such an effort is\n>   taken on, then the authorship would change and no longer refer to the\n>   exact mail message.\n>\n> * External projects consumed in contrib/ should not deviate solely for\n>   style reasons. Recommended edits should be contributed to those\n>   projects directly.\n>\n> Other cases within the Git project were cleaned up by the previous\n> changes.\n>\n> Co-authored-by: Junio C Hamano <gitster@pobox.com>\n> Signed-off-by: Derrick Stolee <dstolee@microsoft.com>\n> Signed-off-by: Junio C Hamano <gitster@pobox.com>\n\nOn the topic of co-authors & SOB this text does look quite familiar:\nhttps://lore.kernel.org/git/87a6nz2fda.fsf@evledraar.gmail.com/ :)\n\n>  The only change relative to the previous one is that this\n>  explicitly calls out that some are taught that 'they' is only used\n>  for third-person plural.  As we already say that some foreigners\n>  find it ungrammatical and unnatural to use 'they', I actually do\n>  not think it is necessary[...]\n\nThe proposed commit message...\n\n> + In order to ensure the documentation is inclusive, avoid assuming\n> + that an unspecified example person is male or female, and think\n> + twice before using \"he\", \"him\", \"she\", or \"her\".  Here are some\n> + tips to avoid use of gendered pronouns:\n\nApplies to this:\n\n> +  - Prefer succinctness and matter-of-factly describing functionality\n> +    in the abstract.  E.g.\n> +\n> +     --short:: Emit output in the short-format.\n> +\n> +    and avoid something like these overly verbose alternatives:\n> +\n> +     --short:: Use this to emit output in the short-format.\n> +     --short:: You can use this to get output in the short-format.\n> +     --short:: A user who prefers shorter output could....\n> +     --short:: Should a person and/or program want shorter output, he\n> +               she/they/it can...\n\nBut this.\n\n> +    This practice often eliminates the need to involve human actors in\n> +    your description, but it is a good practice regardless of the\n> +    avoidance of gendered pronouns.\n\nNot this.\n\n> +  - When it becomes awkward to stick to this style, prefer \"you\" when\n> +    addressing the the hypothetical user, and possibly \"we\" when\n> +    discussing how the program might react to the user.  E.g.\n> +\n> +      You can use this option instead of --xyz, but we might remove\n> +      support for it in future versions.\n> +\n> +    while keeping in mind that you can probably be less verbose, e.g.\n> +\n> +      Use this instead of --xyz. This option might be removed in future\n> +      versions.\n\nBut this.\n\n> +  - If you still need to refer to an example person that is\n> +    third-person singular, you may resort to \"singular they\" to avoid\n> +    \"he/she/him/her\", e.g.\n> +\n> +      A contributor asks their upstream to pull from them.\n> +\n> +    Note that this sounds ungrammatical and unnatural to those who\n> +    learned that \"they\" is only used for third-person plural, e.g.\n> +    those who learn English as a second language in some parts of the\n> +    world.\n> +\n\nAnd not this, have, respectively, nothing to do and mostly everything to\ndo with the commit message.\n\nIOW I don't think we should conflate a section on general style in our\ncommon patterns/issues in our docs and one that at the end state of this\nseries is discussing the already-rare-now-nonexistent pattern that the\nproposed policy is trying to prevent ever making it in-tree again, or to\nput the entirety of a general style guide under the equivalent of \"how\nto avoid gendered pronouns\".\n\nIOW to have this instead (this is mostly a mere moving of your proposed\nversion):\n\n== BEGIN==\n\nGeneral style points for our documentation\n\n - Prefer succinctness and matter-of-factly describing functionality\n   in the abstract.  E.g.\n\n    --short:: Emit output in the short-format.\n\n   and avoid something like these overly verbose alternatives:\n\n    --short:: Use this to emit output in the short-format.\n    --short:: You can use this to get output in the short-format.\n    --short:: A user who prefers shorter output could....\n    --short:: Should a person and/or program want shorter output, he\n              she/they/it can...\n\n - When it becomes awkward to stick to this style, prefer \"you\" when\n   addressing the the hypothetical user, and possibly \"we\" when\n   discussing how the program might react to the user.  E.g.\n\n     You can use this option instead of --xyz, but we might remove\n     support for it in future versions.\n\n   while keeping in mind that you can probably be less verbose, e.g.\n\n     Use this instead of --xyz. This option might be removed in future\n     versions.\n\nDiscussing beings in our documentation:\n\n  In order to ensure the documentation is inclusive, avoid assuming\n  that an unspecified example person is male or female, and think\n  twice before using \"he\", \"him\", \"she\", or \"her\".  Here are some\n  tips to avoid use of gendered pronouns:\n\n  The practice of avoiding verbosity discussed above often eliminates\n  the need to involve human actors in your description.\n\n - If you still need to refer to an example person that is\n   third-person singular, you may resort to \"singular they\" to avoid\n   \"he/she/him/her\", e.g.\n\n   A contributor asks their upstream to pull from them.\n\n   Note that this sounds ungrammatical and unnatural to those who\n   learned that \"they\" is only used for third-person plural, e.g.\n   those who learn English as a second language in some parts of the\n   world.\n\n== END == \n\nI'd be happy to re-arrange this, if I could only get the submitter of\nthe series to respond to my E-Mails...\n\nSnipping around above:\n\n> , but I'd prefer not to leave easy loose\n>  end hanging untied, so let's close this round and let others polish\n>  on top if they wanted to after the dust settls.\n\nSure, but as someone who'll probably want to patch the first part of\nthis at one point or another, it's going to be rather weird to cover\ne.g. how we prefer to quote options or refer to things in\nerrors/warnings or whatever all under a section that says all of the\nbelow is in the service of the avoidance of gender pronouns.\n\nWhereas it's mostly the case that our docs are just following a style\nestablished in common OS-level docs at a time when I daresay this topic\nwasn't part of the zeitgeist.\n"},{"id":"430385","messageId":"xmqqr1fyqbre.fsf@gitster.g","threadId":"56101","inReplyTo":"87pmvivz8j.fsf@evledraar.gmail.com","subject":"Re: [PATCH v2] CodingGuidelines: recommend gender-neutral description","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-07-16T19:50:13Z","receivedAt":"2021-07-16T19:50:28Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:\n\n> I'd be happy to re-arrange this, if I could only get the submitter of\n> the series to respond to my E-Mails...\n\nI'll do this only once to add missing but intended recipient to the\nto: line; you are both adults, don't assume malice but instead good\nintentions and talk to each other.\n"},{"id":"430392","messageId":"60f1f6a22dc08_14cb20856@natae.notmuch","threadId":"56101","inReplyTo":"xmqqr1fyqbre.fsf@gitster.g","subject":"Re: [PATCH v2] CodingGuidelines: recommend gender-neutral description","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-07-16T21:14:10Z","receivedAt":"2021-07-16T21:14:15Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Junio C Hamano wrote:\n> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:\n> \n> > I'd be happy to re-arrange this, if I could only get the submitter of\n> > the series to respond to my E-Mails...\n> \n> I'll do this only once to add missing but intended recipient to the\n> to: line; you are both adults, don't assume malice but instead good\n> intentions and talk to each other.\n\nThat's ironic, given that you don't talk to me, which is BTW against the\ncode of conduct:\n\n * Being respectful of differing opinions, viewpoints, and experiences\n\nYou clearly do not respect my differing opinions.\n\nIt's not about being adults, it's about being *tolerant* about other\npeople's opinions (I still insist \"respect\" is the wrong term).\n\nCheers.\n\n-- \nFelipe Contreras"},{"id":"430396","messageId":"60f1f898eaea9_14cb208e7@natae.notmuch","threadId":"56101","inReplyTo":"2bdd27b7-cbe1-6952-eca0-f6fcecdaec8c@gmail.com","subject":"Re: [PATCH] CodingGuidelines: recommend gender-neutral description","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-07-16T21:22:32Z","receivedAt":"2021-07-16T21:22:37Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Derrick Stolee wrote:\n> On 7/15/2021 12:35 PM, Eric Sunshine wrote:\n> > On Thu, Jul 15, 2021 at 12:25 PM Junio C Hamano <gitster@pobox.com> wrote:\n> >> diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines\n> >> @@ -541,6 +541,49 @@ Writing Documentation:\n> >> +      A contributor asks their upstream to pull from them.\n> >> +\n> >> +    Note that this sounds ungrammatical and unnatural to those who\n> >> +    learned English as a second language in some parts of the world.\n> > \n> > It also sounds ungrammatical and unnatural to this native English speaker.\n> \n> A way to adapt this idea more generally would be to pull a phrase\n> from my commit message in v3:\n> \n>   Note that this sounds ungrammatical and unnatural to readers\n>   who learned English in a way that dictated \"they\" as always plural.\n> \n> Learning English as a second language is one example of how one could\n> find it ungrammatical. We could call it out explicitly:\n> \n>   Note that this sounds ungrammatical and unnatural to readers\n>   who learned English in a way that dictated \"they\" as always plural,\n>   especially those who learned English as a second language.\n\nThis is loaded language. You are inserting your opinion into the text.\n\nDon't. The guidelines are not a place to win arguments.\n\n  Note that this sounds ungrammatical and unnatural to some people.\n\nAnd it sounds ungrammatical because it *is* ungramatical, not only to\nnative English speakers, but professional linguists.\n\n-- \nFelipe Contreras\n"},{"id":"430397","messageId":"60f1f94a83f1e_14cb20828@natae.notmuch","threadId":"56101","inReplyTo":"YPBmv7x3zUbuQ2uy@nand.local","subject":"Re: [PATCH] CodingGuidelines: recommend gender-neutral description","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-07-16T21:25:30Z","receivedAt":"2021-07-16T21:25:38Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Taylor Blau wrote:\n> On Thu, Jul 15, 2021 at 12:35:30PM -0400, Eric Sunshine wrote:\n> > On Thu, Jul 15, 2021 at 12:25 PM Junio C Hamano <gitster@pobox.com> wrote:\n\n> > > diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines\n> > > @@ -541,6 +541,49 @@ Writing Documentation:\n> > > +      A contributor asks their upstream to pull from them.\n> > > +\n> > > +    Note that this sounds ungrammatical and unnatural to those who\n> > > +    learned English as a second language in some parts of the world.\n> >\n> > It also sounds ungrammatical and unnatural to this native English speaker.\n> \n> Apologies if this suggestion has been made earlier in the thread, but\n> this article\n> \n>     https://apastyle.apa.org/style-grammar-guidelines/grammar/singular-they\n> \n> document from the APA's style guide helps convince me that this is\n> grammatical.\n\nThat's the opinion of one organization (biased in my opinion). Other\norganizations disagree:\n\nhttps://ahdictionary.tumblr.com/post/147597257733/updated-usage-note-they\n\n-- \nFelipe Contreras\n"},{"id":"430476","messageId":"YPUrSB8+zEur+ZBt@ncase","threadId":"56101","inReplyTo":"xmqqmtqpzosf.fsf@gitster.g","subject":"Re: What's cooking in git.git (Jul 2021, #03; Tue, 13)","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2021-07-19T07:35:36Z","receivedAt":"2021-07-19T07:35:46Z","isPatch":false,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"On Tue, Jul 13, 2021 at 06:07:12PM -0700, Junio C Hamano wrote:\n[snip]\n> * ps/perf-with-separate-output-directory (2021-07-02) 1 commit\n>  - perf: fix when running with TEST_OUTPUT_DIRECTORY\n> \n>  Test update.\n> \n>  What's the status of this one?\n\nFrom my point of view this is ready, but it's still missing reviews so\nfar. The lack of interest seems to indicate that nobody has hit the\nissue so far, and I wonder why that is. Am I the only one who sets\nTEST_OUTPUT_DIRECTORY to a tmpfs directory in his config.mak to speed up\ntests?\n\nPatrick\n"},{"id":"430477","messageId":"60f52f7a52671_1e0a42083b@natae.notmuch","threadId":"56101","inReplyTo":"YPUrSB8+zEur+ZBt@ncase","subject":"Re: What's cooking in git.git (Jul 2021, #03; Tue, 13)","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-07-19T07:53:30Z","receivedAt":"2021-07-19T07:53:47Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Patrick Steinhardt wrote:\n> On Tue, Jul 13, 2021 at 06:07:12PM -0700, Junio C Hamano wrote:\n> [snip]\n> > * ps/perf-with-separate-output-directory (2021-07-02) 1 commit\n> >  - perf: fix when running with TEST_OUTPUT_DIRECTORY\n> > \n> >  Test update.\n> > \n> >  What's the status of this one?\n> \n> From my point of view this is ready, but it's still missing reviews so\n> far. The lack of interest seems to indicate that nobody has hit the\n> issue so far, and I wonder why that is. Am I the only one who sets\n> TEST_OUTPUT_DIRECTORY to a tmpfs directory in his config.mak to speed up\n> tests?\n\nNo, I do the same, and this other fix for TEST_OUTPUT_DIRECTORY is being\nignored even harder:\n\nhttps://lore.kernel.org/git/20210707030709.3134859-1-felipe.contreras@gmail.com/\n\n-- \nFelipe Contreras\n"},{"id":"430481","messageId":"YPU48uSCxXbsjvGW@coredump.intra.peff.net","threadId":"56101","inReplyTo":"YPUrSB8+zEur+ZBt@ncase","subject":"Re: What's cooking in git.git (Jul 2021, #03; Tue, 13)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2021-07-19T08:33:54Z","receivedAt":"2021-07-19T09:00:40Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Jul 19, 2021 at 09:35:36AM +0200, Patrick Steinhardt wrote:\n\n> On Tue, Jul 13, 2021 at 06:07:12PM -0700, Junio C Hamano wrote:\n> [snip]\n> > * ps/perf-with-separate-output-directory (2021-07-02) 1 commit\n> >  - perf: fix when running with TEST_OUTPUT_DIRECTORY\n> > \n> >  Test update.\n> > \n> >  What's the status of this one?\n> \n> From my point of view this is ready, but it's still missing reviews so\n> far. The lack of interest seems to indicate that nobody has hit the\n> issue so far, and I wonder why that is. Am I the only one who sets\n> TEST_OUTPUT_DIRECTORY to a tmpfs directory in his config.mak to speed up\n> tests?\n\nI had marked it to look at, but just hadn't gotten around to it. I just\ngave it a review (but the upshot is that it looks fine to me).\n\nI don't set TEST_OUTPUT_DIRECTORY myself; instead I do:\n\n  GIT_TEST_OPTS = --root=/path/to/tmpfs\n\nTBH, I had never really considered using TEST_OUTPUT_DIRECTORY for this\n(--root predates it, and was written explicitly for the tmpfs case). But\nI also think --root is more convenient:\n\n  - \"make test\" will run in the tmpfs for speed, but \"./t1234-foo.sh -i\"\n    will run locally, which makes it easy to \"cd\" in to inspect the\n    result\n\n  - likewise, I find accessing the results in t/test-results/*.out a\n    little more convenient\n\nBut all of that is preference. I don't think you're wrong to use\nTEST_OUTPUT_DIRECTORY this way, but the above points might be\ninteresting to you.\n\n-Peff\n"},{"id":"430483","messageId":"YPU5NyoDrQquWOYo@coredump.intra.peff.net","threadId":"56101","inReplyTo":"60f52f7a52671_1e0a42083b@natae.notmuch","subject":"Re: What's cooking in git.git (Jul 2021, #03; Tue, 13)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2021-07-19T08:35:03Z","receivedAt":"2021-07-19T09:01:48Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Jul 19, 2021 at 02:53:30AM -0500, Felipe Contreras wrote:\n\n> Patrick Steinhardt wrote:\n> > On Tue, Jul 13, 2021 at 06:07:12PM -0700, Junio C Hamano wrote:\n> > [snip]\n> > > * ps/perf-with-separate-output-directory (2021-07-02) 1 commit\n> > >  - perf: fix when running with TEST_OUTPUT_DIRECTORY\n> > > \n> > >  Test update.\n> > > \n> > >  What's the status of this one?\n> > \n> > From my point of view this is ready, but it's still missing reviews so\n> > far. The lack of interest seems to indicate that nobody has hit the\n> > issue so far, and I wonder why that is. Am I the only one who sets\n> > TEST_OUTPUT_DIRECTORY to a tmpfs directory in his config.mak to speed up\n> > tests?\n> \n> No, I do the same, and this other fix for TEST_OUTPUT_DIRECTORY is being\n> ignored even harder:\n> \n> https://lore.kernel.org/git/20210707030709.3134859-1-felipe.contreras@gmail.com/\n\nNote that the linked patch will break Patrick's, because we would no\nlonger set TEST_OUTPUT_DIRECTORY in GIT-BUILD-OPTIONS.\n\n-Peff\n"},{"id":"430486","messageId":"YPVW50Q6oyTxQ4D4@ncase","threadId":"56101","inReplyTo":"YPU48uSCxXbsjvGW@coredump.intra.peff.net","subject":"Re: What's cooking in git.git (Jul 2021, #03; Tue, 13)","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2021-07-19T10:41:43Z","receivedAt":"2021-07-19T10:41:54Z","isPatch":false,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"On Mon, Jul 19, 2021 at 04:33:54AM -0400, Jeff King wrote:\n> On Mon, Jul 19, 2021 at 09:35:36AM +0200, Patrick Steinhardt wrote:\n> \n> > On Tue, Jul 13, 2021 at 06:07:12PM -0700, Junio C Hamano wrote:\n> > [snip]\n> > > * ps/perf-with-separate-output-directory (2021-07-02) 1 commit\n> > >  - perf: fix when running with TEST_OUTPUT_DIRECTORY\n> > > \n> > >  Test update.\n> > > \n> > >  What's the status of this one?\n> > \n> > From my point of view this is ready, but it's still missing reviews so\n> > far. The lack of interest seems to indicate that nobody has hit the\n> > issue so far, and I wonder why that is. Am I the only one who sets\n> > TEST_OUTPUT_DIRECTORY to a tmpfs directory in his config.mak to speed up\n> > tests?\n> \n> I had marked it to look at, but just hadn't gotten around to it. I just\n> gave it a review (but the upshot is that it looks fine to me).\n> \n> I don't set TEST_OUTPUT_DIRECTORY myself; instead I do:\n> \n>   GIT_TEST_OPTS = --root=/path/to/tmpfs\n> \n> TBH, I had never really considered using TEST_OUTPUT_DIRECTORY for this\n> (--root predates it, and was written explicitly for the tmpfs case). But\n> I also think --root is more convenient:\n> \n>   - \"make test\" will run in the tmpfs for speed, but \"./t1234-foo.sh -i\"\n>     will run locally, which makes it easy to \"cd\" in to inspect the\n>     result\n> \n>   - likewise, I find accessing the results in t/test-results/*.out a\n>     little more convenient\n> \n> But all of that is preference. I don't think you're wrong to use\n> TEST_OUTPUT_DIRECTORY this way, but the above points might be\n> interesting to you.\n\nIt is, thanks a lot for the hint. But given your first point about\ndirect execution, this in fact makes me want TEST_OUTPUT_DIRECTORY in\ncontrast to `--root=/path/to/tmpfs`: especially in the context of perf\ntests, I never run all of them together given that it takes such a long\ntime. So I instead either run them directly or via the `./run` script,\nand in both cases I definitely want to have them in tmpfs given that\nthere's a lot of disk churn if you're using biggish repos.\n\nPatrick\n"},{"id":"430487","messageId":"60f5573312036_13ce8720841@natae.notmuch","threadId":"56101","inReplyTo":"YPU5NyoDrQquWOYo@coredump.intra.peff.net","subject":"Re: What's cooking in git.git (Jul 2021, #03; Tue, 13)","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-07-19T10:42:59Z","receivedAt":"2021-07-19T10:43:07Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Jeff King wrote:\n> On Mon, Jul 19, 2021 at 02:53:30AM -0500, Felipe Contreras wrote:\n> \n> > Patrick Steinhardt wrote:\n> > > On Tue, Jul 13, 2021 at 06:07:12PM -0700, Junio C Hamano wrote:\n> > > [snip]\n> > > > * ps/perf-with-separate-output-directory (2021-07-02) 1 commit\n> > > >  - perf: fix when running with TEST_OUTPUT_DIRECTORY\n> > > > \n> > > >  Test update.\n> > > > \n> > > >  What's the status of this one?\n> > > \n> > > From my point of view this is ready, but it's still missing reviews so\n> > > far. The lack of interest seems to indicate that nobody has hit the\n> > > issue so far, and I wonder why that is. Am I the only one who sets\n> > > TEST_OUTPUT_DIRECTORY to a tmpfs directory in his config.mak to speed up\n> > > tests?\n> > \n> > No, I do the same, and this other fix for TEST_OUTPUT_DIRECTORY is being\n> > ignored even harder:\n> > \n> > https://lore.kernel.org/git/20210707030709.3134859-1-felipe.contreras@gmail.com/\n> \n> Note that the linked patch will break Patrick's, because we would no\n> longer set TEST_OUTPUT_DIRECTORY in GIT-BUILD-OPTIONS.\n\nIs Patrick's patch specific to GIT-BUILD-OPTIONS? Or can\nTEST_OUTPUT_DIRECTORY be taken from the environment?\n\nEither way I think the priority should be to make the standard tests\nwork with TEST_OUTPUT_DIRECTORY.\n\n-- \nFelipe Contreras\n"},{"id":"430489","messageId":"YPVZcA2z9cmTe5D5@coredump.intra.peff.net","threadId":"56101","inReplyTo":"YPVW50Q6oyTxQ4D4@ncase","subject":"Re: What's cooking in git.git (Jul 2021, #03; Tue, 13)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2021-07-19T10:52:32Z","receivedAt":"2021-07-19T10:52:35Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Jul 19, 2021 at 12:41:43PM +0200, Patrick Steinhardt wrote:\n\n> > TBH, I had never really considered using TEST_OUTPUT_DIRECTORY for this\n> > (--root predates it, and was written explicitly for the tmpfs case). But\n> > I also think --root is more convenient:\n> > \n> >   - \"make test\" will run in the tmpfs for speed, but \"./t1234-foo.sh -i\"\n> >     will run locally, which makes it easy to \"cd\" in to inspect the\n> >     result\n> > \n> >   - likewise, I find accessing the results in t/test-results/*.out a\n> >     little more convenient\n> > \n> > But all of that is preference. I don't think you're wrong to use\n> > TEST_OUTPUT_DIRECTORY this way, but the above points might be\n> > interesting to you.\n> \n> It is, thanks a lot for the hint. But given your first point about\n> direct execution, this in fact makes me want TEST_OUTPUT_DIRECTORY in\n> contrast to `--root=/path/to/tmpfs`: especially in the context of perf\n> tests, I never run all of them together given that it takes such a long\n> time. So I instead either run them directly or via the `./run` script,\n> and in both cases I definitely want to have them in tmpfs given that\n> there's a lot of disk churn if you're using biggish repos.\n\nI generally use \"./run\", too. It will use GIT_TEST_OPTS under the hood\n(which I actually find a little odd, just because it kicks in my usual\n\"-x --verbose-log\", which I don't actually care about for the perf\ntests).\n\nYou'd have to specify it manually for single-script runs, though. I\nusually avoid single-script runs (and instead use \"./run\") because I try\nto make sure each run is associated with a commit. Otherwise, it's easy\nto confuse yourself about what the state of \"this tree\" was when it ran\n(it does not even build fresh with GIT_PERF_MAKE_OPTS! So many times\nI've accidentally tested a -O0 build from the current tree and wondered\nwhy it was so slow).\n\n-Peff\n"},{"id":"430491","messageId":"YPVaVvcamOB0RZV+@ncase","threadId":"56101","inReplyTo":"60f5573312036_13ce8720841@natae.notmuch","subject":"Re: What's cooking in git.git (Jul 2021, #03; Tue, 13)","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2021-07-19T10:56:22Z","receivedAt":"2021-07-19T10:56:28Z","isPatch":false,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"On Mon, Jul 19, 2021 at 05:42:59AM -0500, Felipe Contreras wrote:\n> Jeff King wrote:\n> > On Mon, Jul 19, 2021 at 02:53:30AM -0500, Felipe Contreras wrote:\n> > \n> > > Patrick Steinhardt wrote:\n> > > > On Tue, Jul 13, 2021 at 06:07:12PM -0700, Junio C Hamano wrote:\n> > > > [snip]\n> > > > > * ps/perf-with-separate-output-directory (2021-07-02) 1 commit\n> > > > >  - perf: fix when running with TEST_OUTPUT_DIRECTORY\n> > > > > \n> > > > >  Test update.\n> > > > > \n> > > > >  What's the status of this one?\n> > > > \n> > > > From my point of view this is ready, but it's still missing reviews so\n> > > > far. The lack of interest seems to indicate that nobody has hit the\n> > > > issue so far, and I wonder why that is. Am I the only one who sets\n> > > > TEST_OUTPUT_DIRECTORY to a tmpfs directory in his config.mak to speed up\n> > > > tests?\n> > > \n> > > No, I do the same, and this other fix for TEST_OUTPUT_DIRECTORY is being\n> > > ignored even harder:\n> > > \n> > > https://lore.kernel.org/git/20210707030709.3134859-1-felipe.contreras@gmail.com/\n> > \n> > Note that the linked patch will break Patrick's, because we would no\n> > longer set TEST_OUTPUT_DIRECTORY in GIT-BUILD-OPTIONS.\n> \n> Is Patrick's patch specific to GIT-BUILD-OPTIONS? Or can\n> TEST_OUTPUT_DIRECTORY be taken from the environment?\n> \n> Either way I think the priority should be to make the standard tests\n> work with TEST_OUTPUT_DIRECTORY.\n\nRight now, TEST_OUTPUT_DIRECTORY as defined in config.mak will be\nwritten into GIT-BUILD-OPTIONS, which then gets sourced by test-lib.sh\nautomatically. So even if you execute tests directly and not via the\nMakefile, it'll still pick up the correct output directory you've\nspecified in your config.mak. It would likely be possible to take it\nfrom the environment, but that makes the calling interface much more\nfragile given that you'll have to remember to always set the envvar.\n\nPatrick\n"},{"id":"430492","messageId":"60f5612fd4d2b_13dbe9208ab@natae.notmuch","threadId":"56101","inReplyTo":"YPVaVvcamOB0RZV+@ncase","subject":"Re: What's cooking in git.git (Jul 2021, #03; Tue, 13)","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-07-19T11:25:35Z","receivedAt":"2021-07-19T11:25:40Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Patrick Steinhardt wrote:\n> On Mon, Jul 19, 2021 at 05:42:59AM -0500, Felipe Contreras wrote:\n> > Jeff King wrote:\n> > > On Mon, Jul 19, 2021 at 02:53:30AM -0500, Felipe Contreras wrote:\n> > > \n> > > > Patrick Steinhardt wrote:\n> > > > > On Tue, Jul 13, 2021 at 06:07:12PM -0700, Junio C Hamano wrote:\n> > > > > [snip]\n> > > > > > * ps/perf-with-separate-output-directory (2021-07-02) 1 commit\n> > > > > >  - perf: fix when running with TEST_OUTPUT_DIRECTORY\n> > > > > > \n> > > > > >  Test update.\n> > > > > > \n> > > > > >  What's the status of this one?\n> > > > > \n> > > > > From my point of view this is ready, but it's still missing reviews so\n> > > > > far. The lack of interest seems to indicate that nobody has hit the\n> > > > > issue so far, and I wonder why that is. Am I the only one who sets\n> > > > > TEST_OUTPUT_DIRECTORY to a tmpfs directory in his config.mak to speed up\n> > > > > tests?\n> > > > \n> > > > No, I do the same, and this other fix for TEST_OUTPUT_DIRECTORY is being\n> > > > ignored even harder:\n> > > > \n> > > > https://lore.kernel.org/git/20210707030709.3134859-1-felipe.contreras@gmail.com/\n> > > \n> > > Note that the linked patch will break Patrick's, because we would no\n> > > longer set TEST_OUTPUT_DIRECTORY in GIT-BUILD-OPTIONS.\n> > \n> > Is Patrick's patch specific to GIT-BUILD-OPTIONS? Or can\n> > TEST_OUTPUT_DIRECTORY be taken from the environment?\n> > \n> > Either way I think the priority should be to make the standard tests\n> > work with TEST_OUTPUT_DIRECTORY.\n> \n> Right now, TEST_OUTPUT_DIRECTORY as defined in config.mak will be\n> written into GIT-BUILD-OPTIONS, which then gets sourced by test-lib.sh\n> automatically. So even if you execute tests directly and not via the\n> Makefile, it'll still pick up the correct output directory you've\n> specified in your config.mak.\n\nYeah, I know, but right now if you do that t0000-basic.sh fails because\n_run_sub_test_lib_test_common sets TEST_OUTPUT_DIRECTORY on the\nenvironment, and that gets overriden when GIT-BUILD-OPTIONS is sourced.\n\n> It would likely be possible to take it from the environment, but that\n> makes the calling interface much more fragile given that you'll have\n> to remember to always set the envvar.\n\nIndeed, unless you set that in your ~/.profile, as I did.\n\n-- \nFelipe Contreras\n"},{"id":"430536","messageId":"xmqqtukqkuzr.fsf@gitster.g","threadId":"56101","inReplyTo":"YPVW50Q6oyTxQ4D4@ncase","subject":"Re: What's cooking in git.git (Jul 2021, #03; Tue, 13)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-07-19T18:40:24Z","receivedAt":"2021-07-19T19:15:03Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Patrick Steinhardt <ps@pks.im> writes:\n\n> On Mon, Jul 19, 2021 at 04:33:54AM -0400, Jeff King wrote:\n>> On Mon, Jul 19, 2021 at 09:35:36AM +0200, Patrick Steinhardt wrote:\n>> \n>> > On Tue, Jul 13, 2021 at 06:07:12PM -0700, Junio C Hamano wrote:\n>> > [snip]\n>> > > * ps/perf-with-separate-output-directory (2021-07-02) 1 commit\n>> > >  - perf: fix when running with TEST_OUTPUT_DIRECTORY\n>> > > \n>> > >  Test update.\n>> > > \n>> > >  What's the status of this one?\n>> > \n>> > From my point of view this is ready, but it's still missing reviews so\n>> > far. The lack of interest seems to indicate that nobody has hit the\n>> > issue so far, and I wonder why that is. Am I the only one who sets\n>> > TEST_OUTPUT_DIRECTORY to a tmpfs directory in his config.mak to speed up\n>> > tests?\n>> \n>> I had marked it to look at, but just hadn't gotten around to it. I just\n>> gave it a review (but the upshot is that it looks fine to me).\n>> \n>> I don't set TEST_OUTPUT_DIRECTORY myself; instead I do:\n>> \n>>   GIT_TEST_OPTS = --root=/path/to/tmpfs\n>> \n>> TBH, I had never really considered using TEST_OUTPUT_DIRECTORY for this\n>> (--root predates it, and was written explicitly for the tmpfs case). But\n>> I also think --root is more convenient:\n>> \n>>   - \"make test\" will run in the tmpfs for speed, but \"./t1234-foo.sh -i\"\n>>     will run locally, which makes it easy to \"cd\" in to inspect the\n>>     result\n>> \n>>   - likewise, I find accessing the results in t/test-results/*.out a\n>>     little more convenient\n>> \n>> But all of that is preference. I don't think you're wrong to use\n>> TEST_OUTPUT_DIRECTORY this way, but the above points might be\n>> interesting to you.\n>\n> It is, thanks a lot for the hint. But given your first point about\n> direct execution, this in fact makes me want TEST_OUTPUT_DIRECTORY in\n> contrast to `--root=/path/to/tmpfs`: especially in the context of perf\n> tests, I never run all of them together given that it takes such a long\n> time. So I instead either run them directly or via the `./run` script,\n> and in both cases I definitely want to have them in tmpfs given that\n> there's a lot of disk churn if you're using biggish repos.\n>\n> Patrick\n\nThanks, all.  Let me mark the patch for 'next'.\n\n"},{"id":"430544","messageId":"60f5d923848d3_145c71208cc@natae.notmuch","threadId":"56101","inReplyTo":"xmqqtukqkuzr.fsf@gitster.g","subject":"Re: What's cooking in git.git (Jul 2021, #03; Tue, 13)","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-07-19T19:57:23Z","receivedAt":"2021-07-19T22:59:17Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Junio C Hamano wrote:\n> Patrick Steinhardt <ps@pks.im> writes:\n> \n> > On Mon, Jul 19, 2021 at 04:33:54AM -0400, Jeff King wrote:\n> >> On Mon, Jul 19, 2021 at 09:35:36AM +0200, Patrick Steinhardt wrote:\n> >> \n> >> > On Tue, Jul 13, 2021 at 06:07:12PM -0700, Junio C Hamano wrote:\n> >> > [snip]\n> >> > > * ps/perf-with-separate-output-directory (2021-07-02) 1 commit\n> >> > >  - perf: fix when running with TEST_OUTPUT_DIRECTORY\n> >> > > \n> >> > >  Test update.\n> >> > > \n> >> > >  What's the status of this one?\n> >> > \n> >> > From my point of view this is ready, but it's still missing reviews so\n> >> > far. The lack of interest seems to indicate that nobody has hit the\n> >> > issue so far, and I wonder why that is. Am I the only one who sets\n> >> > TEST_OUTPUT_DIRECTORY to a tmpfs directory in his config.mak to speed up\n> >> > tests?\n> >> \n> >> I had marked it to look at, but just hadn't gotten around to it. I just\n> >> gave it a review (but the upshot is that it looks fine to me).\n> >> \n> >> I don't set TEST_OUTPUT_DIRECTORY myself; instead I do:\n> >> \n> >>   GIT_TEST_OPTS = --root=/path/to/tmpfs\n> >> \n> >> TBH, I had never really considered using TEST_OUTPUT_DIRECTORY for this\n> >> (--root predates it, and was written explicitly for the tmpfs case). But\n> >> I also think --root is more convenient:\n> >> \n> >>   - \"make test\" will run in the tmpfs for speed, but \"./t1234-foo.sh -i\"\n> >>     will run locally, which makes it easy to \"cd\" in to inspect the\n> >>     result\n> >> \n> >>   - likewise, I find accessing the results in t/test-results/*.out a\n> >>     little more convenient\n> >> \n> >> But all of that is preference. I don't think you're wrong to use\n> >> TEST_OUTPUT_DIRECTORY this way, but the above points might be\n> >> interesting to you.\n> >\n> > It is, thanks a lot for the hint. But given your first point about\n> > direct execution, this in fact makes me want TEST_OUTPUT_DIRECTORY in\n> > contrast to `--root=/path/to/tmpfs`: especially in the context of perf\n> > tests, I never run all of them together given that it takes such a long\n> > time. So I instead either run them directly or via the `./run` script,\n> > and in both cases I definitely want to have them in tmpfs given that\n> > there's a lot of disk churn if you're using biggish repos.\n> >\n> > Patrick\n> \n> Thanks, all.  Let me mark the patch for 'next'.\n\nOK, if you don't care that TEST_OUTPUT_DIRECTORY is broken, so be it.\n\n-- \nFelipe Contreras\n"},{"id":"430565","messageId":"YPZtxy1/742YlrlK@ncase","threadId":"56101","inReplyTo":"60f5d923848d3_145c71208cc@natae.notmuch","subject":"Re: What's cooking in git.git (Jul 2021, #03; Tue, 13)","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2021-07-20T06:31:35Z","receivedAt":"2021-07-20T06:31:51Z","isPatch":false,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"On Mon, Jul 19, 2021 at 02:57:23PM -0500, Felipe Contreras wrote:\n> Junio C Hamano wrote:\n> > Patrick Steinhardt <ps@pks.im> writes:\n> > \n> > > On Mon, Jul 19, 2021 at 04:33:54AM -0400, Jeff King wrote:\n> > >> On Mon, Jul 19, 2021 at 09:35:36AM +0200, Patrick Steinhardt wrote:\n> > >> \n> > >> > On Tue, Jul 13, 2021 at 06:07:12PM -0700, Junio C Hamano wrote:\n> > >> > [snip]\n> > >> > > * ps/perf-with-separate-output-directory (2021-07-02) 1 commit\n> > >> > >  - perf: fix when running with TEST_OUTPUT_DIRECTORY\n> > >> > > \n> > >> > >  Test update.\n> > >> > > \n> > >> > >  What's the status of this one?\n> > >> > \n> > >> > From my point of view this is ready, but it's still missing reviews so\n> > >> > far. The lack of interest seems to indicate that nobody has hit the\n> > >> > issue so far, and I wonder why that is. Am I the only one who sets\n> > >> > TEST_OUTPUT_DIRECTORY to a tmpfs directory in his config.mak to speed up\n> > >> > tests?\n> > >> \n> > >> I had marked it to look at, but just hadn't gotten around to it. I just\n> > >> gave it a review (but the upshot is that it looks fine to me).\n> > >> \n> > >> I don't set TEST_OUTPUT_DIRECTORY myself; instead I do:\n> > >> \n> > >>   GIT_TEST_OPTS = --root=/path/to/tmpfs\n> > >> \n> > >> TBH, I had never really considered using TEST_OUTPUT_DIRECTORY for this\n> > >> (--root predates it, and was written explicitly for the tmpfs case). But\n> > >> I also think --root is more convenient:\n> > >> \n> > >>   - \"make test\" will run in the tmpfs for speed, but \"./t1234-foo.sh -i\"\n> > >>     will run locally, which makes it easy to \"cd\" in to inspect the\n> > >>     result\n> > >> \n> > >>   - likewise, I find accessing the results in t/test-results/*.out a\n> > >>     little more convenient\n> > >> \n> > >> But all of that is preference. I don't think you're wrong to use\n> > >> TEST_OUTPUT_DIRECTORY this way, but the above points might be\n> > >> interesting to you.\n> > >\n> > > It is, thanks a lot for the hint. But given your first point about\n> > > direct execution, this in fact makes me want TEST_OUTPUT_DIRECTORY in\n> > > contrast to `--root=/path/to/tmpfs`: especially in the context of perf\n> > > tests, I never run all of them together given that it takes such a long\n> > > time. So I instead either run them directly or via the `./run` script,\n> > > and in both cases I definitely want to have them in tmpfs given that\n> > > there's a lot of disk churn if you're using biggish repos.\n> > >\n> > > Patrick\n> > \n> > Thanks, all.  Let me mark the patch for 'next'.\n> \n> OK, if you don't care that TEST_OUTPUT_DIRECTORY is broken, so be it.\n\nI just think we shouldn't strip away features if we should instead look\nat why the testcase is broken and how to fix the root cause. I'll send a\npatch in a minute which fixes the testcase without dropping support for\nTEST_OUTPUT_DIRECTORY.\n\nPatrick\n"},{"id":"430567","messageId":"44006e7b0bdda50dc51153cc2efb6ae954d4eecb.1626762728.git.ps@pks.im","threadId":"56101","inReplyTo":"60f5d923848d3_145c71208cc@natae.notmuch","subject":"[PATCH] t0000: fix test if run with TEST_OUTPUT_DIRECTORY","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2021-07-20T06:32:26Z","receivedAt":"2021-07-20T06:32:37Z","isPatch":true,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"Testcases in t0000 are quite special given that they many of them run\nnested testcases to verify that testing functionality itself works as\nexpected. These nested testcases are realized by writing a new ad-hoc\ntest script which again sources test-lib.sh, where the new script is\ncreated in a nested subdirectory located beneath the current trash\ndirectory. We then execute the new test script with the nested\nsubdirectory as current working directory and explicitly re-export\nTEST_OUTPUT_DIRECTORY to point to that directory.\n\nWhile this works as expected in the general case, it falls apart when\nthe developer has TEST_OUTPUT_DIRECTORY explicitly defined either via\nthe environment or via config.mak. In that case, test-lib.sh will\nclobber the value that we've just carefully set up to instead contain\nwhat the developer has defined. As a result, the TEST_OUTPUT_DIRECTORY\ncontinues to point at the root output directory, not at the nested one.\n\nThis issue causes breakage in the 'test_atexit is run' test case: the\nnested test case writes files into \"../../\", which is assumed to be the\nparent's trash directory. But because TEST_OUTPUT_DIRECTORY already\npoints to to the root output directory, we instead end up writing those\nfiles outside of the output directory. The parent test case will then\ntry to check whether those files still exist in its own trash directory,\nwhich thus must fail now.\n\nFix the issue by adding a new TEST_OUTPUT_DIRECTORY_OVERRIDE variable.\nIf set, then we'll always override the TEST_OUTPUT_DIRECTORY with its\nvalue after sourcing GIT-BUILD-OPTIONS.\n\nSigned-off-by: Patrick Steinhardt <ps@pks.im>\n---\n t/t0000-basic.sh | 7 +++++--\n t/test-lib.sh    | 9 +++++++++\n 2 files changed, 14 insertions(+), 2 deletions(-)\n\ndiff --git a/t/t0000-basic.sh b/t/t0000-basic.sh\nindex 2c6e34b947..09d2202748 100755\n--- a/t/t0000-basic.sh\n+++ b/t/t0000-basic.sh\n@@ -89,8 +89,11 @@ _run_sub_test_lib_test_common () {\n \t\tEOF\n \t\tcat >>\"$name.sh\" &&\n \t\texport TEST_DIRECTORY &&\n-\t\tTEST_OUTPUT_DIRECTORY=$(pwd) &&\n-\t\texport TEST_OUTPUT_DIRECTORY &&\n+\t\t# The child test re-sources GIT-BUILD-OPTIONS and may thus\n+\t\t# override the test output directory. We thus pass it as an\n+\t\t# explicit override to the child.\n+\t\tTEST_OUTPUT_DIRECTORY_OVERRIDE=$(pwd) &&\n+\t\texport TEST_OUTPUT_DIRECTORY_OVERRIDE &&\n \t\tsane_unset GIT_TEST_FAIL_PREREQS &&\n \t\tif test -z \"$neg\"\n \t\tthen\ndiff --git a/t/test-lib.sh b/t/test-lib.sh\nindex 9e26860544..da13190970 100644\n--- a/t/test-lib.sh\n+++ b/t/test-lib.sh\n@@ -57,6 +57,15 @@ fi\n . \"$GIT_BUILD_DIR\"/GIT-BUILD-OPTIONS\n export PERL_PATH SHELL_PATH\n \n+# In t0000, we need to override test directories of nested testcases. In case\n+# the developer has TEST_OUTPUT_DIRECTORY part of his build options, then we'd\n+# reset this value to instead contain what the developer has specified. We thus\n+# have this knob to allow overriding the directory.\n+if test -n \"${TEST_OUTPUT_DIRECTORY_OVERRIDE}\"\n+then\n+\tTEST_OUTPUT_DIRECTORY=\"${TEST_OUTPUT_DIRECTORY_OVERRIDE}\"\n+fi\n+\n # Disallow the use of abbreviated options in the test suite by default\n if test -z \"${GIT_TEST_DISALLOW_ABBREVIATED_OPTIONS}\"\n then\n-- \n2.32.0\n\n"},{"id":"430569","messageId":"YPZ3JmWKLrUldK4R@coredump.intra.peff.net","threadId":"56101","inReplyTo":"44006e7b0bdda50dc51153cc2efb6ae954d4eecb.1626762728.git.ps@pks.im","subject":"Re: [PATCH] t0000: fix test if run with TEST_OUTPUT_DIRECTORY","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2021-07-20T07:11:34Z","receivedAt":"2021-07-20T07:11:47Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Jul 20, 2021 at 08:32:26AM +0200, Patrick Steinhardt wrote:\n\n> Fix the issue by adding a new TEST_OUTPUT_DIRECTORY_OVERRIDE variable.\n> If set, then we'll always override the TEST_OUTPUT_DIRECTORY with its\n> value after sourcing GIT-BUILD-OPTIONS.\n\nThanks, I like this approach much better than removing\nTEST_OUTPUT_DIRECTORY entirely (and I confirmed that it fixes the\nproblem).\n\nI do wish we had a more generic way of overriding stuff in\nGIT-BUILD-OPTIONS, rather than introducing manual _OVERRIDE variables\nfor each. But there's not an easy solution here (see the earlier thread\nfor some discussion), so this seems like a good immediate step to take.\n\nOne small note on the commit message:\n\n> While this works as expected in the general case, it falls apart when\n> the developer has TEST_OUTPUT_DIRECTORY explicitly defined either via\n> the environment or via config.mak.\n\nThe mention of the environment confused me for a moment, since:\n\n  TEST_OUTPUT_DIRECTORY=/tmp/foo ./t0000-basic.sh\n\nis already OK. But you probably meant that:\n\n  TEST_OUTPUT_DIRECTORY=/tmp/foo make test\n\nwould fail, since \"make\" would pick up the variable and then write it\ninto GIT-BUILD-OPTIONS (just as it would if you put it in config.mak, or\non the command-line of make).\n\nI don't think it's sufficiently confusing to rewrite the commit message,\nbut just something I noted while reading it.\n\n> --- a/t/test-lib.sh\n> +++ b/t/test-lib.sh\n> @@ -57,6 +57,15 @@ fi\n>  . \"$GIT_BUILD_DIR\"/GIT-BUILD-OPTIONS\n>  export PERL_PATH SHELL_PATH\n>  \n> +# In t0000, we need to override test directories of nested testcases. In case\n> +# the developer has TEST_OUTPUT_DIRECTORY part of his build options, then we'd\n> +# reset this value to instead contain what the developer has specified. We thus\n> +# have this knob to allow overriding the directory.\n> +if test -n \"${TEST_OUTPUT_DIRECTORY_OVERRIDE}\"\n> +then\n> +\tTEST_OUTPUT_DIRECTORY=\"${TEST_OUTPUT_DIRECTORY_OVERRIDE}\"\n> +fi\n\nThanks for this comment. Hopefully that will make it clear to anybody\nthat the override mechanism is not meant for general use by developers.\n\n-Peff\n"},{"id":"430571","messageId":"60f6796c18a4d_14a799208fb@natae.notmuch","threadId":"56101","inReplyTo":"YPZtxy1/742YlrlK@ncase","subject":"Re: What's cooking in git.git (Jul 2021, #03; Tue, 13)","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-07-20T07:21:16Z","receivedAt":"2021-07-20T07:21:21Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Patrick Steinhardt wrote:\n> On Mon, Jul 19, 2021 at 02:57:23PM -0500, Felipe Contreras wrote:\n> > Junio C Hamano wrote:\n> > > Patrick Steinhardt <ps@pks.im> writes:\n> > > \n> > > > On Mon, Jul 19, 2021 at 04:33:54AM -0400, Jeff King wrote:\n> > > >> On Mon, Jul 19, 2021 at 09:35:36AM +0200, Patrick Steinhardt wrote:\n> > > >> \n> > > >> > On Tue, Jul 13, 2021 at 06:07:12PM -0700, Junio C Hamano wrote:\n> > > >> > [snip]\n> > > >> > > * ps/perf-with-separate-output-directory (2021-07-02) 1 commit\n> > > >> > >  - perf: fix when running with TEST_OUTPUT_DIRECTORY\n> > > >> > > \n> > > >> > >  Test update.\n> > > >> > > \n> > > >> > >  What's the status of this one?\n> > > >> > \n> > > >> > From my point of view this is ready, but it's still missing reviews so\n> > > >> > far. The lack of interest seems to indicate that nobody has hit the\n> > > >> > issue so far, and I wonder why that is. Am I the only one who sets\n> > > >> > TEST_OUTPUT_DIRECTORY to a tmpfs directory in his config.mak to speed up\n> > > >> > tests?\n> > > >> \n> > > >> I had marked it to look at, but just hadn't gotten around to it. I just\n> > > >> gave it a review (but the upshot is that it looks fine to me).\n> > > >> \n> > > >> I don't set TEST_OUTPUT_DIRECTORY myself; instead I do:\n> > > >> \n> > > >>   GIT_TEST_OPTS = --root=/path/to/tmpfs\n> > > >> \n> > > >> TBH, I had never really considered using TEST_OUTPUT_DIRECTORY for this\n> > > >> (--root predates it, and was written explicitly for the tmpfs case). But\n> > > >> I also think --root is more convenient:\n> > > >> \n> > > >>   - \"make test\" will run in the tmpfs for speed, but \"./t1234-foo.sh -i\"\n> > > >>     will run locally, which makes it easy to \"cd\" in to inspect the\n> > > >>     result\n> > > >> \n> > > >>   - likewise, I find accessing the results in t/test-results/*.out a\n> > > >>     little more convenient\n> > > >> \n> > > >> But all of that is preference. I don't think you're wrong to use\n> > > >> TEST_OUTPUT_DIRECTORY this way, but the above points might be\n> > > >> interesting to you.\n> > > >\n> > > > It is, thanks a lot for the hint. But given your first point about\n> > > > direct execution, this in fact makes me want TEST_OUTPUT_DIRECTORY in\n> > > > contrast to `--root=/path/to/tmpfs`: especially in the context of perf\n> > > > tests, I never run all of them together given that it takes such a long\n> > > > time. So I instead either run them directly or via the `./run` script,\n> > > > and in both cases I definitely want to have them in tmpfs given that\n> > > > there's a lot of disk churn if you're using biggish repos.\n> > > >\n> > > > Patrick\n> > > \n> > > Thanks, all.  Let me mark the patch for 'next'.\n> > \n> > OK, if you don't care that TEST_OUTPUT_DIRECTORY is broken, so be it.\n> \n> I just think we shouldn't strip away features if we should instead look\n> at why the testcase is broken and how to fix the root cause.\n\nI mean, we didn't really strip away any features, you just happened to add\none feature at the same time the fix was proposed.\n\n> I'll send a patch in a minute which fixes the testcase without\n> dropping support for TEST_OUTPUT_DIRECTORY.\n\nOK. You mean without breaking functonality that is flying.\n\n-- \nFelipe Contreras\n"},{"id":"430573","messageId":"60f67a334777f_14a799208b9@natae.notmuch","threadId":"56101","inReplyTo":"44006e7b0bdda50dc51153cc2efb6ae954d4eecb.1626762728.git.ps@pks.im","subject":"RE: [PATCH] t0000: fix test if run with TEST_OUTPUT_DIRECTORY","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-07-20T07:24:35Z","receivedAt":"2021-07-20T07:24:53Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Patrick Steinhardt wrote:\n> Testcases in t0000 are quite special given that they many of them run\n> nested testcases to verify that testing functionality itself works as\n> expected. These nested testcases are realized by writing a new ad-hoc\n> test script which again sources test-lib.sh, where the new script is\n> created in a nested subdirectory located beneath the current trash\n> directory. We then execute the new test script with the nested\n> subdirectory as current working directory and explicitly re-export\n> TEST_OUTPUT_DIRECTORY to point to that directory.\n> \n> While this works as expected in the general case, it falls apart when\n> the developer has TEST_OUTPUT_DIRECTORY explicitly defined either via\n> the environment or via config.mak. In that case, test-lib.sh will\n> clobber the value that we've just carefully set up to instead contain\n> what the developer has defined. As a result, the TEST_OUTPUT_DIRECTORY\n> continues to point at the root output directory, not at the nested one.\n> \n> This issue causes breakage in the 'test_atexit is run' test case: the\n> nested test case writes files into \"../../\", which is assumed to be the\n> parent's trash directory. But because TEST_OUTPUT_DIRECTORY already\n> points to to the root output directory, we instead end up writing those\n> files outside of the output directory. The parent test case will then\n> try to check whether those files still exist in its own trash directory,\n> which thus must fail now.\n> \n> Fix the issue by adding a new TEST_OUTPUT_DIRECTORY_OVERRIDE variable.\n> If set, then we'll always override the TEST_OUTPUT_DIRECTORY with its\n> value after sourcing GIT-BUILD-OPTIONS.\n\nThis is a very *very* narrowly-specific hack, but I guess it's better\nthan the test suite failing.\n\n-- \nFelipe Contreras\n"},{"id":"430636","messageId":"xmqq7dhlhs7d.fsf@gitster.g","threadId":"56101","inReplyTo":"YPZ3JmWKLrUldK4R@coredump.intra.peff.net","subject":"Re: [PATCH] t0000: fix test if run with TEST_OUTPUT_DIRECTORY","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-07-20T16:21:10Z","receivedAt":"2021-07-20T16:26:35Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> On Tue, Jul 20, 2021 at 08:32:26AM +0200, Patrick Steinhardt wrote:\n>\n>> Fix the issue by adding a new TEST_OUTPUT_DIRECTORY_OVERRIDE variable.\n>> If set, then we'll always override the TEST_OUTPUT_DIRECTORY with its\n>> value after sourcing GIT-BUILD-OPTIONS.\n>\n> Thanks, I like this approach much better than removing\n> TEST_OUTPUT_DIRECTORY entirely (and I confirmed that it fixes the\n> problem).\n\nYup, and it combines with your subtests-skip fix rather nicely to\nsolve both problems.  Thanks for working well together.\n\n> I do wish we had a more generic way of overriding stuff in\n> GIT-BUILD-OPTIONS, rather than introducing manual _OVERRIDE variables\n> for each. But there's not an easy solution here (see the earlier thread\n> for some discussion), so this seems like a good immediate step to take.\n>\n> One small note on the commit message:\n>\n>> While this works as expected in the general case, it falls apart when\n>> the developer has TEST_OUTPUT_DIRECTORY explicitly defined either via\n>> the environment or via config.mak.\n>\n> The mention of the environment confused me for a moment, since:\n>\n>   TEST_OUTPUT_DIRECTORY=/tmp/foo ./t0000-basic.sh\n>\n> is already OK. But you probably meant that:\n>\n>   TEST_OUTPUT_DIRECTORY=/tmp/foo make test\n>\n> would fail, since \"make\" would pick up the variable and then write it\n> into GIT-BUILD-OPTIONS (just as it would if you put it in config.mak, or\n> on the command-line of make).\n>\n> I don't think it's sufficiently confusing to rewrite the commit message,\n> but just something I noted while reading it.\n\nI'll just insert \"and runs 'make test'\" after \"via config.mak\" while\nqueuing.\n\nAgain, thanks, both.\n"},{"id":"432568","messageId":"c3eed187-6f16-65eb-a4e5-cb747ba5f36a@gmail.com","threadId":"56101","inReplyTo":"xmqqk0lrtuh4.fsf_-_@gitster.g","subject":"Re: [PATCH] CodingGuidelines: recommend gender-neutral description","fromName":"Bagas Sanjaya","fromEmail":"bagasdotme@gmail.com","sentAt":"2021-08-12T08:35:32Z","receivedAt":"2021-08-12T08:35:42Z","isPatch":true,"sender":{"key":"bagasdotme@gmail.com","avatar":"https://avatars.githubusercontent.com/u/40219486?v=4"},"body":"On 15/07/21 23.25, Junio C Hamano wrote:\n> +  - If you still need to refer to an example person that is\n> +    third-person singular, you may resort to \"singular they\" to avoid\n> +    \"he/she/him/her\", e.g.\n> +\n> +      A contributor asks their upstream to pull from them.\n> +\n> +    Note that this sounds ungrammatical and unnatural to those who\n> +    learned English as a second language in some parts of the world.\n> +\n\nAddendum: For grammatical correctness (for ESL people), proper, plural \nthey can be used. So the last example can be rewritten as:\n\n   Contributors ask their upstream to pull from their repository.\n\n-- \nAn old man doll... just what I always wanted! - Clara\n"}]}