All of lore.kernel.org
 help / color / mirror / Atom feed
* What's cooking in git.git (Jul 2021, #03; Tue, 13)
@ 2021-07-14  1:07 Junio C Hamano
  2021-07-14  2:16 ` Eric Sunshine
                   ` (4 more replies)
  0 siblings, 5 replies; 43+ messages in thread
From: Junio C Hamano @ 2021-07-14  1:07 UTC (permalink / raw)
  To: git

Here are the topics that have been cooking in my tree.  Commits
prefixed with '+' are in 'next' (being in 'next' is a sign that a
topic is stable enough to be used and are candidate to be in a
future release).  Commits prefixed with '-' are only in 'seen',
which means nothing more than that I have found them of interest for
some reason (like "it may have hard-to-resolve conflicts with
another topic already in flight" or "this may turn out to be
useful").  Do not read too much into a topic being in (or not in)
'seen'.  The ones marked with '.' do not appear in any of the
integration branches, but I am still holding onto them.

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

With maint, master, next, seen, todo:

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

With all the integration branches and topics broken out:

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

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

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

Release tarballs are available at:

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

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

* ab/describe-tests-fix (2021-05-11) 5 commits
  (merged to 'next' on 2021-07-06 at ba1f7c0364)
 + describe tests: support -C in "check_describe"
 + describe tests: fix nested "test_expect_success" call
 + describe tests: don't rely on err.actual from "check_describe"
 + describe tests: refactor away from glob matching
 + describe tests: improve test for --work-tree & --dirty

 Various updates to tests around "git describe"


* ab/pickaxe-pcre2 (2021-05-11) 22 commits
  (merged to 'next' on 2021-07-06 at fdb4fdc245)
 + xdiff-interface: replace discard_hunk_line() with a flag
 + xdiff users: use designated initializers for out_line
 + pickaxe -G: don't special-case create/delete
 + pickaxe -G: terminate early on matching lines
 + xdiff-interface: allow early return from xdiff_emit_line_fn
 + xdiff-interface: prepare for allowing early return
 + pickaxe -S: slightly optimize contains()
 + pickaxe: rename variables in has_changes() for brevity
 + pickaxe -S: support content with NULs under --pickaxe-regex
 + pickaxe: assert that we must have a needle under -G or -S
 + pickaxe: refactor function selection in diffcore-pickaxe()
 + perf: add performance test for pickaxe
 + pickaxe/style: consolidate declarations and assignments
 + diff.h: move pickaxe fields together again
 + pickaxe: die when --find-object and --pickaxe-all are combined
 + pickaxe: die when -G and --pickaxe-regex are combined
 + pickaxe tests: add missing test for --no-pickaxe-regex being an error
 + pickaxe tests: test for -G, -S and --find-object incompatibility
 + pickaxe tests: add test for "log -S" not being a regex
 + pickaxe tests: add test for diffgrep_consume() internals
 + pickaxe tests: refactor to use test_commit --append --printf
 + grep/pcre2 tests: reword comments referring to kwset

 Rewrite the backend for "diff -G/-S" to use pcre2 engine when
 available.


* ab/pre-auto-gc-hook-test (2021-06-16) 1 commit
  (merged to 'next' on 2021-07-06 at 305a15ee1d)
 + gc tests: add a test for the "pre-auto-gc" hook

 Test fix.


* bk/doc-commit-typofix (2021-06-28) 1 commit
  (merged to 'next' on 2021-07-06 at 88580c54ed)
 + Documentation: fix typo in the --patch option of the commit command

 Doc typo/grammo-fix.


* dc/p4-binary-submit-fix (2021-06-28) 1 commit
  (merged to 'next' on 2021-07-06 at dec280fdc6)
 + git-p4: fix failed submit by skip non-text data files

 Prevent "git p4" from failing to submit changes to binary file.


* fc/push-simple-updates (2021-06-02) 7 commits
  (merged to 'next' on 2021-07-06 at 95c114f930)
 + doc: push: explain default=simple correctly
 + push: remove unused code in setup_push_upstream()
 + push: simplify setup_push_simple()
 + push: reorganize setup_push_simple()
 + push: copy code to setup_push_simple()
 + push: hedge code of default=simple
 + push: rename !triangular to same_remote
 (this branch is used by fc/push-simple-updates-cleanup.)

 Some code and doc clarification around "git push".


* fc/push-simple-updates-cleanup (2021-06-02) 13 commits
  (merged to 'next' on 2021-07-06 at da7fab5dc4)
 + push: don't get a full remote object
 + push: only check same_remote when needed
 + push: remove trivial function
 + push: remove redundant check
 + push: factor out the typical case
 + push: get rid of all the setup_push_* functions
 + push: trivial simplifications
 + push: make setup_push_* return the dst
 + push: only get the branch when needed
 + push: factor out null branch check
 + push: split switch cases
 + push: return immediately in trivial switch case
 + push: create new get_upstream_ref() helper
 (this branch uses fc/push-simple-updates.)

 Some more code and doc clarification around "git push".


* hn/prep-tests-for-reftable (2021-06-02) 22 commits
  (merged to 'next' on 2021-07-06 at 0d6f79d079)
 + t1415: set REFFILES for test specific to storage format
 + t4202: mark bogus head hash test with REFFILES
 + t7003: check reflog existence only for REFFILES
 + t7900: stop checking for loose refs
 + t1404: mark tests that muck with .git directly as REFFILES.
 + t2017: mark --orphan/logAllRefUpdates=false test as REFFILES
 + t1414: mark corruption test with REFFILES
 + t1407: require REFFILES for for_each_reflog test
 + test-lib: provide test prereq REFFILES
 + t5304: use "reflog expire --all" to clear the reflog
 + t5304: restyle: trim empty lines, drop ':' before >
 + t7003: use rev-parse rather than FS inspection
 + t5000: inspect HEAD using git-rev-parse
 + t5000: reformat indentation to the latest fashion
 + t1301: fix typo in error message
 + t1413: use tar to save and restore entire .git directory
 + t1401-symbolic-ref: avoid direct filesystem access
 + t1401: use tar to snapshot and restore repo state
 + t5601: read HEAD using rev-parse
 + t9300: check ref existence using test-helper rather than a file system check
 + t/helper/ref-store: initialize oid in resolve-ref
 + t4202: split testcase for invalid HEAD symref and HEAD hash

 Preliminary clean-up of tests before the main reftable changes
 hits the codebase.


* jk/union-merge-binary (2021-06-11) 3 commits
  (merged to 'next' on 2021-07-06 at 5e77055895)
 + ll_union_merge(): rename path_unused parameter
 + ll_union_merge(): pass name labels to ll_xdl_merge()
 + ll_binary_merge(): handle XDL_MERGE_FAVOR_UNION

 The "union" conflict resolution variant misbehaved when used with
 binary merge driver.


* mr/cmake (2021-06-11) 3 commits
  (merged to 'next' on 2021-07-06 at efc86eb8fb)
 + cmake: add warning for ignored MSGFMT_EXE
 + cmake: create compile_commands.json by default
 + cmake: add knob to disable vcpkg

 CMake update.


* rs/grep-parser-fix (2021-06-30) 1 commit
  (merged to 'next' on 2021-07-06 at 8c582fcd64)
 + grep: report missing left operand of --and

 "git grep --and -e foo" ought to have been diagnosed as an error
 but instead segfaulted, which has been corrected.


* zh/cat-file-batch-fix (2021-06-04) 2 commits
  (merged to 'next' on 2021-07-01 at 28b788e905)
 + cat-file: merge two block into one
 + cat-file: handle trivial --batch format with --batch-all-objects
 (this branch is used by zh/ref-filter-raw-data.)

 "git cat-file --batch-all-objects"" misbehaved when "--batch" is in
 use and did not ask for certain object traits.

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

* dl/packet-read-response-end-fix (2021-07-09) 1 commit
 - pkt-line: replace "stateless separator" with "response end"

 Error message update.

 Will merge to 'next'.


* hj/commit-allow-empty-message (2021-07-09) 2 commits
 - commit: remove irrelavent prompt on `--allow-empty-message`
 - commit: reorganise commit hint strings

 "git commit --allow-empty-message" won't abort the operation upon
 an empty message, but the hint shown in the editor said otherwise.

 Will merge to 'next'.


* ab/attribute-format (2021-07-13) 6 commits
 - strbuf.h: add a comment about "missing" strftime() checking
 - advice.h: add missing __attribute__((format)) & fix usage
 - *.h: add a few missing __attribute__((format))
 - *.c static functions: add missing __attribute__((format))
 - sequencer.c: move static function to avoid forward decl
 - *.c static functions: don't forward-declare __attribute__

 Many "printf"-like helper functions we have have been annotated
 with __attribute__() to catch placeholder/parameter mismatches.

 Will merge to 'next'.


* dl/diff-merge-base (2021-07-12) 1 commit
 - git-diff: fix missing --merge-base docs

 "git diff --merge-base" documentation has been updated.

 Will merge to 'next'.


* en/rename-limits-doc (2021-07-12) 3 commits
 - diff: correct warning message when renameLimit exceeded
 - doc: document the special handling of -l0
 - doc: clarify documentation for rename/copy limits

 Update documentation on "git diff -l<n>" and diff.renameLimit.

 Expecting a reroll.
 cf. <c25e29a9-3a15-4079-43fd-b77746927b16@gmail.com>
 cf. <CAPig+cTFoLaUd8+VRsaJuP24C7fnbTTFx0i7PizyasES7K2jdg@mail.gmail.com>
 cf. <CABPp-BHF3Os7fOeaF_EQOo+Bs7f1DXbYr26WmAQrPjv63nq1Pg@mail.gmail.com>


* jk/typofix (2021-07-13) 1 commit
  (merged to 'next' on 2021-07-13 at cce3caa34e)
 + doc/rev-list-options: fix duplicate word typo

 Typofix.

 Will merge to 'master'.

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

* hn/reftable (2021-05-20) 27 commits
 . t1404: annotate test cases with REFFILES
 . t1401,t2011: parameterize HEAD.lock for REFTABLE
 . t1301: document what needs to be done for REFTABLE
 . Add "test-tool dump-reftable" command.
 . git-prompt: prepare for reftable refs backend
 . Reftable support for git-core
 . reftable: add dump utility
 . reftable: implement stack, a mutable database of reftable files.
 . reftable: implement refname validation
 . reftable: add merged table view
 . reftable: add a heap-based priority queue for reftable records
 . reftable: reftable file level tests
 . reftable: read reftable files
 . reftable: generic interface to tables
 . reftable: write reftable files
 . reftable: a generic binary tree implementation
 . reftable: reading/writing blocks
 . Provide zlib's uncompress2 from compat/zlib-compat.c
 . reftable: (de)serialization for the polymorphic record type.
 . reftable: add blocksource, an abstraction for random access reads
 . reftable: utility functions
 . reftable: add error related functionality
 . reftable: add LICENSE
 . init-db: set the_repository->hash_algo early on
 . hash.h: provide constants for the hash IDs
 . refs/debug: trace into reflog expiry too
 . refs: document reflog_expire_fn's flag argument
 (this branch uses hn/refs-iterator-peel-returns-boolean.)

 The "reftable" backend for the refs API.


* ao/p4-avoid-decoding (2021-04-12) 2 commits
 - git-p4: do not decode data from perforce by default
 - git-p4: avoid decoding more data from perforce

 "git p4" in Python-2 days used to accept a lot more kinds of data
 from Perforce server as uninterrupted byte sequence, but after
 switching to Python-3, too many things are expected to be in UTF-8,
 which broke traditional use cases.

 Waiting for reviews.


* tv/p4-fallback-encoding (2021-04-30) 1 commit
 - git-p4: git-p4.fallbackEncoding to specify non UTF-8 charset

 "git p4" learns the fallbackEncoding configuration variable to
 safely accept changeset descriptions that aren't written in UTF-8.

 Waiting for reviews.

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

* ab/gitignore-discovery-doc (2021-07-06) 1 commit
  (merged to 'next' on 2021-07-13 at 02f3b3deab)
 + docs: .gitignore parsing is to the top of the repo

 Doc update.

 Will merge to 'master'.


* bc/rev-list-without-commit-line (2021-07-12) 1 commit
  (merged to 'next' on 2021-07-13 at 1ceed60061)
 + rev-list: add option for --pretty=format without header

 "git rev-list" learns to omit the "commit <object-name>" header
 lines from the output with the `--no-commit-header` option.

 Will merge to 'master'.


* ab/imap-send-read-everything-simplify (2021-07-07) 1 commit
  (merged to 'next' on 2021-07-13 at ab59128bfb)
 + imap-send.c: use less verbose strbuf_fread() idiom

 Code simplification.

 Will merge to 'master'.


* ab/pkt-line-tests (2021-07-12) 5 commits
 - test-lib-functions.sh: remove unused [de]packetize() functions
 - tests: replace remaining packetize() with "test-tool pkt-line"
 - tests: replace [de]packetize() shell+perl test-tool pkt-line
 - serve tests: use test_cmp in "protocol violations" test
 - serve tests: add missing "extra delim" test

 Update tests to cover a bit more protocol bits and unify two
 similar test helpers into one.

 Expecting a reroll for a couple of small "correctness" things...
 cf.<YO3+3F5fRONVtqTI@coredump.intra.peff.net>


* ab/lib-subtest (2021-07-01) 8 commits
 - test-lib tests: assert 1 exit code, not non-zero
 - test-lib tests: refactor common part of check_sub_test_lib_test*()
 - test-lib tests: avoid subshell for "test_cmp" for readability
 - test-lib tests: get rid of copy/pasted mock test code
 - test-lib tests: don't provide a description for the sub-tests
 - test-lib tests: stop using a subshell in write_sub_test_lib_test()
 - test-lib tests: split up "write and run" into two functions
 - test-lib tests: move "run_sub_test" to a new lib-subtest.sh

 Refactor tests on test framework.

 Needs review.


* ab/struct-init (2021-07-01) 5 commits
  (merged to 'next' on 2021-07-09 at 8aec33fe39)
 + string-list.h users: change to use *_{nodup,dup}()
 + string-list.[ch]: add a string_list_init_{nodup,dup}()
 + dir.[ch]: replace dir_init() with DIR_INIT
 + *.c *_init(): define in terms of corresponding *_INIT macro
 + *.h: move some *_INIT to designated initializers

 Code cleanup around struct_type_init() functions.

 Will merge to 'master'.


* bc/inactive-submodules (2021-07-02) 1 commit
 - submodule: mark submodules with update=none as inactive

 Usability update for inactive submodules.

 Under review.
 cf. <fc5ec100-1d42-4199-236e-7a99c9218f38@gmail.com>
 cf. <bf1893ee-6973-d8b2-659e-bb239a0a9ae2@gmail.com>


* en/ort-perf-batch-14 (2021-07-13) 7 commits
 - merge-ort: restart merge with cached renames to reduce process entry cost
 - merge-ort: avoid recursing into directories when we don't need to
 - merge-ort: defer recursing into directories when merge base is matched
 - merge-ort: add a handle_deferred_entries() helper function
 - merge-ort: add data structures for allowable trivial directory resolves
 - merge-ort: add some more explanations in collect_merge_info_callback()
 - merge-ort: resolve paths early when we have sufficient information

 Further optimization on "merge -sort" backend.

 Reviews?


* ar/help-micro-cleanup (2021-07-06) 1 commit
  (merged to 'next' on 2021-07-09 at d8e428c6fd)
 + help: convert git_cmd to page in one place

 Tiny code clean-up.

 Will merge to 'master'.


* ar/submodule-helper-include-cleanup (2021-07-06) 1 commit
  (merged to 'next' on 2021-07-09 at 7e1d15fb86)
 + submodule--helper: remove redundant include

 Code clean-up.

 Will merge to 'master'.


* cf/fetch-set-upstream-while-detached (2021-07-06) 1 commit
 - fetch: fix segfault on --set-upstream while on a detached HEAD

 "git fetch --set-upstream" while on detached HEAD segfaulted
 instead of noticing that such an operation did not make sense.

 Expecting a reroll.


* dd/test-stdout-count-lines (2021-07-06) 3 commits
  (merged to 'next' on 2021-07-09 at 19200fa2e0)
 + t6402: preserve git exit status code
 + t6400: preserve git ls-files exit status code
 + test-lib-functions: introduce test_stdout_line_count

 Tiny test clean-up.

 Will merge to 'master'.


* hn/refs-iterator-peel-returns-boolean (2021-05-20) 1 commit
  (merged to 'next' on 2021-07-08 at b9b35881ba)
 + refs: make explicit that ref_iterator_peel returns boolean
 (this branch is used by hn/reftable.)

 Tiny API tweak.

 Will merge to 'master'.


* hn/refs-test-cleanup (2021-07-06) 2 commits
  (merged to 'next' on 2021-07-09 at ae08de6afc)
 + t7509: avoid direct file access for writing CHERRY_PICK_HEAD
 + t1415: avoid direct filesystem access for writing refs

 Test clean-up.

 Will merge to 'master'.


* ps/perf-with-separate-output-directory (2021-07-02) 1 commit
 - perf: fix when running with TEST_OUTPUT_DIRECTORY

 Test update.

 What's the status of this one?


* rs/khash-alloc-cleanup (2021-07-06) 1 commit
  (merged to 'next' on 2021-07-09 at a01d1bb8c9)
 + khash: clarify that allocations never fail

 Code clean-up.

 Will merge to 'master'.


* sm/worktree-add-lock (2021-07-12) 3 commits
 - worktree: teach `add` to accept --reason <string> with --lock
 - worktree: mark lock strings with `_()` for translation
 - t2400: clean up '"add" worktree with lock' test

 "git worktree add --lock" learned to record why the worktree is
 locked with a custom message.

 Ready?


* ab/bundle-doc (2021-07-02) 3 commits
 - bundle doc: elaborate on rev<->ref restriction
 - bundle doc: elaborate on object prerequisites
 - bundle doc: rewrite the "DESCRIPTION" section

 Doc update.

 Expecting a reroll.
 at least for the second patch.


* ab/pack-stdin-packs-fix (2021-07-09) 2 commits
 - pack-objects: fix segfault in --stdin-packs option
 - pack-objects tests: cover blindspots in stdin handling

 Input validation of "git pack-objects --stdin-packs" has been
 corrected.

 Ack?
 cf. <YND3h2l10PlnSNGJ@nand.local>


* ds/commit-and-checkout-with-sparse-index (2021-07-12) 5 commits
 - checkout: stop expanding sparse indexes
 - sparse-index: recompute cache-tree
 - commit: integrate with sparse-index
 - p2000: compress repo names
 - p2000: add 'git checkout -' test and decrease depth
 (this branch uses ds/status-with-sparse-index.)

 "git checkout" and "git commit" learn to work without unnecessarily
 expanding sparse indexes.

 Ready?


* en/merge-dir-rename-corner-case-fix (2021-06-30) 3 commits
  (merged to 'next' on 2021-07-08 at cf7087576e)
 + merge-recursive: handle rename-to-self case
 + merge-ort: ensure we consult df_conflict and path_conflicts
 + t6423: test directory renames causing rename-to-self

 The merge code had funny interactions between content based rename
 detection and directory rename detection.

 Will merge to 'master'.


* ew/many-alternate-optim (2021-07-07) 5 commits
 - oidtree: a crit-bit tree for odb_loose_cache
 - oidcpy_with_padding: constify `src' arg
 - make object_directory.loose_objects_subdir_seen a bitmap
 - avoid strlen via strbuf_addstr in link_alt_odb_entry
 - speed up alt_odb_usable() with many alternates

 Optimization for repositories with many alternate object store.

 Will merge to 'next'?


* jk/log-decorate-optim (2021-07-13) 7 commits
 - load_ref_decorations(): fix decoration with tags
  (merged to 'next' on 2021-07-08 at a3b6f978ab)
 + add_ref_decoration(): rename s/type/deco_type/
 + load_ref_decorations(): avoid parsing non-tag objects
 + object.h: add lookup_object_by_type() function
 + object.h: expand docstring for lookup_unknown_object()
 + log: avoid loading decorations for userformats that don't need it
 + pretty.h: update and expand docstring for userformat_find_requirements()

 Optimize "git log" for cases where we wasted cycles to load ref
 decoration data that may not be needed.

 Will merge to 'next'.


* js/ci-windows-update (2021-07-06) 7 commits
  (merged to 'next' on 2021-07-13 at 329771e960)
 + ci: accelerate the checkout
 + ci (vs-build): build with NO_GETTEXT
 + artifacts-tar: respect NO_GETTEXT
 + ci (windows): transfer also the Git-tracked files to the test jobs
 + ci: upgrade to using actions/{up,down}load-artifacts v2
 + ci (vs-build): use `cmd` to copy the DLLs, not `powershell`
 + ci: use the new GitHub Action to download git-sdk-64-minimal

 GitHub Actions / CI update.

 Will merge to 'master'.


* js/config-mak-windows-pcre-fix (2021-06-28) 1 commit
  (merged to 'next' on 2021-07-08 at fe457da682)
 + config.mak.uname: PCRE1 cleanup

 Whitespace fix.

 Will merge to 'master'.


* js/gfw-system-config-loc-fix (2021-06-28) 3 commits
  (merged to 'next' on 2021-07-08 at 91a090ab50)
 + config: normalize the path of the system gitconfig
 + cmake(windows): set correct path to the system Git config
 + mingw: move Git for Windows' system config where users expect it

 Update the location of system-side configuration file on Windows.

 Will merge to 'master'.


* jt/push-negotiation-fixes (2021-06-28) 3 commits
 - fetch: die on invalid --negotiation-tip hash
 - send-pack: fix push nego. when remote has refs
 - send-pack: fix push.negotiate with remote helper

 Bugfix for common ancestor negotiation recently introduced in "git
 push" codepath.

 Needs review.


* ks/submodule-cleanup (2021-06-28) 1 commit
  (merged to 'next' on 2021-07-08 at 03ba93067f)
 + submodule: remove unnecessary `prefix` based option logic

 Code cleanup.

 Will merge to 'master'.


* tb/midx-use-checksum (2021-06-28) 4 commits
  (merged to 'next' on 2021-07-08 at bbaac9c721)
 + midx: report checksum mismatches during 'verify'
 + midx: don't reuse corrupt MIDXs when writing
 + commit-graph: rewrite to use checksum_valid()
 + csum-file: introduce checksum_valid()

 When rebuilding the multi-pack index file reusing an existing one,
 we used to blindly trust the existing file and ended up carrying
 corrupted data into the updated file, which has been corrected.

 Will merge to 'master'.


* ab/bundle-updates (2021-07-06) 3 commits
  (merged to 'next' on 2021-07-08 at 0c9c54fad7)
 + bundle: remove "ref_list" in favor of string-list.c API
 + bundle.c: use a temporary variable for OIDs and names
 + bundle cmd: stop leaking memory from parse_options_cmd_bundle()

 Code clean-up and leak plugging in "git bundle".

 Will merge to 'master'.


* ab/fetch-negotiate-segv-fix (2021-07-08) 3 commits
  (merged to 'next' on 2021-07-08 at 30dcd90ea6)
 + fetch: fix segfault in --negotiate-only without --negotiation-tip=*
 + fetch: document the --negotiate-only option
 + send-pack.c: move "no refs in common" abort earlier

 Code recently added to support common ancestry negotiation during
 "git push" did not sanity check its arguments carefully enough.

 Will merge to 'master'.


* ab/make-delete-on-error (2021-06-29) 1 commit
  (merged to 'next' on 2021-07-08 at 787d70d2d6)
 + Makefile: add and use the ".DELETE_ON_ERROR" flag

 Use ".DELETE_ON_ERROR" pseudo target to simplify our Makefile.

 Will merge to 'master'.


* ab/make-tags-cleanup (2021-06-29) 5 commits
 - Makefile: normalize clobbering & xargs for tags targets
 - Makefile: don't use "FORCE" for tags targets
 - Makefile: fix "cscope" target to refer to cscope.out
 - Makefile: add QUIET_GEN to "cscope" target
 - Makefile: move ".PHONY: cscope" near its target

 Build clean-up for "make tags" and friends.

 Expecting a reroll.
 Hopefully with a final reroll it would become good enough shape for 'next'?
 cf. <YN5AwdVC3QAcy2tA@coredump.intra.peff.net>
 cf. <67c45b13-df8f-8065-377a-fbd2f80992ee@ramsayjones.plus.com>


* ew/mmap-failures (2021-06-29) 1 commit
  (merged to 'next' on 2021-07-08 at e0e19d5d26)
 + xmmap: inform Linux users of tuning knobs on ENOMEM

 Error message update.

 Will merge to 'master'.


* tb/multi-pack-bitmaps (2021-06-28) 24 commits
 - p5326: perf tests for MIDX bitmaps
 - p5310: extract full and partial bitmap tests
 - midx: respect 'GIT_TEST_MULTI_PACK_INDEX_WRITE_BITMAP'
 - t7700: update to work with MIDX bitmap test knob
 - t5319: don't write MIDX bitmaps in t5319
 - t5310: disable GIT_TEST_MULTI_PACK_INDEX_WRITE_BITMAP
 - t0410: disable GIT_TEST_MULTI_PACK_INDEX_WRITE_BITMAP
 - t5326: test multi-pack bitmap behavior
 - t/helper/test-read-midx.c: add --checksum mode
 - t5310: move some tests to lib-bitmap.sh
 - pack-bitmap: write multi-pack bitmaps
 - pack-bitmap: read multi-pack bitmaps
 - pack-bitmap.c: introduce 'bitmap_is_preferred_refname()'
 - pack-bitmap.c: introduce 'nth_bitmap_object_oid()'
 - pack-bitmap.c: introduce 'bitmap_num_objects()'
 - midx: infer preferred pack when not given one
 - midx: respect 'core.multiPackIndex' when writing
 - midx: clear auxiliary .rev after replacing the MIDX
 - midx: make a number of functions non-static
 - Documentation: describe MIDX-based bitmaps
 - Documentation: build 'technical/bitmap-format' by default
 - pack-bitmap-write.c: free existing bitmaps
 - pack-bitmap-write.c: gracefully fail to write non-closed bitmaps
 - pack-bitmap.c: harden 'test_bitmap_walk()' to check type bitmaps

 The reachability bitmap file used to be generated only for a single
 pack, but now we've learned to generate bitmaps for history that
 span across multiple packfiles.

 Comments?


* ds/status-with-sparse-index (2021-07-12) 15 commits
 - fsmonitor: integrate with sparse index
 - wt-status: expand added sparse directory entries
 - status: use sparse-index throughout
 - status: skip sparse-checkout percentage with sparse-index
 - diff-lib: handle index diffs with sparse dirs
 - dir.c: accept a directory as part of cone-mode patterns
 - unpack-trees: unpack sparse directory entries
 - unpack-trees: rename unpack_nondirectories()
 - unpack-trees: compare sparse directories correctly
 - unpack-trees: preserve cache_bottom
 - t1092: add tests for status/add and sparse files
 - t1092: expand repository data shape
 - t1092: replace incorrect 'echo' with 'cat'
 - sparse-index: include EXTENDED flag when expanding
 - sparse-index: skip indexes with unmerged entries
 (this branch is used by ds/commit-and-checkout-with-sparse-index.)

 "git status" codepath learned to work with sparsely populated index
 without hydrating it fully.

 Expecting a final reroll.
 cf. <e7199fc6-bc7b-f556-c10c-12dee04af287@gmail.com>


* ab/config-based-hooks-base (2021-06-29) 33 commits
 - hooks: fix a TOCTOU in "did we run a hook?" heuristic
 - receive-pack: convert receive hooks to hook.h
 - post-update: use hook.h library
 - receive-pack: convert 'update' hook to hook.h
 - hooks: allow callers to capture output
 - run-command: allow capturing of collated output
 - reference-transaction: use hook.h to run hooks
 - transport: convert pre-push hook to use config
 - hook: convert 'post-rewrite' hook in sequencer.c to hook.h
 - hook: provide stdin by string_list or callback
 - run-command: add stdin callback for parallelization
 - am: convert 'post-rewrite' hook to hook.h
 - hook: support passing stdin to hooks
 - run-command: allow stdin for run_processes_parallel
 - run-command: remove old run_hook_{le,ve}() hook API
 - receive-pack: convert push-to-checkout hook to hook.h
 - read-cache: convert post-index-change hook to use config
 - commit: use hook.h to execute hooks
 - git-p4: use 'git hook' to run hooks
 - send-email: use 'git hook run' for 'sendemail-validate'
 - git hook run: add an --ignore-missing flag
 - merge: use config-based hooks for post-merge hook
 - hooks: convert 'post-checkout' hook to hook library
 - am: convert applypatch hooks to use config
 - rebase: teach pre-rebase to use hook.h
 - gc: use hook library for pre-auto-gc hook
 - hook: add 'run' subcommand
 - hook-list.h: add a generated list of hooks, like config-list.h
 - hook.c: add a hook_exists() wrapper and use it in bugreport.c
 - hook.[ch]: move find_hook() to this new library
 - Makefile: remove an out-of-date comment
 - Makefile: stop hardcoding {command,config}-list.h
 - Makefile: mark "check" target as .PHONY

 Restructuring of (a subset of) Emily's config-based-hooks series,
 to demonstrate that a series can be presented as a more logical and
 focused progression.

 Waiting for reviews.


* ab/doc-retire-alice-bob (2021-06-16) 6 commits
 - pack-protocol doc: use "www-data" in place of "alice"
 - doc: replace "alice" and "bob" with "jdoe" and "msmith"
 - fast-import doc: change "bob" in an example to "file.txt"
 - daemon doc + code comments: reword "alice" example
 - gitcvs-migration doc: replace "alice" and "bob" with "you" and "www-data"
 - gittutorial doc: replace "alice" and "bob" with "you" and "www-data"

 Documentation update to avoid Alice and Bob in contexts where Eve
 does not appear in.

 Will discard.
 Let's shelve this one for now, as it does not seem to solve any
 real problems (other than ceasing to use Alice and Bob in contexts
 that do not call for Eve).


* en/ort-perf-batch-13 (2021-06-28) 5 commits
  (merged to 'next' on 2021-07-08 at 39aad121d3)
 + merge-ort: add prefetching for content merges
 + diffcore-rename: use a different prefetch for basename comparisons
 + diffcore-rename: allow different missing_object_cb functions
 + t6421: add tests checking for excessive object downloads during merge
 + promisor-remote: output trace2 statistics for number of objects fetched

 Performance tweaks of "git merge -sort" around lazy fetching of objects.

 Will merge to 'master'.


* ab/serve-cleanup (2021-06-28) 8 commits
 - upload-pack.c: convert to new serve.c "startup" config cb
 - serve: add support for a "startup" git_config() callback
 - serve.c: add trace2 regions for advertise & command
 - serve.c: add call_{advertise,command}() indirection
 - serve: use designated initializers
 - transport: use designated initializers
 - transport: rename "fetch" in transport_vtable to "fetch_refs"
 - serve: mark has_capability() as static

 Code clean-up around "git serve".

 Expecting a reroll.
 cf. <cover-0.8-00000000000-20210628T191634Z-avarab@gmail.com>


* jt/partial-clone-submodule-1 (2021-06-28) 5 commits
  (merged to 'next' on 2021-07-09 at 2bc8c2c4dd)
 + promisor-remote: teach lazy-fetch in any repo
 + run-command: refactor subprocess env preparation
 + submodule: refrain from filtering GIT_CONFIG_COUNT
 + promisor-remote: support per-repository config
 + repository: move global r_f_p_c to repo struct

 Prepare the internals for lazily fetching objects in submodules
 from their promisor remotes.

 Will merge to 'master'.


* ab/mktag-tests (2021-06-28) 6 commits
  (merged to 'next' on 2021-07-08 at bfd55b0a38)
 + mktag tests: test fast-export
 + mktag tests: test for-each-ref
 + mktag tests: test update-ref and reachable fsck
 + mktag tests: test hash-object --literally and unreachable fsck
 + mktag tests: invert --no-strict test
 + mktag tests: parse out options in helper

 Fill test gaps.

 Will merge to 'master'.


* ab/show-branch-tests (2021-06-28) 4 commits
  (merged to 'next' on 2021-07-08 at 47f90868cf)
 + show-branch tests: add missing tests
 + show-branch: don't <COLOR></RESET> for space characters
 + show-branch tests: modernize test code
 + show-branch tests: rename the one "show-branch" test file

 Fill test gaps.

 Will merge to 'master'.


* es/superproject-aware-submodules (2021-06-16) 5 commits
 - SQUASH???
 - submodule: cache superproject gitdir during 'update'
 - submodule: cache superproject gitdir during absorbgitdirs
 - introduce submodule.superprojectGitDir cache
 - t7400-submodule-basic: modernize inspect() helper

 A configuration variable in a submodule points at the location of
 the superproject it is bound to (RFC).

 Waiting for reviews.


* en/zdiff3 (2021-06-15) 2 commits
 - update documentation for new zdiff3 conflictStyle
 - xdiff: implement a zealous diff3, or "zdiff3"

 "Zealous diff3" style of merge conflict presentation has been added.

 Expecting a reroll.
 cf. <CABPp-BE7-E03+x38EK-=AE5mwwdST+d50hiiud2eY2Nsf3rM5g@mail.gmail.com>


* pw/diff-color-moved-fix (2021-06-15) 10 commits
 - diff --color-moved: intern strings
 - diff --color-moved-ws=allow-indentation-change: improve hash lookups
 - diff --color-moved: stop clearing potential moved blocks
 - diff --color-moved: shrink potential moved blocks as we go
 - diff --color-moved: unify moved block growth functions
 - diff --color-moved: call comparison function directly
 - diff --color-moved-ws=allow-indentation-change: simplify and optimize
 - diff: simplify allow-indentation-change delta calculation
 - diff --color-moved: avoid false short line matches and bad zebra coloring
 - diff --color-moved=zebra: fix alternate coloring

 Long-overdue correctness and performance update to "diff
 --color-moved" feature.

 Expecting a reroll.
 cf. <094f5e5f-d447-8867-a9a7-be5c8827bba6@gmail.com>


* hn/refs-errno-cleanup (2021-07-07) 6 commits
 - refs: make errno output explicit for refs_resolve_ref_unsafe
 - refs: explicitly return failure_errno from parse_loose_ref_contents
 - refs: add failure_errno to refs_read_raw_ref() signature
 - refs: make errno output explicit for read_raw_ref_fn
 - refs/files-backend: stop setting errno from lock_ref_oid_basic
 - refs: remove EINVAL errno output from specification of read_raw_ref_fn

 Futz with the way 'errno' is relied on in the refs API to carry the
 failure modes up the callchain.

 Expecting a (hopefully final) reroll.
 cf. <CAFQ2z_NzykfcBSvtHQ10RZWxLP48+qArZk9HbDJQB4tNX-GtYA@mail.gmail.com>


* ab/test-tool-cache-cleanup (2021-06-08) 4 commits
 - read-cache perf: add a perf test for refresh_index()
 - test-tool: migrate read-cache-again to parse_options()
 - test-tool: migrate read-cache-perf to parse_options()
 - test-tool: split up test-tool read-cache

 Test code shuffling.

 Waiting for reviews.


* ab/pack-objects-stdin (2021-07-09) 5 commits
 - pack-objects.c: make use of REV_INFO_STDIN_LINE_PROCESS
 - pack-objects.c: do stdin parsing via revision.c's API
 - revision.[ch]: add a "handle_stdin_line" API
 - revision.h: refactor "disable_stdin" and "read_from_stdin"
 - upload-pack: run is_repository_shallow() before setup_revisions()

 Introduce handle_stdin_line callback to revision API and uses it.


* ar/submodule-add (2021-07-12) 4 commits
 - submodule--helper: introduce add-clone subcommand
 - submodule--helper: refactor module_clone()
 - submodule: prefix die messages with 'fatal'
 - t7400: test failure to add submodule in tracked path

 Rewrite of "git submodule" in C continues.

 Will merge to 'next'.


* ds/gender-neutral-doc (2021-06-16) 3 commits
  (merged to 'next' on 2021-07-09 at 57bb445576)
 + *: fix typos
 + comments: avoid using the gender of our users
 + doc: avoid using the gender of other people
 (this branch is used by ds/gender-neutral-doc-guidelines.)

 Update the documentation not to assume users are of certain gender
 and adds to guidelines to do so.

 Will merge to 'master'.


* ds/gender-neutral-doc-guidelines (2021-06-16) 2 commits
 - SQUASH??? replace neutering tips with that of Æver
 - CodingGuidelines: recommend singular they
 (this branch uses ds/gender-neutral-doc.)

 Attempt to give a guideline for gender neutral documentation.

 Comments?


* gh/gitweb-branch-sort (2021-06-10) 1 commit
 - gitweb: use HEAD as secondary sort key in git_get_heads_list()

 Tie-break branches that point at the same object in the list of
 branches on GitWeb to show the one pointed at by HEAD early.

 Waiting for reviews.


* lh/systemd-timers (2021-07-02) 3 commits
 - maintenance: add support for systemd timers on Linux
 - maintenance: `git maintenance run` learned `--scheduler=<scheduler>`
 - cache.h: Introduce a generic "xdg_config_home_for(…)" function

 "git maintenance" scheduler learned to use systemd timers as a
 possible backend.

 Waiting for reviews.


* fc/completion-updates (2021-06-07) 4 commits
 - completion: bash: add correct suffix in variables
 - completion: bash: fix for multiple dash commands
 - completion: bash: fix for suboptions with value
 - completion: bash: fix prefix detection in branch.*

 Command line completion updates.

 Expecting a reroll.
 cf. <60be6f7fa4435_db80d208f2@natae.notmuch>


* ab/update-submitting-patches (2021-06-08) 3 commits
 - SubmittingPatches: remove pine-specific hints from MUA hints
 - SubmittingPatches: replace discussion of Travis with GitHub Actions
 - SubmittingPatches: move discussion of Signed-off-by above "send"

 Reorganize and update the SubmitingPatches document.

 Expecting a reroll.
 cf. <20210607172542.GA6312@szeder.dev>
 cf. <nycvar.QRO.7.76.6.2106072346560.55@tvgsbejvaqbjf.bet>


* en/ort-perf-batch-12 (2021-06-09) 4 commits
  (merged to 'next' on 2021-07-08 at 4807694598)
 + merge-ort: miscellaneous touch-ups
 + Fix various issues found in comments
 + diffcore-rename: avoid unnecessary strdup'ing in break_idx
 + merge-ort: replace string_list_df_name_compare with faster alternative

 More fix-ups and optimization to "merge -sort".

 Will merge to 'master'.


* zh/ref-filter-raw-data (2021-07-12) 18 commits
 - cat-file: use fast path when using default_format
 - cat-file: create p1006-cat-file.sh
 - ref-filter: remove grab_oid() function
 - cat-file: re-implement --textconv, --filters options
 - cat-file: reuse err buf in batch_object_write()
 - cat-file: reuse ref-filter logic
 - cat-file: change batch_objects parameter name
 - cat-file: add has_object_file() check
 - ref-filter: modify the error message and value in get_object
 - ref-filter: introduce reject_atom()
 - ref-filter: introduce free_ref_array_item_value() function
 - ref-filter: pass get_object() return value to their callers
 - ref-filter: add %(rest) atom
 - ref-filter: use non-const ref_format in *_atom_parser()
 - ref-filter: --format=%(raw) re-support --perl
 - ref-filter: add %(raw) atom
 - ref-filter: add obj-type check in grab contents
 - Merge branch 'zh/cat-file-batch-fix' into zh/ref-filter-raw-data

 Prepare the "ref-filter" machinery that drives the "--format"
 option of "git for-each-ref" and its friends to be used in "git
 cat-file --batch".

 Heavy performance degradation has been observed with this series.


* jh/builtin-fsmonitor (2021-07-12) 35 commits
 - BANDAID: sparse fixes
 - t7527: test FS event reporing on MacOS WRT case and Unicode
 - fsmonitor: handle shortname for .git
 - t7527: test status with untracked-cache and fsmonitor--daemon
 - fsmonitor: force update index after large responses
 - fsmonitor: enhance existing comments
 - fsmonitor--daemon: use a cookie file to sync with file system
 - fsmonitor--daemon: periodically truncate list of modified files
 - t7527: create test for fsmonitor--daemon
 - t/perf/p7519: add fsmonitor--daemon test cases
 - t/perf: avoid copying builtin fsmonitor files into test repo
 - t/perf/p7519: speed up test using "test-tool touch"
 - t/helper/test-touch: add helper to touch a series of files
 - fsmonitor--daemon: implement handle_client callback
 - fsmonitor-fs-listen-macos: implement FSEvent listener on MacOS
 - fsmonitor-fs-listen-macos: add macos header files for FSEvent
 - fsmonitor-fs-listen-win32: implement FSMonitor backend on Windows
 - fsmonitor--daemon: create token-based changed path cache
 - fsmonitor--daemon: define token-ids
 - fsmonitor--daemon: add pathname classification
 - fsmonitor: do not try to operate on bare repos
 - fsmonitor--daemon: implement 'start' command
 - fsmonitor--daemon: implement 'run' command
 - fsmonitor-fs-listen-macos: stub in backend for MacOS
 - fsmonitor-fs-listen-win32: stub in backend for Windows
 - t/helper/fsmonitor-client: create IPC client to talk to FSMonitor Daemon
 - fsmonitor--daemon: implement 'stop' and 'status' commands
 - fsmonitor--daemon: add a built-in fsmonitor daemon
 - fsmonitor: use IPC to query the builtin FSMonitor daemon
 - fsmonitor: config settings are repository-specific
 - help: include fsmonitor--daemon feature flag in version info
 - fsmonitor-ipc: create client routines for git-fsmonitor--daemon
 - fsmonitor--daemon: update fsmonitor documentation
 - fsmonitor--daemon: man page
 - simple-ipc: preparations for supporting binary messages.

 An attempt to write and ship with a watchman equivalent tailored
 for our use.


* es/trace2-log-parent-process-name (2021-06-09) 1 commit
 - tr2: log parent process name

 trace2 logs learned to show parent process name to see in what
 context Git was invoked.

 Expecting a reroll.
 cf. <YNux62he9Mk43Y1B@google.com>


* ab/send-email-optim (2021-05-28) 13 commits
  (merged to 'next' on 2021-07-08 at 35ac315894)
 + perl: nano-optimize by replacing Cwd::cwd() with Cwd::getcwd()
 + send-email: move trivial config handling to Perl
 + perl: lazily load some common Git.pm setup code
 + send-email: lazily load modules for a big speedup
 + send-email: get rid of indirect object syntax
 + send-email: use function syntax instead of barewords
 + send-email: lazily shell out to "git var"
 + send-email: lazily load config for a big speedup
 + send-email: copy "config_regxp" into git-send-email.perl
 + send-email: refactor sendemail.smtpencryption config parsing
 + send-email: remove non-working support for "sendemail.smtpssl"
 + send-email tests: test for boolean variables without a value
 + send-email tests: support GIT_TEST_PERL_FATAL_WARNINGS=true

 "git send-email" optimization.

 Will merge to 'master'.


* ab/fsck-unexpected-type (2021-07-12) 21 commits
 - fsck: report invalid object type-path combinations
 - fsck: report invalid types recorded in objects
 - object-store.h: move read_loose_object() below 'struct object_info'
 - fsck: don't hard die on invalid object types
 - object-file.c: return -2 on "header too long" in unpack_loose_header()
 - object-file.c: return -1, not "status" from unpack_loose_header()
 - object-file.c: guard against future bugs in loose_object_info()
 - object-file.c: stop dying in parse_loose_header()
 - object-file.c: split up ternary in parse_loose_header()
 - object-file.c: simplify unpack_loose_short_header()
 - object-file.c: add missing braces to loose_object_info()
 - object-file.c: make parse_loose_header_extended() public
 - object-file.c: don't set "typep" when returning non-zero
 - cache.h: move object functions to object-store.h
 - cat-file tests: test for current --allow-unknown-type behavior
 - cat-file tests: add corrupt loose object test
 - rev-list tests: test for behavior with invalid object types
 - cat-file tests: test that --allow-unknown-type isn't on by default
 - cat-file tests: test for missing object with -t and -s
 - fsck tests: add test for fsck-ing an unknown type
 - fsck tests: refactor one test to use a sub-repo

 "git fsck" has been taught to report mismatch between expected and
 actual types of an object better.

 Needs review.

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: What's cooking in git.git (Jul 2021, #03; Tue, 13)
  2021-07-14  1:07 What's cooking in git.git (Jul 2021, #03; Tue, 13) Junio C Hamano
@ 2021-07-14  2:16 ` Eric Sunshine
  2021-07-14 16:30   ` Junio C Hamano
  2021-07-14  8:42 ` Han-Wen Nienhuys
                   ` (3 subsequent siblings)
  4 siblings, 1 reply; 43+ messages in thread
From: Eric Sunshine @ 2021-07-14  2:16 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Git List, Stephen Manz

On Tue, Jul 13, 2021 at 9:07 PM Junio C Hamano <gitster@pobox.com> wrote:
> * sm/worktree-add-lock (2021-07-12) 3 commits
>  - worktree: teach `add` to accept --reason <string> with --lock
>  - worktree: mark lock strings with `_()` for translation
>  - t2400: clean up '"add" worktree with lock' test
>
>  "git worktree add --lock" learned to record why the worktree is
>  locked with a custom message.
>
>  Ready?

I think this series is ready and gave my Reviewed-by: here[1]. One of
the new tests contains an unnecessary but harmless `test -f`[2], but
it's such a minor nit that I doubt it's worth demanding a re-roll.

[1]: https://lore.kernel.org/git/CAPig+cSVsJ9AtAMqtRQpyuosCDCGi+mu2C1PJUK49WTb5KvcWQ@mail.gmail.com/
[2]: https://lore.kernel.org/git/CAPig+cQVSUg1aqry_hMydJ=Uo=-VhOog6TUTpG=0on0LUcw8Dg@mail.gmail.com/

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: What's cooking in git.git (Jul 2021, #03; Tue, 13)
  2021-07-14  1:07 What's cooking in git.git (Jul 2021, #03; Tue, 13) Junio C Hamano
  2021-07-14  2:16 ` Eric Sunshine
@ 2021-07-14  8:42 ` Han-Wen Nienhuys
  2021-07-14 11:53   ` Ævar Arnfjörð Bjarmason
                     ` (2 more replies)
  2021-07-14 13:11 ` Derrick Stolee
                   ` (2 subsequent siblings)
  4 siblings, 3 replies; 43+ messages in thread
From: Han-Wen Nienhuys @ 2021-07-14  8:42 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

On Wed, Jul 14, 2021 at 3:07 AM Junio C Hamano <gitster@pobox.com> wrote:
> [Stalled]
>
> * hn/reftable (2021-05-20) 27 commits

I have some updates for the series pending, but I'm waiting for the
preliminaries (test fixes, the errno stuff) to hit master.

How do other folks deal with dependencies between topics?

> * hn/refs-errno-cleanup (2021-07-07) 6 commits
>  - refs: make errno output explicit for refs_resolve_ref_unsafe
>  - refs: explicitly return failure_errno from parse_loose_ref_contents
>  - refs: add failure_errno to refs_read_raw_ref() signature
>  - refs: make errno output explicit for read_raw_ref_fn
>  - refs/files-backend: stop setting errno from lock_ref_oid_basic
>  - refs: remove EINVAL errno output from specification of read_raw_ref_fn
>
>  Futz with the way 'errno' is relied on in the refs API to carry the
>  failure modes up the callchain.
>
>  Expecting a (hopefully final) reroll.
>  cf. <CAFQ2z_NzykfcBSvtHQ10RZWxLP48+qArZk9HbDJQB4tNX-GtYA@mail.gmail.com>

AEvar posted the corrected patch as part of his follow-up series.
(https://public-inbox.org/git/patch-04.17-270cda29c3a-20210711T162803Z-avarab@gmail.com/).
Would that work for you?

--
Han-Wen Nienhuys - Google Munich
I work 80%. Don't expect answers from me on Fridays.
--
Google Germany GmbH, Erika-Mann-Strasse 33, 80636 Munich
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: What's cooking in git.git (Jul 2021, #03; Tue, 13)
  2021-07-14  8:42 ` Han-Wen Nienhuys
@ 2021-07-14 11:53   ` Ævar Arnfjörð Bjarmason
  2021-07-14 11:54   ` Ævar Arnfjörð Bjarmason
  2021-07-14 17:28   ` Junio C Hamano
  2 siblings, 0 replies; 43+ messages in thread
From: Ævar Arnfjörð Bjarmason @ 2021-07-14 11:53 UTC (permalink / raw)
  To: Han-Wen Nienhuys; +Cc: Junio C Hamano, git


On Wed, Jul 14 2021, Han-Wen Nienhuys wrote:

> On Wed, Jul 14, 2021 at 3:07 AM Junio C Hamano <gitster@pobox.com> wrote:
>> [Stalled]
>>
>> * hn/reftable (2021-05-20) 27 commits
>
> I have some updates for the series pending, but I'm waiting for the
> preliminaries (test fixes, the errno stuff) to hit master.
>
> How do other folks deal with dependencies between topics?
>
>> * hn/refs-errno-cleanup (2021-07-07) 6 commits
>>  - refs: make errno output explicit for refs_resolve_ref_unsafe
>>  - refs: explicitly return failure_errno from parse_loose_ref_contents
>>  - refs: add failure_errno to refs_read_raw_ref() signature
>>  - refs: make errno output explicit for read_raw_ref_fn
>>  - refs/files-backend: stop setting errno from lock_ref_oid_basic
>>  - refs: remove EINVAL errno output from specification of read_raw_ref_fn
>>
>>  Futz with the way 'errno' is relied on in the refs API to carry the
>>  failure modes up the callchain.
>>
>>  Expecting a (hopefully final) reroll.
>>  cf. <CAFQ2z_NzykfcBSvtHQ10RZWxLP48+qArZk9HbDJQB4tNX-GtYA@mail.gmail.com>
>
> AEvar posted the corrected patch as part of his follow-up series.
> (https://public-inbox.org/git/patch-04.17-270cda29c3a-20210711T162803Z-avarab@gmail.com/).
> Would that work for you?

I re-rolled this just now as depending on:

    https://lore.kernel.org/git/patch-1.1-de0838fe99-20210714T111351Z-avarab@gmail.com

And submitted a s/v6\?/v7/g at:
https://lore.kernel.org/git/cover-0.6-0000000000-20210714T114301Z-avarab@gmail.com

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: What's cooking in git.git (Jul 2021, #03; Tue, 13)
  2021-07-14  8:42 ` Han-Wen Nienhuys
  2021-07-14 11:53   ` Ævar Arnfjörð Bjarmason
@ 2021-07-14 11:54   ` Ævar Arnfjörð Bjarmason
  2021-07-14 17:28   ` Junio C Hamano
  2 siblings, 0 replies; 43+ messages in thread
From: Ævar Arnfjörð Bjarmason @ 2021-07-14 11:54 UTC (permalink / raw)
  To: Han-Wen Nienhuys; +Cc: Junio C Hamano, git


On Wed, Jul 14 2021, Han-Wen Nienhuys wrote:

> On Wed, Jul 14, 2021 at 3:07 AM Junio C Hamano <gitster@pobox.com> wrote:
>> [Stalled]
>>
>> * hn/reftable (2021-05-20) 27 commits
>
> I have some updates for the series pending, but I'm waiting for the
> preliminaries (test fixes, the errno stuff) to hit master.
>
> How do other folks deal with dependencies between topics?

Not very well, but maybe this works for you.

If I had say a "ab/reftable" locally and it depended on
"ab/refs-errno-fixes" I'd rebase ab/refs-errno-fixes on top of
ab/reftable, and set the upstream info ("git branch --set-upstream-to")
to my pushed version of ab/reftable.

Thus "git log @{u}.." in "ab/reftable" gives me changes as of the
"ab/refs-errno-fixes" "base" topic, and git-format-patch/send-email will
send patches as of that topic.

Of course when you send this to the list you need to make that
dependency relationship clear, as in my just-submitted re-roll of
your/my refs.c errno changes:
https://lore.kernel.org/git/87im1d156t.fsf@evledraar.gmail.com/

I have no idea if/how this would work with gitgitgadget, which I think
you exclusively use.


^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: What's cooking in git.git (Jul 2021, #03; Tue, 13)
  2021-07-14  1:07 What's cooking in git.git (Jul 2021, #03; Tue, 13) Junio C Hamano
  2021-07-14  2:16 ` Eric Sunshine
  2021-07-14  8:42 ` Han-Wen Nienhuys
@ 2021-07-14 13:11 ` Derrick Stolee
  2021-07-14 14:32   ` Ævar Arnfjörð Bjarmason
  2021-07-14 20:11 ` What's cooking in git.git (Jul 2021, #03; Tue, 13) Taylor Blau
  2021-07-19  7:35 ` Patrick Steinhardt
  4 siblings, 1 reply; 43+ messages in thread
From: Derrick Stolee @ 2021-07-14 13:11 UTC (permalink / raw)
  To: Junio C Hamano, git

On 7/13/2021 9:07 PM, Junio C Hamano wrote:
...
> * en/ort-perf-batch-14 (2021-07-13) 7 commits
>  - merge-ort: restart merge with cached renames to reduce process entry cost
>  - merge-ort: avoid recursing into directories when we don't need to
>  - merge-ort: defer recursing into directories when merge base is matched
>  - merge-ort: add a handle_deferred_entries() helper function
>  - merge-ort: add data structures for allowable trivial directory resolves
>  - merge-ort: add some more explanations in collect_merge_info_callback()
>  - merge-ort: resolve paths early when we have sufficient information
> 
>  Further optimization on "merge -sort" backend.
> 
>  Reviews?

I saw a v2 re-roll, so I will review that this week.

> * ds/commit-and-checkout-with-sparse-index (2021-07-12) 5 commits
>  - checkout: stop expanding sparse indexes
>  - sparse-index: recompute cache-tree
>  - commit: integrate with sparse-index
>  - p2000: compress repo names
>  - p2000: add 'git checkout -' test and decrease depth
>  (this branch uses ds/status-with-sparse-index.)
> 
>  "git checkout" and "git commit" learn to work without unnecessarily
>  expanding sparse indexes.
> 
>  Ready?

Let's mark this as "expecting a re-roll" because of the
directory/file conflict issue. I'm trying to see if there
is a quick way to resolve the current behavior change that
Elijah pointed out.

> * ds/status-with-sparse-index (2021-07-12) 15 commits
>  - fsmonitor: integrate with sparse index
>  - wt-status: expand added sparse directory entries
>  - status: use sparse-index throughout
>  - status: skip sparse-checkout percentage with sparse-index
>  - diff-lib: handle index diffs with sparse dirs
>  - dir.c: accept a directory as part of cone-mode patterns
>  - unpack-trees: unpack sparse directory entries
>  - unpack-trees: rename unpack_nondirectories()
>  - unpack-trees: compare sparse directories correctly
>  - unpack-trees: preserve cache_bottom
>  - t1092: add tests for status/add and sparse files
>  - t1092: expand repository data shape
>  - t1092: replace incorrect 'echo' with 'cat'
>  - sparse-index: include EXTENDED flag when expanding
>  - sparse-index: skip indexes with unmerged entries
>  (this branch is used by ds/commit-and-checkout-with-sparse-index.)
> 
>  "git status" codepath learned to work with sparsely populated index
>  without hydrating it fully.
> 
>  Expecting a final reroll.
>  cf. <e7199fc6-bc7b-f556-c10c-12dee04af287@gmail.com>

Final re-roll inbound.

> * ds/gender-neutral-doc-guidelines (2021-06-16) 2 commits
>  - SQUASH??? replace neutering tips with that of Æver
>  - CodingGuidelines: recommend singular they
>  (this branch uses ds/gender-neutral-doc.)
> 
>  Attempt to give a guideline for gender neutral documentation.
> 
>  Comments?

I've said before and will repeat here that the draft in your
SQUASH??? commit looks like a good compromise to me. It can
replace the other commit in this branch.

Thanks,
-Stolee

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: What's cooking in git.git (Jul 2021, #03; Tue, 13)
  2021-07-14 13:11 ` Derrick Stolee
@ 2021-07-14 14:32   ` Ævar Arnfjörð Bjarmason
  2021-07-15 16:25     ` [PATCH] CodingGuidelines: recommend gender-neutral description Junio C Hamano
  0 siblings, 1 reply; 43+ messages in thread
From: Ævar Arnfjörð Bjarmason @ 2021-07-14 14:32 UTC (permalink / raw)
  To: Derrick Stolee; +Cc: Junio C Hamano, git


On Wed, Jul 14 2021, Derrick Stolee wrote:

> On 7/13/2021 9:07 PM, Junio C Hamano wrote:
> [...]
>> * ds/gender-neutral-doc-guidelines (2021-06-16) 2 commits
>>  - SQUASH??? replace neutering tips with that of Æver
>>  - CodingGuidelines: recommend singular they
>>  (this branch uses ds/gender-neutral-doc.)
>> 
>>  Attempt to give a guideline for gender neutral documentation.
>> 
>>  Comments?
>
> I've said before and will repeat here that the draft in your
> SQUASH??? commit looks like a good compromise to me. It can
> replace the other commit in this branch.

Just doing that would leave the commit message that says "change X",
when we're now changing X, Y and Z. I.e.  With the squash it changes
from narrowly focusing on the pronoun question into a start of a general
prose and style guide for our documentation.

Whatever anyone thinks about the proposed end-result I'd say that's a
bit too much work to dump in Junio's lap.

I also had a question for you here >2 weeks ago:
https://lore.kernel.org/git/87o8bog7li.fsf@evledraar.gmail.com/

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: What's cooking in git.git (Jul 2021, #03; Tue, 13)
  2021-07-14  2:16 ` Eric Sunshine
@ 2021-07-14 16:30   ` Junio C Hamano
  2021-07-14 22:39     ` Eric Sunshine
  0 siblings, 1 reply; 43+ messages in thread
From: Junio C Hamano @ 2021-07-14 16:30 UTC (permalink / raw)
  To: Eric Sunshine; +Cc: Git List, Stephen Manz

Eric Sunshine <sunshine@sunshineco.com> writes:

> On Tue, Jul 13, 2021 at 9:07 PM Junio C Hamano <gitster@pobox.com> wrote:
>> * sm/worktree-add-lock (2021-07-12) 3 commits
>>  - worktree: teach `add` to accept --reason <string> with --lock
>>  - worktree: mark lock strings with `_()` for translation
>>  - t2400: clean up '"add" worktree with lock' test
>>
>>  "git worktree add --lock" learned to record why the worktree is
>>  locked with a custom message.
>>
>>  Ready?
>
> I think this series is ready and gave my Reviewed-by: here[1]. One of
> the new tests contains an unnecessary but harmless `test -f`[2], but
> it's such a minor nit that I doubt it's worth demanding a re-roll.

I think having "test -f" is the right thing to do, so [2] is
probably OK as-is.  test_cmp may want to complain about a possible
bug in the test when given a missing file.  I do agree with you that
the unquoted "why not" is a bit problematic from the readability's
point of view but I agree it is not too huge a deal.

Let me "rebase -i"-in your Reviewed-by: before merging it down to
'next'.

Thanks.


> [1]: https://lore.kernel.org/git/CAPig+cSVsJ9AtAMqtRQpyuosCDCGi+mu2C1PJUK49WTb5KvcWQ@mail.gmail.com/
> [2]: https://lore.kernel.org/git/CAPig+cQVSUg1aqry_hMydJ=Uo=-VhOog6TUTpG=0on0LUcw8Dg@mail.gmail.com/

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: What's cooking in git.git (Jul 2021, #03; Tue, 13)
  2021-07-14  8:42 ` Han-Wen Nienhuys
  2021-07-14 11:53   ` Ævar Arnfjörð Bjarmason
  2021-07-14 11:54   ` Ævar Arnfjörð Bjarmason
@ 2021-07-14 17:28   ` Junio C Hamano
  2 siblings, 0 replies; 43+ messages in thread
From: Junio C Hamano @ 2021-07-14 17:28 UTC (permalink / raw)
  To: Han-Wen Nienhuys; +Cc: git

Han-Wen Nienhuys <hanwen@google.com> writes:

> AEvar posted the corrected patch as part of his follow-up series.
> (https://public-inbox.org/git/patch-04.17-270cda29c3a-20210711T162803Z-avarab@gmail.com/).
> Would that work for you?

In
<CAFQ2z_M7FzR6HEea2Xj-j=LiTsjQvpGJc+h+D+GgU=ZEkWm50A@mail.gmail.com>
you sounded that you are more-or-less OK with that version but with
some comments, so as long as you two can give a "final" version that
both clearly agree to, I'm OK.  It just is not clear if v7 is that
version to me (yet).

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: What's cooking in git.git (Jul 2021, #03; Tue, 13)
  2021-07-14  1:07 What's cooking in git.git (Jul 2021, #03; Tue, 13) Junio C Hamano
                   ` (2 preceding siblings ...)
  2021-07-14 13:11 ` Derrick Stolee
@ 2021-07-14 20:11 ` Taylor Blau
  2021-07-19  7:35 ` Patrick Steinhardt
  4 siblings, 0 replies; 43+ messages in thread
From: Taylor Blau @ 2021-07-14 20:11 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

On Tue, Jul 13, 2021 at 06:07:12PM -0700, Junio C Hamano wrote:
> * tb/midx-use-checksum (2021-06-28) 4 commits
>   (merged to 'next' on 2021-07-08 at bbaac9c721)
>  + midx: report checksum mismatches during 'verify'
>  + midx: don't reuse corrupt MIDXs when writing
>  + commit-graph: rewrite to use checksum_valid()
>  + csum-file: introduce checksum_valid()
>
>  When rebuilding the multi-pack index file reusing an existing one,
>  we used to blindly trust the existing file and ended up carrying
>  corrupted data into the updated file, which has been corrected.
>
>  Will merge to 'master'.

Thanks.

I had a moment of panic over my week off that the new code wasn't using
the right hash for non-SHA-1 repositories. But we check that the hash
version the file was written with matches 'the_hash_algo' at runtime,
and we use 'the_hash_algo->rawsz' to determine the end of the contents,
so we're all good here.


> * tb/multi-pack-bitmaps (2021-06-28) 24 commits
> [...]
>
>  The reachability bitmap file used to be generated only for a single
>  pack, but now we've learned to generate bitmaps for history that
>  span across multiple packfiles.
>
>  Comments?

I would definitely appreciate some more comments, but I have only
sporadically been keeping up-to-date with this series. Ævar sent some
suggestions which I've been replying to today as I catch back up, but
they appear mostly cosmetic (at least, the ones that I've read so far).

I think at this point I'd want a deep review from somebody familiar with
bitmaps before re-rolling. Peff and I have both looked over the series
exhaustively within GitHub, but the clean version submitted here should
definitely be checked before merging.

I'm not in a big hurry to merge this, but there are some other good
topics that are built on top (and it makes working on other bitmap
related things kind of a pain since there are two choices for what to
base it on).

Thanks,
Taylor

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: What's cooking in git.git (Jul 2021, #03; Tue, 13)
  2021-07-14 16:30   ` Junio C Hamano
@ 2021-07-14 22:39     ` Eric Sunshine
  2021-07-14 22:44       ` Junio C Hamano
  0 siblings, 1 reply; 43+ messages in thread
From: Eric Sunshine @ 2021-07-14 22:39 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Git List, Stephen Manz

On Wed, Jul 14, 2021 at 12:30 PM Junio C Hamano <gitster@pobox.com> wrote:
> Eric Sunshine <sunshine@sunshineco.com> writes:
> > I think this series is ready and gave my Reviewed-by: here[1]. One of
> > the new tests contains an unnecessary but harmless `test -f`[2], but
> > it's such a minor nit that I doubt it's worth demanding a re-roll.
>
> I think having "test -f" is the right thing to do, so [2] is
> probably OK as-is.  test_cmp may want to complain about a possible
> bug in the test when given a missing file.  [...]

We tried relatively recently to have test_cmp() complain about a
missing file[1], but both Ævar[2] and Peff[3] ran into problems in
which tests (presumably) legitimately called test_cmp() on missing
files, so the suggestion was made to revert the check[4], which is
indeed what happened[5].

[1]: https://lore.kernel.org/git/20200809174209.15466-1-sunshine@sunshineco.com/
[2]: https://lore.kernel.org/git/20200921104000.2304-15-avarab@gmail.com/
[3]: https://lore.kernel.org/git/20201016001704.GA2937048@coredump.intra.peff.net/
[4]: https://lore.kernel.org/git/CAPig+cSU=1GcQuqZab+0Vff_A-JmD59wEc3RMr3wDojpgRYUuw@mail.gmail.com/
[5]: https://lore.kernel.org/git/xmqqv9f9ao0v.fsf@gitster.c.googlers.com/

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: What's cooking in git.git (Jul 2021, #03; Tue, 13)
  2021-07-14 22:39     ` Eric Sunshine
@ 2021-07-14 22:44       ` Junio C Hamano
  0 siblings, 0 replies; 43+ messages in thread
From: Junio C Hamano @ 2021-07-14 22:44 UTC (permalink / raw)
  To: Eric Sunshine; +Cc: Git List, Stephen Manz

Eric Sunshine <sunshine@sunshineco.com> writes:

> On Wed, Jul 14, 2021 at 12:30 PM Junio C Hamano <gitster@pobox.com> wrote:
>> Eric Sunshine <sunshine@sunshineco.com> writes:
>> > I think this series is ready and gave my Reviewed-by: here[1]. One of
>> > the new tests contains an unnecessary but harmless `test -f`[2], but
>> > it's such a minor nit that I doubt it's worth demanding a re-roll.
>>
>> I think having "test -f" is the right thing to do, so [2] is
>> probably OK as-is.  test_cmp may want to complain about a possible
>> bug in the test when given a missing file.  [...]
>
> We tried relatively recently to have test_cmp() complain about a
> missing file[1], but both Ævar[2] and Peff[3] ran into problems in
> which tests (presumably) legitimately called test_cmp() on missing
> files, so the suggestion was made to revert the check[4], which is
> indeed what happened[5].

Yes, I know all that, and even with that, having "test -f" is the
right thing to do, so [2] is probably OK as-is.

> [1]: https://lore.kernel.org/git/20200809174209.15466-1-sunshine@sunshineco.com/
> [2]: https://lore.kernel.org/git/20200921104000.2304-15-avarab@gmail.com/
> [3]: https://lore.kernel.org/git/20201016001704.GA2937048@coredump.intra.peff.net/
> [4]: https://lore.kernel.org/git/CAPig+cSU=1GcQuqZab+0Vff_A-JmD59wEc3RMr3wDojpgRYUuw@mail.gmail.com/
> [5]: https://lore.kernel.org/git/xmqqv9f9ao0v.fsf@gitster.c.googlers.com/

^ permalink raw reply	[flat|nested] 43+ messages in thread

* [PATCH] CodingGuidelines: recommend gender-neutral description
  2021-07-14 14:32   ` Ævar Arnfjörð Bjarmason
@ 2021-07-15 16:25     ` Junio C Hamano
  2021-07-15 16:35       ` Eric Sunshine
                         ` (2 more replies)
  0 siblings, 3 replies; 43+ messages in thread
From: Junio C Hamano @ 2021-07-15 16:25 UTC (permalink / raw)
  To: Ævar Arnfjörð Bjarmason; +Cc: Derrick Stolee, git

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

>> I've said before and will repeat here that the draft in your
>> SQUASH??? commit looks like a good compromise to me. It can
>> replace the other commit in this branch.
>
> Just doing that would leave the commit message that says "change X",
> when we're now changing X, Y and Z. I.e.  With the squash it changes
> from narrowly focusing on the pronoun question into a start of a general
> prose and style guide for our documentation.

Yeah, that is a good point.  Perhaps like this?

-- >8 ---- >8 ---- >8 -- cut here -- >8 ---- >8 ---- >8 --

Technical writing seeks to convey information with minimal
friction. One way that a reader can experience friction is if they
encounter a description of "a user" that is later simplified using a
gendered pronoun. If the reader does not consider that pronoun to
apply to them, then they can experience cognitive dissonance that
removes focus from the information.

Give some basic tips to guide us avoid unnecessary of gendered
description.

Using a gendered pronoun is appropriate when referring to a specific
person.

There are acceptable existing uses of gendered pronouns within the
Git codebase, such as:

* References to real people (e.g. Linus Torvalds, "the Git maintainer").
  Do not misgender real people. If there is any doubt to the gender of a
  person, then avoid using pronouns.

* References to fictional people with clear genders (e.g. Alice and
  Bob).

* Sample text used in test cases (e.g t3702, t6432).

* The official text of the GPL license contains uses of "he or she",
  but using singular "they" (or modifying the text in some other
  way) is not within the scope of the Git project.

* Literal email messages in Documentation/howto/ should not be edited
  for grammatical concerns such as this, unless we update the entire
  document to fit the standard documentation format. If such an effort is
  taken on, then the authorship would change and no longer refer to the
  exact mail message.

* External projects consumed in contrib/ should not deviate solely for
  style reasons. Recommended edits should be contributed to those
  projects directly.

Other cases within the Git project were cleaned up by the previous
changes.

Co-authored-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 Documentation/CodingGuidelines | 43 ++++++++++++++++++++++++++++++++++
 1 file changed, 43 insertions(+)

diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines
index 45465bc0c9..476b840d30 100644
--- a/Documentation/CodingGuidelines
+++ b/Documentation/CodingGuidelines
@@ -541,6 +541,49 @@ Writing Documentation:
  documentation, please see the documentation-related advice in the
  Documentation/SubmittingPatches file).
 
+ In order to ensure the documentation is inclusive, avoid assuming
+ that an unspecified example person is male or female, and think
+ twice before using "he", "him", "she", or "her".  Here are some
+ tips to avoid use of gendered pronouns:
+
+  - Prefer succinctness and matter-of-factly describing functionality
+    in the abstract.  E.g.
+
+     --short:: Emit output in the short-format.
+
+    and avoid something like these overly verbose alternatives:
+
+     --short:: Use this to emit output in the short-format.
+     --short:: You can use this to get output in the short-format.
+     --short:: A user who prefers shorter output could....
+     --short:: Should a person and/or program want shorter output, he
+               she/they/it can...
+
+    This practice often eliminates the need to involve human actors in
+    your description, but it is a good practice regardless of the
+    avoidance of gendered pronouns.
+
+  - When it becomes awkward to stick to this style, prefer "you" when
+    addressing the the hypothetical user, and possibly "we" when
+    discussing how the program might react to the user.  E.g.
+
+      You can use this option instead of --xyz, but we might remove
+      support for it in future versions.
+
+    while keeping in mind that you can probably be less verbose, e.g.
+
+      Use this instead of --xyz. This option might be removed in future
+      versions.
+
+  - If you still need to refer to an example person that is
+    third-person singular, you may resort to "singular they" to avoid
+    "he/she/him/her", e.g.
+
+      A contributor asks their upstream to pull from them.
+
+    Note that this sounds ungrammatical and unnatural to those who
+    learned English as a second language in some parts of the world.
+
  Every user-visible change should be reflected in the documentation.
  The same general rule as for code applies -- imitate the existing
  conventions.
-- 
2.32.0-443-g7e6d7322bf


^ permalink raw reply related	[flat|nested] 43+ messages in thread

* Re: [PATCH] CodingGuidelines: recommend gender-neutral description
  2021-07-15 16:25     ` [PATCH] CodingGuidelines: recommend gender-neutral description Junio C Hamano
@ 2021-07-15 16:35       ` Eric Sunshine
  2021-07-15 16:47         ` Taylor Blau
  2021-07-15 17:27         ` Derrick Stolee
  2021-07-16 18:41       ` [PATCH v2] " Junio C Hamano
  2021-08-12  8:35       ` [PATCH] " Bagas Sanjaya
  2 siblings, 2 replies; 43+ messages in thread
From: Eric Sunshine @ 2021-07-15 16:35 UTC (permalink / raw)
  To: Junio C Hamano
  Cc: Ævar Arnfjörð Bjarmason, Derrick Stolee, Git List

On Thu, Jul 15, 2021 at 12:25 PM Junio C Hamano <gitster@pobox.com> wrote:
> Technical writing seeks to convey information with minimal
> friction. One way that a reader can experience friction is if they
> encounter a description of "a user" that is later simplified using a
> gendered pronoun. If the reader does not consider that pronoun to
> apply to them, then they can experience cognitive dissonance that
> removes focus from the information.
>
> Give some basic tips to guide us avoid unnecessary of gendered
> description.

Some words seem to be missing from this sentence.

> diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines
> @@ -541,6 +541,49 @@ Writing Documentation:
> +      A contributor asks their upstream to pull from them.
> +
> +    Note that this sounds ungrammatical and unnatural to those who
> +    learned English as a second language in some parts of the world.

It also sounds ungrammatical and unnatural to this native English speaker.

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: [PATCH] CodingGuidelines: recommend gender-neutral description
  2021-07-15 16:35       ` Eric Sunshine
@ 2021-07-15 16:47         ` Taylor Blau
  2021-07-15 18:02           ` Junio C Hamano
  2021-07-16 21:25           ` Felipe Contreras
  2021-07-15 17:27         ` Derrick Stolee
  1 sibling, 2 replies; 43+ messages in thread
From: Taylor Blau @ 2021-07-15 16:47 UTC (permalink / raw)
  To: Eric Sunshine
  Cc: Junio C Hamano, Ævar Arnfjörð Bjarmason,
	Derrick Stolee, Git List

On Thu, Jul 15, 2021 at 12:35:30PM -0400, Eric Sunshine wrote:
> On Thu, Jul 15, 2021 at 12:25 PM Junio C Hamano <gitster@pobox.com> wrote:
> > Technical writing seeks to convey information with minimal
> > friction. One way that a reader can experience friction is if they
> > encounter a description of "a user" that is later simplified using a
> > gendered pronoun. If the reader does not consider that pronoun to
> > apply to them, then they can experience cognitive dissonance that
> > removes focus from the information.
> >
> > Give some basic tips to guide us avoid unnecessary of gendered
> > description.
>
> Some words seem to be missing from this sentence.

I assume that it's supposed to read "guide us [to] avoid unnecessary
[uses] of gendered description".

>
> > diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines
> > @@ -541,6 +541,49 @@ Writing Documentation:
> > +      A contributor asks their upstream to pull from them.
> > +
> > +    Note that this sounds ungrammatical and unnatural to those who
> > +    learned English as a second language in some parts of the world.
>
> It also sounds ungrammatical and unnatural to this native English speaker.

Apologies if this suggestion has been made earlier in the thread, but
this article

    https://apastyle.apa.org/style-grammar-guidelines/grammar/singular-they

document from the APA's style guide helps convince me that this is
grammatical.

Thanks,
Taylor

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: [PATCH] CodingGuidelines: recommend gender-neutral description
  2021-07-15 16:35       ` Eric Sunshine
  2021-07-15 16:47         ` Taylor Blau
@ 2021-07-15 17:27         ` Derrick Stolee
  2021-07-16 15:11           ` Johannes Schindelin
  2021-07-16 21:22           ` Felipe Contreras
  1 sibling, 2 replies; 43+ messages in thread
From: Derrick Stolee @ 2021-07-15 17:27 UTC (permalink / raw)
  To: Eric Sunshine, Junio C Hamano
  Cc: Ævar Arnfjörð Bjarmason, Git List

On 7/15/2021 12:35 PM, Eric Sunshine wrote:
> On Thu, Jul 15, 2021 at 12:25 PM Junio C Hamano <gitster@pobox.com> wrote:
>> diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines
>> @@ -541,6 +541,49 @@ Writing Documentation:
>> +      A contributor asks their upstream to pull from them.
>> +
>> +    Note that this sounds ungrammatical and unnatural to those who
>> +    learned English as a second language in some parts of the world.
> 
> It also sounds ungrammatical and unnatural to this native English speaker.

A way to adapt this idea more generally would be to pull a phrase
from my commit message in v3:

  Note that this sounds ungrammatical and unnatural to readers
  who learned English in a way that dictated "they" as always plural.

Learning English as a second language is one example of how one could
find it ungrammatical. We could call it out explicitly:

  Note that this sounds ungrammatical and unnatural to readers
  who learned English in a way that dictated "they" as always plural,
  especially those who learned English as a second language.

Thanks,
-Stolee

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: [PATCH] CodingGuidelines: recommend gender-neutral description
  2021-07-15 16:47         ` Taylor Blau
@ 2021-07-15 18:02           ` Junio C Hamano
  2021-07-16 21:25           ` Felipe Contreras
  1 sibling, 0 replies; 43+ messages in thread
From: Junio C Hamano @ 2021-07-15 18:02 UTC (permalink / raw)
  To: Taylor Blau
  Cc: Eric Sunshine, Ævar Arnfjörð Bjarmason,
	Derrick Stolee, Git List

Taylor Blau <me@ttaylorr.com> writes:

> On Thu, Jul 15, 2021 at 12:35:30PM -0400, Eric Sunshine wrote:
>> On Thu, Jul 15, 2021 at 12:25 PM Junio C Hamano <gitster@pobox.com> wrote:
>> > Technical writing seeks to convey information with minimal
>> > friction. One way that a reader can experience friction is if they
>> > encounter a description of "a user" that is later simplified using a
>> > gendered pronoun. If the reader does not consider that pronoun to
>> > apply to them, then they can experience cognitive dissonance that
>> > removes focus from the information.
>> >
>> > Give some basic tips to guide us avoid unnecessary of gendered
>> > description.
>>
>> Some words seem to be missing from this sentence.
>
> I assume that it's supposed to read "guide us [to] avoid unnecessary
> [uses] of gendered description".

Thanks.  Last-minute edit always screwes me up.

>> > +    Note that this sounds ungrammatical and unnatural to those who
>> > +    learned English as a second language in some parts of the world.
>>
>> It also sounds ungrammatical and unnatural to this native English speaker.
>
> Apologies if this suggestion has been made earlier in the thread, but
> this article
>
>     https://apastyle.apa.org/style-grammar-guidelines/grammar/singular-they
>
> document from the APA's style guide helps convince me that this is
> grammatical.

Yes, the language is living and drifting---and that is why it
matters when and where you learned ;-)

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: [PATCH] CodingGuidelines: recommend gender-neutral description
  2021-07-15 17:27         ` Derrick Stolee
@ 2021-07-16 15:11           ` Johannes Schindelin
  2021-07-16 21:22           ` Felipe Contreras
  1 sibling, 0 replies; 43+ messages in thread
From: Johannes Schindelin @ 2021-07-16 15:11 UTC (permalink / raw)
  To: Derrick Stolee
  Cc: Eric Sunshine, Junio C Hamano,
	Ævar Arnfjörð Bjarmason, Git List

Hi,

On Thu, 15 Jul 2021, Derrick Stolee wrote:

> On 7/15/2021 12:35 PM, Eric Sunshine wrote:
> > On Thu, Jul 15, 2021 at 12:25 PM Junio C Hamano <gitster@pobox.com> wrote:
> >> diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines
> >> @@ -541,6 +541,49 @@ Writing Documentation:
> >> +      A contributor asks their upstream to pull from them.
> >> +
> >> +    Note that this sounds ungrammatical and unnatural to those who
> >> +    learned English as a second language in some parts of the world.
> >
> > It also sounds ungrammatical and unnatural to this native English speaker.
>
> A way to adapt this idea more generally would be to pull a phrase
> from my commit message in v3:
>
>   Note that this sounds ungrammatical and unnatural to readers
>   who learned English in a way that dictated "they" as always plural.
>
> Learning English as a second language is one example of how one could
> find it ungrammatical. We could call it out explicitly:
>
>   Note that this sounds ungrammatical and unnatural to readers
>   who learned English in a way that dictated "they" as always plural,
>   especially those who learned English as a second language.

I like the latter form.

Ciao,
Dscho "who will never stop learning English because learning never ends"

^ permalink raw reply	[flat|nested] 43+ messages in thread

* [PATCH v2] CodingGuidelines: recommend gender-neutral description
  2021-07-15 16:25     ` [PATCH] CodingGuidelines: recommend gender-neutral description Junio C Hamano
  2021-07-15 16:35       ` Eric Sunshine
@ 2021-07-16 18:41       ` Junio C Hamano
  2021-07-16 19:05         ` Derrick Stolee
  2021-07-16 19:11         ` Ævar Arnfjörð Bjarmason
  2021-08-12  8:35       ` [PATCH] " Bagas Sanjaya
  2 siblings, 2 replies; 43+ messages in thread
From: Junio C Hamano @ 2021-07-16 18:41 UTC (permalink / raw)
  To: git

Technical writing seeks to convey information with minimal
friction. One way that a reader can experience friction is if they
encounter a description of "a user" that is later simplified using a
gendered pronoun. If the reader does not consider that pronoun to
apply to them, then they can experience cognitive dissonance that
removes focus from the information.

Give some basic tips to guide us avoid unnecessary uses of gendered
description.

Using a gendered pronoun is appropriate when referring to a specific
person.

There are acceptable existing uses of gendered pronouns within the
Git codebase, such as:

* References to real people (e.g. Linus Torvalds, "the Git maintainer").
  Do not misgender real people. If there is any doubt to the gender of a
  person, then avoid using pronouns.

* References to fictional people with clear genders (e.g. Alice and
  Bob).

* Sample text used in test cases (e.g t3702, t6432).

* The official text of the GPL license contains uses of "he or she",
  but using singular "they" (or modifying the text in some other
  way) is not within the scope of the Git project.

* Literal email messages in Documentation/howto/ should not be edited
  for grammatical concerns such as this, unless we update the entire
  document to fit the standard documentation format. If such an effort is
  taken on, then the authorship would change and no longer refer to the
  exact mail message.

* External projects consumed in contrib/ should not deviate solely for
  style reasons. Recommended edits should be contributed to those
  projects directly.

Other cases within the Git project were cleaned up by the previous
changes.

Co-authored-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---

 The only change relative to the previous one is that this
 explicitly calls out that some are taught that 'they' is only used
 for third-person plural.  As we already say that some foreigners
 find it ungrammatical and unnatural to use 'they', I actually do
 not think it is necessary, but I'd prefer not to leave easy loose
 end hanging untied, so let's close this round and let others polish
 on top if they wanted to after the dust settls.

 Documentation/CodingGuidelines | 45 ++++++++++++++++++++++++++++++++++
 1 file changed, 45 insertions(+)

diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines
index 45465bc0c9..b1f199b1fe 100644
--- a/Documentation/CodingGuidelines
+++ b/Documentation/CodingGuidelines
@@ -541,6 +541,51 @@ Writing Documentation:
  documentation, please see the documentation-related advice in the
  Documentation/SubmittingPatches file).
 
+ In order to ensure the documentation is inclusive, avoid assuming
+ that an unspecified example person is male or female, and think
+ twice before using "he", "him", "she", or "her".  Here are some
+ tips to avoid use of gendered pronouns:
+
+  - Prefer succinctness and matter-of-factly describing functionality
+    in the abstract.  E.g.
+
+     --short:: Emit output in the short-format.
+
+    and avoid something like these overly verbose alternatives:
+
+     --short:: Use this to emit output in the short-format.
+     --short:: You can use this to get output in the short-format.
+     --short:: A user who prefers shorter output could....
+     --short:: Should a person and/or program want shorter output, he
+               she/they/it can...
+
+    This practice often eliminates the need to involve human actors in
+    your description, but it is a good practice regardless of the
+    avoidance of gendered pronouns.
+
+  - When it becomes awkward to stick to this style, prefer "you" when
+    addressing the the hypothetical user, and possibly "we" when
+    discussing how the program might react to the user.  E.g.
+
+      You can use this option instead of --xyz, but we might remove
+      support for it in future versions.
+
+    while keeping in mind that you can probably be less verbose, e.g.
+
+      Use this instead of --xyz. This option might be removed in future
+      versions.
+
+  - If you still need to refer to an example person that is
+    third-person singular, you may resort to "singular they" to avoid
+    "he/she/him/her", e.g.
+
+      A contributor asks their upstream to pull from them.
+
+    Note that this sounds ungrammatical and unnatural to those who
+    learned that "they" is only used for third-person plural, e.g.
+    those who learn English as a second language in some parts of the
+    world.
+
  Every user-visible change should be reflected in the documentation.
  The same general rule as for code applies -- imitate the existing
  conventions.
-- 
2.32.0-454-g0dabea483d


^ permalink raw reply related	[flat|nested] 43+ messages in thread

* Re: [PATCH v2] CodingGuidelines: recommend gender-neutral description
  2021-07-16 18:41       ` [PATCH v2] " Junio C Hamano
@ 2021-07-16 19:05         ` Derrick Stolee
  2021-07-16 19:11         ` Ævar Arnfjörð Bjarmason
  1 sibling, 0 replies; 43+ messages in thread
From: Derrick Stolee @ 2021-07-16 19:05 UTC (permalink / raw)
  To: Junio C Hamano, git

On 7/16/2021 2:41 PM, Junio C Hamano wrote:
>  The only change relative to the previous one is that this
>  explicitly calls out that some are taught that 'they' is only used
>  for third-person plural.  As we already say that some foreigners
>  find it ungrammatical and unnatural to use 'they', I actually do
>  not think it is necessary, but I'd prefer not to leave easy loose
>  end hanging untied, so let's close this round and let others polish
>  on top if they wanted to after the dust settls.
...
> +    Note that this sounds ungrammatical and unnatural to those who
> +    learned that "they" is only used for third-person plural, e.g.
> +    those who learn English as a second language in some parts of the
> +    world.

Perfect. Thank you.

-Stolee

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: [PATCH v2] CodingGuidelines: recommend gender-neutral description
  2021-07-16 18:41       ` [PATCH v2] " Junio C Hamano
  2021-07-16 19:05         ` Derrick Stolee
@ 2021-07-16 19:11         ` Ævar Arnfjörð Bjarmason
  2021-07-16 19:50           ` Junio C Hamano
  1 sibling, 1 reply; 43+ messages in thread
From: Ævar Arnfjörð Bjarmason @ 2021-07-16 19:11 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git


On Fri, Jul 16 2021, Junio C Hamano wrote:

> Technical writing seeks to convey information with minimal
> friction. One way that a reader can experience friction is if they
> encounter a description of "a user" that is later simplified using a
> gendered pronoun. If the reader does not consider that pronoun to
> apply to them, then they can experience cognitive dissonance that
> removes focus from the information.
>
> Give some basic tips to guide us avoid unnecessary uses of gendered
> description.
>
> Using a gendered pronoun is appropriate when referring to a specific
> person.
>
> There are acceptable existing uses of gendered pronouns within the
> Git codebase, such as:
>
> * References to real people (e.g. Linus Torvalds, "the Git maintainer").
>   Do not misgender real people. If there is any doubt to the gender of a
>   person, then avoid using pronouns.
>
> * References to fictional people with clear genders (e.g. Alice and
>   Bob).
>
> * Sample text used in test cases (e.g t3702, t6432).
>
> * The official text of the GPL license contains uses of "he or she",
>   but using singular "they" (or modifying the text in some other
>   way) is not within the scope of the Git project.
>
> * Literal email messages in Documentation/howto/ should not be edited
>   for grammatical concerns such as this, unless we update the entire
>   document to fit the standard documentation format. If such an effort is
>   taken on, then the authorship would change and no longer refer to the
>   exact mail message.
>
> * External projects consumed in contrib/ should not deviate solely for
>   style reasons. Recommended edits should be contributed to those
>   projects directly.
>
> Other cases within the Git project were cleaned up by the previous
> changes.
>
> Co-authored-by: Junio C Hamano <gitster@pobox.com>
> Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>

On the topic of co-authors & SOB this text does look quite familiar:
https://lore.kernel.org/git/87a6nz2fda.fsf@evledraar.gmail.com/ :)

>  The only change relative to the previous one is that this
>  explicitly calls out that some are taught that 'they' is only used
>  for third-person plural.  As we already say that some foreigners
>  find it ungrammatical and unnatural to use 'they', I actually do
>  not think it is necessary[...]

The proposed commit message...

> + In order to ensure the documentation is inclusive, avoid assuming
> + that an unspecified example person is male or female, and think
> + twice before using "he", "him", "she", or "her".  Here are some
> + tips to avoid use of gendered pronouns:

Applies to this:

> +  - Prefer succinctness and matter-of-factly describing functionality
> +    in the abstract.  E.g.
> +
> +     --short:: Emit output in the short-format.
> +
> +    and avoid something like these overly verbose alternatives:
> +
> +     --short:: Use this to emit output in the short-format.
> +     --short:: You can use this to get output in the short-format.
> +     --short:: A user who prefers shorter output could....
> +     --short:: Should a person and/or program want shorter output, he
> +               she/they/it can...

But this.

> +    This practice often eliminates the need to involve human actors in
> +    your description, but it is a good practice regardless of the
> +    avoidance of gendered pronouns.

Not this.

> +  - When it becomes awkward to stick to this style, prefer "you" when
> +    addressing the the hypothetical user, and possibly "we" when
> +    discussing how the program might react to the user.  E.g.
> +
> +      You can use this option instead of --xyz, but we might remove
> +      support for it in future versions.
> +
> +    while keeping in mind that you can probably be less verbose, e.g.
> +
> +      Use this instead of --xyz. This option might be removed in future
> +      versions.

But this.

> +  - If you still need to refer to an example person that is
> +    third-person singular, you may resort to "singular they" to avoid
> +    "he/she/him/her", e.g.
> +
> +      A contributor asks their upstream to pull from them.
> +
> +    Note that this sounds ungrammatical and unnatural to those who
> +    learned that "they" is only used for third-person plural, e.g.
> +    those who learn English as a second language in some parts of the
> +    world.
> +

And not this, have, respectively, nothing to do and mostly everything to
do with the commit message.

IOW I don't think we should conflate a section on general style in our
common patterns/issues in our docs and one that at the end state of this
series is discussing the already-rare-now-nonexistent pattern that the
proposed policy is trying to prevent ever making it in-tree again, or to
put the entirety of a general style guide under the equivalent of "how
to avoid gendered pronouns".

IOW to have this instead (this is mostly a mere moving of your proposed
version):

== BEGIN==

General style points for our documentation

 - Prefer succinctness and matter-of-factly describing functionality
   in the abstract.  E.g.

    --short:: Emit output in the short-format.

   and avoid something like these overly verbose alternatives:

    --short:: Use this to emit output in the short-format.
    --short:: You can use this to get output in the short-format.
    --short:: A user who prefers shorter output could....
    --short:: Should a person and/or program want shorter output, he
              she/they/it can...

 - When it becomes awkward to stick to this style, prefer "you" when
   addressing the the hypothetical user, and possibly "we" when
   discussing how the program might react to the user.  E.g.

     You can use this option instead of --xyz, but we might remove
     support for it in future versions.

   while keeping in mind that you can probably be less verbose, e.g.

     Use this instead of --xyz. This option might be removed in future
     versions.

Discussing beings in our documentation:

  In order to ensure the documentation is inclusive, avoid assuming
  that an unspecified example person is male or female, and think
  twice before using "he", "him", "she", or "her".  Here are some
  tips to avoid use of gendered pronouns:

  The practice of avoiding verbosity discussed above often eliminates
  the need to involve human actors in your description.

 - If you still need to refer to an example person that is
   third-person singular, you may resort to "singular they" to avoid
   "he/she/him/her", e.g.

   A contributor asks their upstream to pull from them.

   Note that this sounds ungrammatical and unnatural to those who
   learned that "they" is only used for third-person plural, e.g.
   those who learn English as a second language in some parts of the
   world.

== END == 

I'd be happy to re-arrange this, if I could only get the submitter of
the series to respond to my E-Mails...

Snipping around above:

> , but I'd prefer not to leave easy loose
>  end hanging untied, so let's close this round and let others polish
>  on top if they wanted to after the dust settls.

Sure, but as someone who'll probably want to patch the first part of
this at one point or another, it's going to be rather weird to cover
e.g. how we prefer to quote options or refer to things in
errors/warnings or whatever all under a section that says all of the
below is in the service of the avoidance of gender pronouns.

Whereas it's mostly the case that our docs are just following a style
established in common OS-level docs at a time when I daresay this topic
wasn't part of the zeitgeist.

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: [PATCH v2] CodingGuidelines: recommend gender-neutral description
  2021-07-16 19:11         ` Ævar Arnfjörð Bjarmason
@ 2021-07-16 19:50           ` Junio C Hamano
  2021-07-16 21:14             ` Felipe Contreras
  0 siblings, 1 reply; 43+ messages in thread
From: Junio C Hamano @ 2021-07-16 19:50 UTC (permalink / raw)
  To: Derrick Stolee; +Cc: git, Ævar Arnfjörð Bjarmason

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

> I'd be happy to re-arrange this, if I could only get the submitter of
> the series to respond to my E-Mails...

I'll do this only once to add missing but intended recipient to the
to: line; you are both adults, don't assume malice but instead good
intentions and talk to each other.

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: [PATCH v2] CodingGuidelines: recommend gender-neutral description
  2021-07-16 19:50           ` Junio C Hamano
@ 2021-07-16 21:14             ` Felipe Contreras
  0 siblings, 0 replies; 43+ messages in thread
From: Felipe Contreras @ 2021-07-16 21:14 UTC (permalink / raw)
  To: Junio C Hamano, Derrick Stolee
  Cc: git, Ævar Arnfjörð Bjarmason

Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
> 
> > I'd be happy to re-arrange this, if I could only get the submitter of
> > the series to respond to my E-Mails...
> 
> I'll do this only once to add missing but intended recipient to the
> to: line; you are both adults, don't assume malice but instead good
> intentions and talk to each other.

That's ironic, given that you don't talk to me, which is BTW against the
code of conduct:

 * Being respectful of differing opinions, viewpoints, and experiences

You clearly do not respect my differing opinions.

It's not about being adults, it's about being *tolerant* about other
people's opinions (I still insist "respect" is the wrong term).

Cheers.

-- 
Felipe Contreras

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: [PATCH] CodingGuidelines: recommend gender-neutral description
  2021-07-15 17:27         ` Derrick Stolee
  2021-07-16 15:11           ` Johannes Schindelin
@ 2021-07-16 21:22           ` Felipe Contreras
  1 sibling, 0 replies; 43+ messages in thread
From: Felipe Contreras @ 2021-07-16 21:22 UTC (permalink / raw)
  To: Derrick Stolee, Eric Sunshine, Junio C Hamano
  Cc: Ævar Arnfjörð Bjarmason, Git List

Derrick Stolee wrote:
> On 7/15/2021 12:35 PM, Eric Sunshine wrote:
> > On Thu, Jul 15, 2021 at 12:25 PM Junio C Hamano <gitster@pobox.com> wrote:
> >> diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines
> >> @@ -541,6 +541,49 @@ Writing Documentation:
> >> +      A contributor asks their upstream to pull from them.
> >> +
> >> +    Note that this sounds ungrammatical and unnatural to those who
> >> +    learned English as a second language in some parts of the world.
> > 
> > It also sounds ungrammatical and unnatural to this native English speaker.
> 
> A way to adapt this idea more generally would be to pull a phrase
> from my commit message in v3:
> 
>   Note that this sounds ungrammatical and unnatural to readers
>   who learned English in a way that dictated "they" as always plural.
> 
> Learning English as a second language is one example of how one could
> find it ungrammatical. We could call it out explicitly:
> 
>   Note that this sounds ungrammatical and unnatural to readers
>   who learned English in a way that dictated "they" as always plural,
>   especially those who learned English as a second language.

This is loaded language. You are inserting your opinion into the text.

Don't. The guidelines are not a place to win arguments.

  Note that this sounds ungrammatical and unnatural to some people.

And it sounds ungrammatical because it *is* ungramatical, not only to
native English speakers, but professional linguists.

-- 
Felipe Contreras

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: [PATCH] CodingGuidelines: recommend gender-neutral description
  2021-07-15 16:47         ` Taylor Blau
  2021-07-15 18:02           ` Junio C Hamano
@ 2021-07-16 21:25           ` Felipe Contreras
  1 sibling, 0 replies; 43+ messages in thread
From: Felipe Contreras @ 2021-07-16 21:25 UTC (permalink / raw)
  To: Taylor Blau, Eric Sunshine
  Cc: Junio C Hamano, Ævar Arnfjörð Bjarmason,
	Derrick Stolee, Git List

Taylor Blau wrote:
> On Thu, Jul 15, 2021 at 12:35:30PM -0400, Eric Sunshine wrote:
> > On Thu, Jul 15, 2021 at 12:25 PM Junio C Hamano <gitster@pobox.com> wrote:

> > > diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines
> > > @@ -541,6 +541,49 @@ Writing Documentation:
> > > +      A contributor asks their upstream to pull from them.
> > > +
> > > +    Note that this sounds ungrammatical and unnatural to those who
> > > +    learned English as a second language in some parts of the world.
> >
> > It also sounds ungrammatical and unnatural to this native English speaker.
> 
> Apologies if this suggestion has been made earlier in the thread, but
> this article
> 
>     https://apastyle.apa.org/style-grammar-guidelines/grammar/singular-they
> 
> document from the APA's style guide helps convince me that this is
> grammatical.

That's the opinion of one organization (biased in my opinion). Other
organizations disagree:

https://ahdictionary.tumblr.com/post/147597257733/updated-usage-note-they

-- 
Felipe Contreras

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: What's cooking in git.git (Jul 2021, #03; Tue, 13)
  2021-07-14  1:07 What's cooking in git.git (Jul 2021, #03; Tue, 13) Junio C Hamano
                   ` (3 preceding siblings ...)
  2021-07-14 20:11 ` What's cooking in git.git (Jul 2021, #03; Tue, 13) Taylor Blau
@ 2021-07-19  7:35 ` Patrick Steinhardt
  2021-07-19  7:53   ` Felipe Contreras
  2021-07-19  8:33   ` Jeff King
  4 siblings, 2 replies; 43+ messages in thread
From: Patrick Steinhardt @ 2021-07-19  7:35 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

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

On Tue, Jul 13, 2021 at 06:07:12PM -0700, Junio C Hamano wrote:
[snip]
> * ps/perf-with-separate-output-directory (2021-07-02) 1 commit
>  - perf: fix when running with TEST_OUTPUT_DIRECTORY
> 
>  Test update.
> 
>  What's the status of this one?

From my point of view this is ready, but it's still missing reviews so
far. The lack of interest seems to indicate that nobody has hit the
issue so far, and I wonder why that is. Am I the only one who sets
TEST_OUTPUT_DIRECTORY to a tmpfs directory in his config.mak to speed up
tests?

Patrick

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: What's cooking in git.git (Jul 2021, #03; Tue, 13)
  2021-07-19  7:35 ` Patrick Steinhardt
@ 2021-07-19  7:53   ` Felipe Contreras
  2021-07-19  8:35     ` Jeff King
  2021-07-19  8:33   ` Jeff King
  1 sibling, 1 reply; 43+ messages in thread
From: Felipe Contreras @ 2021-07-19  7:53 UTC (permalink / raw)
  To: Patrick Steinhardt, Junio C Hamano; +Cc: git

Patrick Steinhardt wrote:
> On Tue, Jul 13, 2021 at 06:07:12PM -0700, Junio C Hamano wrote:
> [snip]
> > * ps/perf-with-separate-output-directory (2021-07-02) 1 commit
> >  - perf: fix when running with TEST_OUTPUT_DIRECTORY
> > 
> >  Test update.
> > 
> >  What's the status of this one?
> 
> From my point of view this is ready, but it's still missing reviews so
> far. The lack of interest seems to indicate that nobody has hit the
> issue so far, and I wonder why that is. Am I the only one who sets
> TEST_OUTPUT_DIRECTORY to a tmpfs directory in his config.mak to speed up
> tests?

No, I do the same, and this other fix for TEST_OUTPUT_DIRECTORY is being
ignored even harder:

https://lore.kernel.org/git/20210707030709.3134859-1-felipe.contreras@gmail.com/

-- 
Felipe Contreras

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: What's cooking in git.git (Jul 2021, #03; Tue, 13)
  2021-07-19  7:35 ` Patrick Steinhardt
  2021-07-19  7:53   ` Felipe Contreras
@ 2021-07-19  8:33   ` Jeff King
  2021-07-19 10:41     ` Patrick Steinhardt
  1 sibling, 1 reply; 43+ messages in thread
From: Jeff King @ 2021-07-19  8:33 UTC (permalink / raw)
  To: Patrick Steinhardt; +Cc: Junio C Hamano, git

On Mon, Jul 19, 2021 at 09:35:36AM +0200, Patrick Steinhardt wrote:

> On Tue, Jul 13, 2021 at 06:07:12PM -0700, Junio C Hamano wrote:
> [snip]
> > * ps/perf-with-separate-output-directory (2021-07-02) 1 commit
> >  - perf: fix when running with TEST_OUTPUT_DIRECTORY
> > 
> >  Test update.
> > 
> >  What's the status of this one?
> 
> From my point of view this is ready, but it's still missing reviews so
> far. The lack of interest seems to indicate that nobody has hit the
> issue so far, and I wonder why that is. Am I the only one who sets
> TEST_OUTPUT_DIRECTORY to a tmpfs directory in his config.mak to speed up
> tests?

I had marked it to look at, but just hadn't gotten around to it. I just
gave it a review (but the upshot is that it looks fine to me).

I don't set TEST_OUTPUT_DIRECTORY myself; instead I do:

  GIT_TEST_OPTS = --root=/path/to/tmpfs

TBH, I had never really considered using TEST_OUTPUT_DIRECTORY for this
(--root predates it, and was written explicitly for the tmpfs case). But
I also think --root is more convenient:

  - "make test" will run in the tmpfs for speed, but "./t1234-foo.sh -i"
    will run locally, which makes it easy to "cd" in to inspect the
    result

  - likewise, I find accessing the results in t/test-results/*.out a
    little more convenient

But all of that is preference. I don't think you're wrong to use
TEST_OUTPUT_DIRECTORY this way, but the above points might be
interesting to you.

-Peff

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: What's cooking in git.git (Jul 2021, #03; Tue, 13)
  2021-07-19  7:53   ` Felipe Contreras
@ 2021-07-19  8:35     ` Jeff King
  2021-07-19 10:42       ` Felipe Contreras
  0 siblings, 1 reply; 43+ messages in thread
From: Jeff King @ 2021-07-19  8:35 UTC (permalink / raw)
  To: Felipe Contreras; +Cc: Patrick Steinhardt, Junio C Hamano, git

On Mon, Jul 19, 2021 at 02:53:30AM -0500, Felipe Contreras wrote:

> Patrick Steinhardt wrote:
> > On Tue, Jul 13, 2021 at 06:07:12PM -0700, Junio C Hamano wrote:
> > [snip]
> > > * ps/perf-with-separate-output-directory (2021-07-02) 1 commit
> > >  - perf: fix when running with TEST_OUTPUT_DIRECTORY
> > > 
> > >  Test update.
> > > 
> > >  What's the status of this one?
> > 
> > From my point of view this is ready, but it's still missing reviews so
> > far. The lack of interest seems to indicate that nobody has hit the
> > issue so far, and I wonder why that is. Am I the only one who sets
> > TEST_OUTPUT_DIRECTORY to a tmpfs directory in his config.mak to speed up
> > tests?
> 
> No, I do the same, and this other fix for TEST_OUTPUT_DIRECTORY is being
> ignored even harder:
> 
> https://lore.kernel.org/git/20210707030709.3134859-1-felipe.contreras@gmail.com/

Note that the linked patch will break Patrick's, because we would no
longer set TEST_OUTPUT_DIRECTORY in GIT-BUILD-OPTIONS.

-Peff

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: What's cooking in git.git (Jul 2021, #03; Tue, 13)
  2021-07-19  8:33   ` Jeff King
@ 2021-07-19 10:41     ` Patrick Steinhardt
  2021-07-19 10:52       ` Jeff King
  2021-07-19 18:40       ` Junio C Hamano
  0 siblings, 2 replies; 43+ messages in thread
From: Patrick Steinhardt @ 2021-07-19 10:41 UTC (permalink / raw)
  To: Jeff King; +Cc: Junio C Hamano, git

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

On Mon, Jul 19, 2021 at 04:33:54AM -0400, Jeff King wrote:
> On Mon, Jul 19, 2021 at 09:35:36AM +0200, Patrick Steinhardt wrote:
> 
> > On Tue, Jul 13, 2021 at 06:07:12PM -0700, Junio C Hamano wrote:
> > [snip]
> > > * ps/perf-with-separate-output-directory (2021-07-02) 1 commit
> > >  - perf: fix when running with TEST_OUTPUT_DIRECTORY
> > > 
> > >  Test update.
> > > 
> > >  What's the status of this one?
> > 
> > From my point of view this is ready, but it's still missing reviews so
> > far. The lack of interest seems to indicate that nobody has hit the
> > issue so far, and I wonder why that is. Am I the only one who sets
> > TEST_OUTPUT_DIRECTORY to a tmpfs directory in his config.mak to speed up
> > tests?
> 
> I had marked it to look at, but just hadn't gotten around to it. I just
> gave it a review (but the upshot is that it looks fine to me).
> 
> I don't set TEST_OUTPUT_DIRECTORY myself; instead I do:
> 
>   GIT_TEST_OPTS = --root=/path/to/tmpfs
> 
> TBH, I had never really considered using TEST_OUTPUT_DIRECTORY for this
> (--root predates it, and was written explicitly for the tmpfs case). But
> I also think --root is more convenient:
> 
>   - "make test" will run in the tmpfs for speed, but "./t1234-foo.sh -i"
>     will run locally, which makes it easy to "cd" in to inspect the
>     result
> 
>   - likewise, I find accessing the results in t/test-results/*.out a
>     little more convenient
> 
> But all of that is preference. I don't think you're wrong to use
> TEST_OUTPUT_DIRECTORY this way, but the above points might be
> interesting to you.

It is, thanks a lot for the hint. But given your first point about
direct execution, this in fact makes me want TEST_OUTPUT_DIRECTORY in
contrast to `--root=/path/to/tmpfs`: especially in the context of perf
tests, I never run all of them together given that it takes such a long
time. So I instead either run them directly or via the `./run` script,
and in both cases I definitely want to have them in tmpfs given that
there's a lot of disk churn if you're using biggish repos.

Patrick

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: What's cooking in git.git (Jul 2021, #03; Tue, 13)
  2021-07-19  8:35     ` Jeff King
@ 2021-07-19 10:42       ` Felipe Contreras
  2021-07-19 10:56         ` Patrick Steinhardt
  0 siblings, 1 reply; 43+ messages in thread
From: Felipe Contreras @ 2021-07-19 10:42 UTC (permalink / raw)
  To: Jeff King, Felipe Contreras; +Cc: Patrick Steinhardt, Junio C Hamano, git

Jeff King wrote:
> On Mon, Jul 19, 2021 at 02:53:30AM -0500, Felipe Contreras wrote:
> 
> > Patrick Steinhardt wrote:
> > > On Tue, Jul 13, 2021 at 06:07:12PM -0700, Junio C Hamano wrote:
> > > [snip]
> > > > * ps/perf-with-separate-output-directory (2021-07-02) 1 commit
> > > >  - perf: fix when running with TEST_OUTPUT_DIRECTORY
> > > > 
> > > >  Test update.
> > > > 
> > > >  What's the status of this one?
> > > 
> > > From my point of view this is ready, but it's still missing reviews so
> > > far. The lack of interest seems to indicate that nobody has hit the
> > > issue so far, and I wonder why that is. Am I the only one who sets
> > > TEST_OUTPUT_DIRECTORY to a tmpfs directory in his config.mak to speed up
> > > tests?
> > 
> > No, I do the same, and this other fix for TEST_OUTPUT_DIRECTORY is being
> > ignored even harder:
> > 
> > https://lore.kernel.org/git/20210707030709.3134859-1-felipe.contreras@gmail.com/
> 
> Note that the linked patch will break Patrick's, because we would no
> longer set TEST_OUTPUT_DIRECTORY in GIT-BUILD-OPTIONS.

Is Patrick's patch specific to GIT-BUILD-OPTIONS? Or can
TEST_OUTPUT_DIRECTORY be taken from the environment?

Either way I think the priority should be to make the standard tests
work with TEST_OUTPUT_DIRECTORY.

-- 
Felipe Contreras

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: What's cooking in git.git (Jul 2021, #03; Tue, 13)
  2021-07-19 10:41     ` Patrick Steinhardt
@ 2021-07-19 10:52       ` Jeff King
  2021-07-19 18:40       ` Junio C Hamano
  1 sibling, 0 replies; 43+ messages in thread
From: Jeff King @ 2021-07-19 10:52 UTC (permalink / raw)
  To: Patrick Steinhardt; +Cc: Junio C Hamano, git

On Mon, Jul 19, 2021 at 12:41:43PM +0200, Patrick Steinhardt wrote:

> > TBH, I had never really considered using TEST_OUTPUT_DIRECTORY for this
> > (--root predates it, and was written explicitly for the tmpfs case). But
> > I also think --root is more convenient:
> > 
> >   - "make test" will run in the tmpfs for speed, but "./t1234-foo.sh -i"
> >     will run locally, which makes it easy to "cd" in to inspect the
> >     result
> > 
> >   - likewise, I find accessing the results in t/test-results/*.out a
> >     little more convenient
> > 
> > But all of that is preference. I don't think you're wrong to use
> > TEST_OUTPUT_DIRECTORY this way, but the above points might be
> > interesting to you.
> 
> It is, thanks a lot for the hint. But given your first point about
> direct execution, this in fact makes me want TEST_OUTPUT_DIRECTORY in
> contrast to `--root=/path/to/tmpfs`: especially in the context of perf
> tests, I never run all of them together given that it takes such a long
> time. So I instead either run them directly or via the `./run` script,
> and in both cases I definitely want to have them in tmpfs given that
> there's a lot of disk churn if you're using biggish repos.

I generally use "./run", too. It will use GIT_TEST_OPTS under the hood
(which I actually find a little odd, just because it kicks in my usual
"-x --verbose-log", which I don't actually care about for the perf
tests).

You'd have to specify it manually for single-script runs, though. I
usually avoid single-script runs (and instead use "./run") because I try
to make sure each run is associated with a commit. Otherwise, it's easy
to confuse yourself about what the state of "this tree" was when it ran
(it does not even build fresh with GIT_PERF_MAKE_OPTS! So many times
I've accidentally tested a -O0 build from the current tree and wondered
why it was so slow).

-Peff

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: What's cooking in git.git (Jul 2021, #03; Tue, 13)
  2021-07-19 10:42       ` Felipe Contreras
@ 2021-07-19 10:56         ` Patrick Steinhardt
  2021-07-19 11:25           ` Felipe Contreras
  0 siblings, 1 reply; 43+ messages in thread
From: Patrick Steinhardt @ 2021-07-19 10:56 UTC (permalink / raw)
  To: Felipe Contreras; +Cc: Jeff King, Junio C Hamano, git

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

On Mon, Jul 19, 2021 at 05:42:59AM -0500, Felipe Contreras wrote:
> Jeff King wrote:
> > On Mon, Jul 19, 2021 at 02:53:30AM -0500, Felipe Contreras wrote:
> > 
> > > Patrick Steinhardt wrote:
> > > > On Tue, Jul 13, 2021 at 06:07:12PM -0700, Junio C Hamano wrote:
> > > > [snip]
> > > > > * ps/perf-with-separate-output-directory (2021-07-02) 1 commit
> > > > >  - perf: fix when running with TEST_OUTPUT_DIRECTORY
> > > > > 
> > > > >  Test update.
> > > > > 
> > > > >  What's the status of this one?
> > > > 
> > > > From my point of view this is ready, but it's still missing reviews so
> > > > far. The lack of interest seems to indicate that nobody has hit the
> > > > issue so far, and I wonder why that is. Am I the only one who sets
> > > > TEST_OUTPUT_DIRECTORY to a tmpfs directory in his config.mak to speed up
> > > > tests?
> > > 
> > > No, I do the same, and this other fix for TEST_OUTPUT_DIRECTORY is being
> > > ignored even harder:
> > > 
> > > https://lore.kernel.org/git/20210707030709.3134859-1-felipe.contreras@gmail.com/
> > 
> > Note that the linked patch will break Patrick's, because we would no
> > longer set TEST_OUTPUT_DIRECTORY in GIT-BUILD-OPTIONS.
> 
> Is Patrick's patch specific to GIT-BUILD-OPTIONS? Or can
> TEST_OUTPUT_DIRECTORY be taken from the environment?
> 
> Either way I think the priority should be to make the standard tests
> work with TEST_OUTPUT_DIRECTORY.

Right now, TEST_OUTPUT_DIRECTORY as defined in config.mak will be
written into GIT-BUILD-OPTIONS, which then gets sourced by test-lib.sh
automatically. So even if you execute tests directly and not via the
Makefile, it'll still pick up the correct output directory you've
specified in your config.mak. It would likely be possible to take it
from the environment, but that makes the calling interface much more
fragile given that you'll have to remember to always set the envvar.

Patrick

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: What's cooking in git.git (Jul 2021, #03; Tue, 13)
  2021-07-19 10:56         ` Patrick Steinhardt
@ 2021-07-19 11:25           ` Felipe Contreras
  0 siblings, 0 replies; 43+ messages in thread
From: Felipe Contreras @ 2021-07-19 11:25 UTC (permalink / raw)
  To: Patrick Steinhardt, Felipe Contreras; +Cc: Jeff King, Junio C Hamano, git

Patrick Steinhardt wrote:
> On Mon, Jul 19, 2021 at 05:42:59AM -0500, Felipe Contreras wrote:
> > Jeff King wrote:
> > > On Mon, Jul 19, 2021 at 02:53:30AM -0500, Felipe Contreras wrote:
> > > 
> > > > Patrick Steinhardt wrote:
> > > > > On Tue, Jul 13, 2021 at 06:07:12PM -0700, Junio C Hamano wrote:
> > > > > [snip]
> > > > > > * ps/perf-with-separate-output-directory (2021-07-02) 1 commit
> > > > > >  - perf: fix when running with TEST_OUTPUT_DIRECTORY
> > > > > > 
> > > > > >  Test update.
> > > > > > 
> > > > > >  What's the status of this one?
> > > > > 
> > > > > From my point of view this is ready, but it's still missing reviews so
> > > > > far. The lack of interest seems to indicate that nobody has hit the
> > > > > issue so far, and I wonder why that is. Am I the only one who sets
> > > > > TEST_OUTPUT_DIRECTORY to a tmpfs directory in his config.mak to speed up
> > > > > tests?
> > > > 
> > > > No, I do the same, and this other fix for TEST_OUTPUT_DIRECTORY is being
> > > > ignored even harder:
> > > > 
> > > > https://lore.kernel.org/git/20210707030709.3134859-1-felipe.contreras@gmail.com/
> > > 
> > > Note that the linked patch will break Patrick's, because we would no
> > > longer set TEST_OUTPUT_DIRECTORY in GIT-BUILD-OPTIONS.
> > 
> > Is Patrick's patch specific to GIT-BUILD-OPTIONS? Or can
> > TEST_OUTPUT_DIRECTORY be taken from the environment?
> > 
> > Either way I think the priority should be to make the standard tests
> > work with TEST_OUTPUT_DIRECTORY.
> 
> Right now, TEST_OUTPUT_DIRECTORY as defined in config.mak will be
> written into GIT-BUILD-OPTIONS, which then gets sourced by test-lib.sh
> automatically. So even if you execute tests directly and not via the
> Makefile, it'll still pick up the correct output directory you've
> specified in your config.mak.

Yeah, I know, but right now if you do that t0000-basic.sh fails because
_run_sub_test_lib_test_common sets TEST_OUTPUT_DIRECTORY on the
environment, and that gets overriden when GIT-BUILD-OPTIONS is sourced.

> It would likely be possible to take it from the environment, but that
> makes the calling interface much more fragile given that you'll have
> to remember to always set the envvar.

Indeed, unless you set that in your ~/.profile, as I did.

-- 
Felipe Contreras

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: What's cooking in git.git (Jul 2021, #03; Tue, 13)
  2021-07-19 10:41     ` Patrick Steinhardt
  2021-07-19 10:52       ` Jeff King
@ 2021-07-19 18:40       ` Junio C Hamano
  2021-07-19 19:57         ` Felipe Contreras
  1 sibling, 1 reply; 43+ messages in thread
From: Junio C Hamano @ 2021-07-19 18:40 UTC (permalink / raw)
  To: Patrick Steinhardt; +Cc: Jeff King, git

Patrick Steinhardt <ps@pks.im> writes:

> On Mon, Jul 19, 2021 at 04:33:54AM -0400, Jeff King wrote:
>> On Mon, Jul 19, 2021 at 09:35:36AM +0200, Patrick Steinhardt wrote:
>> 
>> > On Tue, Jul 13, 2021 at 06:07:12PM -0700, Junio C Hamano wrote:
>> > [snip]
>> > > * ps/perf-with-separate-output-directory (2021-07-02) 1 commit
>> > >  - perf: fix when running with TEST_OUTPUT_DIRECTORY
>> > > 
>> > >  Test update.
>> > > 
>> > >  What's the status of this one?
>> > 
>> > From my point of view this is ready, but it's still missing reviews so
>> > far. The lack of interest seems to indicate that nobody has hit the
>> > issue so far, and I wonder why that is. Am I the only one who sets
>> > TEST_OUTPUT_DIRECTORY to a tmpfs directory in his config.mak to speed up
>> > tests?
>> 
>> I had marked it to look at, but just hadn't gotten around to it. I just
>> gave it a review (but the upshot is that it looks fine to me).
>> 
>> I don't set TEST_OUTPUT_DIRECTORY myself; instead I do:
>> 
>>   GIT_TEST_OPTS = --root=/path/to/tmpfs
>> 
>> TBH, I had never really considered using TEST_OUTPUT_DIRECTORY for this
>> (--root predates it, and was written explicitly for the tmpfs case). But
>> I also think --root is more convenient:
>> 
>>   - "make test" will run in the tmpfs for speed, but "./t1234-foo.sh -i"
>>     will run locally, which makes it easy to "cd" in to inspect the
>>     result
>> 
>>   - likewise, I find accessing the results in t/test-results/*.out a
>>     little more convenient
>> 
>> But all of that is preference. I don't think you're wrong to use
>> TEST_OUTPUT_DIRECTORY this way, but the above points might be
>> interesting to you.
>
> It is, thanks a lot for the hint. But given your first point about
> direct execution, this in fact makes me want TEST_OUTPUT_DIRECTORY in
> contrast to `--root=/path/to/tmpfs`: especially in the context of perf
> tests, I never run all of them together given that it takes such a long
> time. So I instead either run them directly or via the `./run` script,
> and in both cases I definitely want to have them in tmpfs given that
> there's a lot of disk churn if you're using biggish repos.
>
> Patrick

Thanks, all.  Let me mark the patch for 'next'.


^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: What's cooking in git.git (Jul 2021, #03; Tue, 13)
  2021-07-19 18:40       ` Junio C Hamano
@ 2021-07-19 19:57         ` Felipe Contreras
  2021-07-20  6:31           ` Patrick Steinhardt
  2021-07-20  6:32           ` [PATCH] t0000: fix test if run with TEST_OUTPUT_DIRECTORY Patrick Steinhardt
  0 siblings, 2 replies; 43+ messages in thread
From: Felipe Contreras @ 2021-07-19 19:57 UTC (permalink / raw)
  To: Junio C Hamano, Patrick Steinhardt; +Cc: Jeff King, git

Junio C Hamano wrote:
> Patrick Steinhardt <ps@pks.im> writes:
> 
> > On Mon, Jul 19, 2021 at 04:33:54AM -0400, Jeff King wrote:
> >> On Mon, Jul 19, 2021 at 09:35:36AM +0200, Patrick Steinhardt wrote:
> >> 
> >> > On Tue, Jul 13, 2021 at 06:07:12PM -0700, Junio C Hamano wrote:
> >> > [snip]
> >> > > * ps/perf-with-separate-output-directory (2021-07-02) 1 commit
> >> > >  - perf: fix when running with TEST_OUTPUT_DIRECTORY
> >> > > 
> >> > >  Test update.
> >> > > 
> >> > >  What's the status of this one?
> >> > 
> >> > From my point of view this is ready, but it's still missing reviews so
> >> > far. The lack of interest seems to indicate that nobody has hit the
> >> > issue so far, and I wonder why that is. Am I the only one who sets
> >> > TEST_OUTPUT_DIRECTORY to a tmpfs directory in his config.mak to speed up
> >> > tests?
> >> 
> >> I had marked it to look at, but just hadn't gotten around to it. I just
> >> gave it a review (but the upshot is that it looks fine to me).
> >> 
> >> I don't set TEST_OUTPUT_DIRECTORY myself; instead I do:
> >> 
> >>   GIT_TEST_OPTS = --root=/path/to/tmpfs
> >> 
> >> TBH, I had never really considered using TEST_OUTPUT_DIRECTORY for this
> >> (--root predates it, and was written explicitly for the tmpfs case). But
> >> I also think --root is more convenient:
> >> 
> >>   - "make test" will run in the tmpfs for speed, but "./t1234-foo.sh -i"
> >>     will run locally, which makes it easy to "cd" in to inspect the
> >>     result
> >> 
> >>   - likewise, I find accessing the results in t/test-results/*.out a
> >>     little more convenient
> >> 
> >> But all of that is preference. I don't think you're wrong to use
> >> TEST_OUTPUT_DIRECTORY this way, but the above points might be
> >> interesting to you.
> >
> > It is, thanks a lot for the hint. But given your first point about
> > direct execution, this in fact makes me want TEST_OUTPUT_DIRECTORY in
> > contrast to `--root=/path/to/tmpfs`: especially in the context of perf
> > tests, I never run all of them together given that it takes such a long
> > time. So I instead either run them directly or via the `./run` script,
> > and in both cases I definitely want to have them in tmpfs given that
> > there's a lot of disk churn if you're using biggish repos.
> >
> > Patrick
> 
> Thanks, all.  Let me mark the patch for 'next'.

OK, if you don't care that TEST_OUTPUT_DIRECTORY is broken, so be it.

-- 
Felipe Contreras

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: What's cooking in git.git (Jul 2021, #03; Tue, 13)
  2021-07-19 19:57         ` Felipe Contreras
@ 2021-07-20  6:31           ` Patrick Steinhardt
  2021-07-20  7:21             ` Felipe Contreras
  2021-07-20  6:32           ` [PATCH] t0000: fix test if run with TEST_OUTPUT_DIRECTORY Patrick Steinhardt
  1 sibling, 1 reply; 43+ messages in thread
From: Patrick Steinhardt @ 2021-07-20  6:31 UTC (permalink / raw)
  To: Felipe Contreras; +Cc: Junio C Hamano, Jeff King, git

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

On Mon, Jul 19, 2021 at 02:57:23PM -0500, Felipe Contreras wrote:
> Junio C Hamano wrote:
> > Patrick Steinhardt <ps@pks.im> writes:
> > 
> > > On Mon, Jul 19, 2021 at 04:33:54AM -0400, Jeff King wrote:
> > >> On Mon, Jul 19, 2021 at 09:35:36AM +0200, Patrick Steinhardt wrote:
> > >> 
> > >> > On Tue, Jul 13, 2021 at 06:07:12PM -0700, Junio C Hamano wrote:
> > >> > [snip]
> > >> > > * ps/perf-with-separate-output-directory (2021-07-02) 1 commit
> > >> > >  - perf: fix when running with TEST_OUTPUT_DIRECTORY
> > >> > > 
> > >> > >  Test update.
> > >> > > 
> > >> > >  What's the status of this one?
> > >> > 
> > >> > From my point of view this is ready, but it's still missing reviews so
> > >> > far. The lack of interest seems to indicate that nobody has hit the
> > >> > issue so far, and I wonder why that is. Am I the only one who sets
> > >> > TEST_OUTPUT_DIRECTORY to a tmpfs directory in his config.mak to speed up
> > >> > tests?
> > >> 
> > >> I had marked it to look at, but just hadn't gotten around to it. I just
> > >> gave it a review (but the upshot is that it looks fine to me).
> > >> 
> > >> I don't set TEST_OUTPUT_DIRECTORY myself; instead I do:
> > >> 
> > >>   GIT_TEST_OPTS = --root=/path/to/tmpfs
> > >> 
> > >> TBH, I had never really considered using TEST_OUTPUT_DIRECTORY for this
> > >> (--root predates it, and was written explicitly for the tmpfs case). But
> > >> I also think --root is more convenient:
> > >> 
> > >>   - "make test" will run in the tmpfs for speed, but "./t1234-foo.sh -i"
> > >>     will run locally, which makes it easy to "cd" in to inspect the
> > >>     result
> > >> 
> > >>   - likewise, I find accessing the results in t/test-results/*.out a
> > >>     little more convenient
> > >> 
> > >> But all of that is preference. I don't think you're wrong to use
> > >> TEST_OUTPUT_DIRECTORY this way, but the above points might be
> > >> interesting to you.
> > >
> > > It is, thanks a lot for the hint. But given your first point about
> > > direct execution, this in fact makes me want TEST_OUTPUT_DIRECTORY in
> > > contrast to `--root=/path/to/tmpfs`: especially in the context of perf
> > > tests, I never run all of them together given that it takes such a long
> > > time. So I instead either run them directly or via the `./run` script,
> > > and in both cases I definitely want to have them in tmpfs given that
> > > there's a lot of disk churn if you're using biggish repos.
> > >
> > > Patrick
> > 
> > Thanks, all.  Let me mark the patch for 'next'.
> 
> OK, if you don't care that TEST_OUTPUT_DIRECTORY is broken, so be it.

I just think we shouldn't strip away features if we should instead look
at why the testcase is broken and how to fix the root cause. I'll send a
patch in a minute which fixes the testcase without dropping support for
TEST_OUTPUT_DIRECTORY.

Patrick

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 43+ messages in thread

* [PATCH] t0000: fix test if run with TEST_OUTPUT_DIRECTORY
  2021-07-19 19:57         ` Felipe Contreras
  2021-07-20  6:31           ` Patrick Steinhardt
@ 2021-07-20  6:32           ` Patrick Steinhardt
  2021-07-20  7:11             ` Jeff King
  2021-07-20  7:24             ` Felipe Contreras
  1 sibling, 2 replies; 43+ messages in thread
From: Patrick Steinhardt @ 2021-07-20  6:32 UTC (permalink / raw)
  To: git; +Cc: Jeff King, Junio C Hamano, Felipe Contreras

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

Testcases in t0000 are quite special given that they many of them run
nested testcases to verify that testing functionality itself works as
expected. These nested testcases are realized by writing a new ad-hoc
test script which again sources test-lib.sh, where the new script is
created in a nested subdirectory located beneath the current trash
directory. We then execute the new test script with the nested
subdirectory as current working directory and explicitly re-export
TEST_OUTPUT_DIRECTORY to point to that directory.

While this works as expected in the general case, it falls apart when
the developer has TEST_OUTPUT_DIRECTORY explicitly defined either via
the environment or via config.mak. In that case, test-lib.sh will
clobber the value that we've just carefully set up to instead contain
what the developer has defined. As a result, the TEST_OUTPUT_DIRECTORY
continues to point at the root output directory, not at the nested one.

This issue causes breakage in the 'test_atexit is run' test case: the
nested test case writes files into "../../", which is assumed to be the
parent's trash directory. But because TEST_OUTPUT_DIRECTORY already
points to to the root output directory, we instead end up writing those
files outside of the output directory. The parent test case will then
try to check whether those files still exist in its own trash directory,
which thus must fail now.

Fix the issue by adding a new TEST_OUTPUT_DIRECTORY_OVERRIDE variable.
If set, then we'll always override the TEST_OUTPUT_DIRECTORY with its
value after sourcing GIT-BUILD-OPTIONS.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 t/t0000-basic.sh | 7 +++++--
 t/test-lib.sh    | 9 +++++++++
 2 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/t/t0000-basic.sh b/t/t0000-basic.sh
index 2c6e34b947..09d2202748 100755
--- a/t/t0000-basic.sh
+++ b/t/t0000-basic.sh
@@ -89,8 +89,11 @@ _run_sub_test_lib_test_common () {
 		EOF
 		cat >>"$name.sh" &&
 		export TEST_DIRECTORY &&
-		TEST_OUTPUT_DIRECTORY=$(pwd) &&
-		export TEST_OUTPUT_DIRECTORY &&
+		# The child test re-sources GIT-BUILD-OPTIONS and may thus
+		# override the test output directory. We thus pass it as an
+		# explicit override to the child.
+		TEST_OUTPUT_DIRECTORY_OVERRIDE=$(pwd) &&
+		export TEST_OUTPUT_DIRECTORY_OVERRIDE &&
 		sane_unset GIT_TEST_FAIL_PREREQS &&
 		if test -z "$neg"
 		then
diff --git a/t/test-lib.sh b/t/test-lib.sh
index 9e26860544..da13190970 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -57,6 +57,15 @@ fi
 . "$GIT_BUILD_DIR"/GIT-BUILD-OPTIONS
 export PERL_PATH SHELL_PATH
 
+# In t0000, we need to override test directories of nested testcases. In case
+# the developer has TEST_OUTPUT_DIRECTORY part of his build options, then we'd
+# reset this value to instead contain what the developer has specified. We thus
+# have this knob to allow overriding the directory.
+if test -n "${TEST_OUTPUT_DIRECTORY_OVERRIDE}"
+then
+	TEST_OUTPUT_DIRECTORY="${TEST_OUTPUT_DIRECTORY_OVERRIDE}"
+fi
+
 # Disallow the use of abbreviated options in the test suite by default
 if test -z "${GIT_TEST_DISALLOW_ABBREVIATED_OPTIONS}"
 then
-- 
2.32.0


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply related	[flat|nested] 43+ messages in thread

* Re: [PATCH] t0000: fix test if run with TEST_OUTPUT_DIRECTORY
  2021-07-20  6:32           ` [PATCH] t0000: fix test if run with TEST_OUTPUT_DIRECTORY Patrick Steinhardt
@ 2021-07-20  7:11             ` Jeff King
  2021-07-20 16:21               ` Junio C Hamano
  2021-07-20  7:24             ` Felipe Contreras
  1 sibling, 1 reply; 43+ messages in thread
From: Jeff King @ 2021-07-20  7:11 UTC (permalink / raw)
  To: Patrick Steinhardt; +Cc: git, Junio C Hamano, Felipe Contreras

On Tue, Jul 20, 2021 at 08:32:26AM +0200, Patrick Steinhardt wrote:

> Fix the issue by adding a new TEST_OUTPUT_DIRECTORY_OVERRIDE variable.
> If set, then we'll always override the TEST_OUTPUT_DIRECTORY with its
> value after sourcing GIT-BUILD-OPTIONS.

Thanks, I like this approach much better than removing
TEST_OUTPUT_DIRECTORY entirely (and I confirmed that it fixes the
problem).

I do wish we had a more generic way of overriding stuff in
GIT-BUILD-OPTIONS, rather than introducing manual _OVERRIDE variables
for each. But there's not an easy solution here (see the earlier thread
for some discussion), so this seems like a good immediate step to take.

One small note on the commit message:

> While this works as expected in the general case, it falls apart when
> the developer has TEST_OUTPUT_DIRECTORY explicitly defined either via
> the environment or via config.mak.

The mention of the environment confused me for a moment, since:

  TEST_OUTPUT_DIRECTORY=/tmp/foo ./t0000-basic.sh

is already OK. But you probably meant that:

  TEST_OUTPUT_DIRECTORY=/tmp/foo make test

would fail, since "make" would pick up the variable and then write it
into GIT-BUILD-OPTIONS (just as it would if you put it in config.mak, or
on the command-line of make).

I don't think it's sufficiently confusing to rewrite the commit message,
but just something I noted while reading it.

> --- a/t/test-lib.sh
> +++ b/t/test-lib.sh
> @@ -57,6 +57,15 @@ fi
>  . "$GIT_BUILD_DIR"/GIT-BUILD-OPTIONS
>  export PERL_PATH SHELL_PATH
>  
> +# In t0000, we need to override test directories of nested testcases. In case
> +# the developer has TEST_OUTPUT_DIRECTORY part of his build options, then we'd
> +# reset this value to instead contain what the developer has specified. We thus
> +# have this knob to allow overriding the directory.
> +if test -n "${TEST_OUTPUT_DIRECTORY_OVERRIDE}"
> +then
> +	TEST_OUTPUT_DIRECTORY="${TEST_OUTPUT_DIRECTORY_OVERRIDE}"
> +fi

Thanks for this comment. Hopefully that will make it clear to anybody
that the override mechanism is not meant for general use by developers.

-Peff

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: What's cooking in git.git (Jul 2021, #03; Tue, 13)
  2021-07-20  6:31           ` Patrick Steinhardt
@ 2021-07-20  7:21             ` Felipe Contreras
  0 siblings, 0 replies; 43+ messages in thread
From: Felipe Contreras @ 2021-07-20  7:21 UTC (permalink / raw)
  To: Patrick Steinhardt, Felipe Contreras; +Cc: Junio C Hamano, Jeff King, git

Patrick Steinhardt wrote:
> On Mon, Jul 19, 2021 at 02:57:23PM -0500, Felipe Contreras wrote:
> > Junio C Hamano wrote:
> > > Patrick Steinhardt <ps@pks.im> writes:
> > > 
> > > > On Mon, Jul 19, 2021 at 04:33:54AM -0400, Jeff King wrote:
> > > >> On Mon, Jul 19, 2021 at 09:35:36AM +0200, Patrick Steinhardt wrote:
> > > >> 
> > > >> > On Tue, Jul 13, 2021 at 06:07:12PM -0700, Junio C Hamano wrote:
> > > >> > [snip]
> > > >> > > * ps/perf-with-separate-output-directory (2021-07-02) 1 commit
> > > >> > >  - perf: fix when running with TEST_OUTPUT_DIRECTORY
> > > >> > > 
> > > >> > >  Test update.
> > > >> > > 
> > > >> > >  What's the status of this one?
> > > >> > 
> > > >> > From my point of view this is ready, but it's still missing reviews so
> > > >> > far. The lack of interest seems to indicate that nobody has hit the
> > > >> > issue so far, and I wonder why that is. Am I the only one who sets
> > > >> > TEST_OUTPUT_DIRECTORY to a tmpfs directory in his config.mak to speed up
> > > >> > tests?
> > > >> 
> > > >> I had marked it to look at, but just hadn't gotten around to it. I just
> > > >> gave it a review (but the upshot is that it looks fine to me).
> > > >> 
> > > >> I don't set TEST_OUTPUT_DIRECTORY myself; instead I do:
> > > >> 
> > > >>   GIT_TEST_OPTS = --root=/path/to/tmpfs
> > > >> 
> > > >> TBH, I had never really considered using TEST_OUTPUT_DIRECTORY for this
> > > >> (--root predates it, and was written explicitly for the tmpfs case). But
> > > >> I also think --root is more convenient:
> > > >> 
> > > >>   - "make test" will run in the tmpfs for speed, but "./t1234-foo.sh -i"
> > > >>     will run locally, which makes it easy to "cd" in to inspect the
> > > >>     result
> > > >> 
> > > >>   - likewise, I find accessing the results in t/test-results/*.out a
> > > >>     little more convenient
> > > >> 
> > > >> But all of that is preference. I don't think you're wrong to use
> > > >> TEST_OUTPUT_DIRECTORY this way, but the above points might be
> > > >> interesting to you.
> > > >
> > > > It is, thanks a lot for the hint. But given your first point about
> > > > direct execution, this in fact makes me want TEST_OUTPUT_DIRECTORY in
> > > > contrast to `--root=/path/to/tmpfs`: especially in the context of perf
> > > > tests, I never run all of them together given that it takes such a long
> > > > time. So I instead either run them directly or via the `./run` script,
> > > > and in both cases I definitely want to have them in tmpfs given that
> > > > there's a lot of disk churn if you're using biggish repos.
> > > >
> > > > Patrick
> > > 
> > > Thanks, all.  Let me mark the patch for 'next'.
> > 
> > OK, if you don't care that TEST_OUTPUT_DIRECTORY is broken, so be it.
> 
> I just think we shouldn't strip away features if we should instead look
> at why the testcase is broken and how to fix the root cause.

I mean, we didn't really strip away any features, you just happened to add
one feature at the same time the fix was proposed.

> I'll send a patch in a minute which fixes the testcase without
> dropping support for TEST_OUTPUT_DIRECTORY.

OK. You mean without breaking functonality that is flying.

-- 
Felipe Contreras

^ permalink raw reply	[flat|nested] 43+ messages in thread

* RE: [PATCH] t0000: fix test if run with TEST_OUTPUT_DIRECTORY
  2021-07-20  6:32           ` [PATCH] t0000: fix test if run with TEST_OUTPUT_DIRECTORY Patrick Steinhardt
  2021-07-20  7:11             ` Jeff King
@ 2021-07-20  7:24             ` Felipe Contreras
  1 sibling, 0 replies; 43+ messages in thread
From: Felipe Contreras @ 2021-07-20  7:24 UTC (permalink / raw)
  To: Patrick Steinhardt, git; +Cc: Jeff King, Junio C Hamano, Felipe Contreras

Patrick Steinhardt wrote:
> Testcases in t0000 are quite special given that they many of them run
> nested testcases to verify that testing functionality itself works as
> expected. These nested testcases are realized by writing a new ad-hoc
> test script which again sources test-lib.sh, where the new script is
> created in a nested subdirectory located beneath the current trash
> directory. We then execute the new test script with the nested
> subdirectory as current working directory and explicitly re-export
> TEST_OUTPUT_DIRECTORY to point to that directory.
> 
> While this works as expected in the general case, it falls apart when
> the developer has TEST_OUTPUT_DIRECTORY explicitly defined either via
> the environment or via config.mak. In that case, test-lib.sh will
> clobber the value that we've just carefully set up to instead contain
> what the developer has defined. As a result, the TEST_OUTPUT_DIRECTORY
> continues to point at the root output directory, not at the nested one.
> 
> This issue causes breakage in the 'test_atexit is run' test case: the
> nested test case writes files into "../../", which is assumed to be the
> parent's trash directory. But because TEST_OUTPUT_DIRECTORY already
> points to to the root output directory, we instead end up writing those
> files outside of the output directory. The parent test case will then
> try to check whether those files still exist in its own trash directory,
> which thus must fail now.
> 
> Fix the issue by adding a new TEST_OUTPUT_DIRECTORY_OVERRIDE variable.
> If set, then we'll always override the TEST_OUTPUT_DIRECTORY with its
> value after sourcing GIT-BUILD-OPTIONS.

This is a very *very* narrowly-specific hack, but I guess it's better
than the test suite failing.

-- 
Felipe Contreras

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: [PATCH] t0000: fix test if run with TEST_OUTPUT_DIRECTORY
  2021-07-20  7:11             ` Jeff King
@ 2021-07-20 16:21               ` Junio C Hamano
  0 siblings, 0 replies; 43+ messages in thread
From: Junio C Hamano @ 2021-07-20 16:21 UTC (permalink / raw)
  To: Jeff King; +Cc: Patrick Steinhardt, git, Felipe Contreras

Jeff King <peff@peff.net> writes:

> On Tue, Jul 20, 2021 at 08:32:26AM +0200, Patrick Steinhardt wrote:
>
>> Fix the issue by adding a new TEST_OUTPUT_DIRECTORY_OVERRIDE variable.
>> If set, then we'll always override the TEST_OUTPUT_DIRECTORY with its
>> value after sourcing GIT-BUILD-OPTIONS.
>
> Thanks, I like this approach much better than removing
> TEST_OUTPUT_DIRECTORY entirely (and I confirmed that it fixes the
> problem).

Yup, and it combines with your subtests-skip fix rather nicely to
solve both problems.  Thanks for working well together.

> I do wish we had a more generic way of overriding stuff in
> GIT-BUILD-OPTIONS, rather than introducing manual _OVERRIDE variables
> for each. But there's not an easy solution here (see the earlier thread
> for some discussion), so this seems like a good immediate step to take.
>
> One small note on the commit message:
>
>> While this works as expected in the general case, it falls apart when
>> the developer has TEST_OUTPUT_DIRECTORY explicitly defined either via
>> the environment or via config.mak.
>
> The mention of the environment confused me for a moment, since:
>
>   TEST_OUTPUT_DIRECTORY=/tmp/foo ./t0000-basic.sh
>
> is already OK. But you probably meant that:
>
>   TEST_OUTPUT_DIRECTORY=/tmp/foo make test
>
> would fail, since "make" would pick up the variable and then write it
> into GIT-BUILD-OPTIONS (just as it would if you put it in config.mak, or
> on the command-line of make).
>
> I don't think it's sufficiently confusing to rewrite the commit message,
> but just something I noted while reading it.

I'll just insert "and runs 'make test'" after "via config.mak" while
queuing.

Again, thanks, both.

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: [PATCH] CodingGuidelines: recommend gender-neutral description
  2021-07-15 16:25     ` [PATCH] CodingGuidelines: recommend gender-neutral description Junio C Hamano
  2021-07-15 16:35       ` Eric Sunshine
  2021-07-16 18:41       ` [PATCH v2] " Junio C Hamano
@ 2021-08-12  8:35       ` Bagas Sanjaya
  2 siblings, 0 replies; 43+ messages in thread
From: Bagas Sanjaya @ 2021-08-12  8:35 UTC (permalink / raw)
  To: Junio C Hamano, Ævar Arnfjörð Bjarmason
  Cc: Derrick Stolee, git

On 15/07/21 23.25, Junio C Hamano wrote:
> +  - If you still need to refer to an example person that is
> +    third-person singular, you may resort to "singular they" to avoid
> +    "he/she/him/her", e.g.
> +
> +      A contributor asks their upstream to pull from them.
> +
> +    Note that this sounds ungrammatical and unnatural to those who
> +    learned English as a second language in some parts of the world.
> +

Addendum: For grammatical correctness (for ESL people), proper, plural 
they can be used. So the last example can be rewritten as:

   Contributors ask their upstream to pull from their repository.

-- 
An old man doll... just what I always wanted! - Clara

^ permalink raw reply	[flat|nested] 43+ messages in thread

end of thread, other threads:[~2021-08-12  8:35 UTC | newest]

Thread overview: 43+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-07-14  1:07 What's cooking in git.git (Jul 2021, #03; Tue, 13) Junio C Hamano
2021-07-14  2:16 ` Eric Sunshine
2021-07-14 16:30   ` Junio C Hamano
2021-07-14 22:39     ` Eric Sunshine
2021-07-14 22:44       ` Junio C Hamano
2021-07-14  8:42 ` Han-Wen Nienhuys
2021-07-14 11:53   ` Ævar Arnfjörð Bjarmason
2021-07-14 11:54   ` Ævar Arnfjörð Bjarmason
2021-07-14 17:28   ` Junio C Hamano
2021-07-14 13:11 ` Derrick Stolee
2021-07-14 14:32   ` Ævar Arnfjörð Bjarmason
2021-07-15 16:25     ` [PATCH] CodingGuidelines: recommend gender-neutral description Junio C Hamano
2021-07-15 16:35       ` Eric Sunshine
2021-07-15 16:47         ` Taylor Blau
2021-07-15 18:02           ` Junio C Hamano
2021-07-16 21:25           ` Felipe Contreras
2021-07-15 17:27         ` Derrick Stolee
2021-07-16 15:11           ` Johannes Schindelin
2021-07-16 21:22           ` Felipe Contreras
2021-07-16 18:41       ` [PATCH v2] " Junio C Hamano
2021-07-16 19:05         ` Derrick Stolee
2021-07-16 19:11         ` Ævar Arnfjörð Bjarmason
2021-07-16 19:50           ` Junio C Hamano
2021-07-16 21:14             ` Felipe Contreras
2021-08-12  8:35       ` [PATCH] " Bagas Sanjaya
2021-07-14 20:11 ` What's cooking in git.git (Jul 2021, #03; Tue, 13) Taylor Blau
2021-07-19  7:35 ` Patrick Steinhardt
2021-07-19  7:53   ` Felipe Contreras
2021-07-19  8:35     ` Jeff King
2021-07-19 10:42       ` Felipe Contreras
2021-07-19 10:56         ` Patrick Steinhardt
2021-07-19 11:25           ` Felipe Contreras
2021-07-19  8:33   ` Jeff King
2021-07-19 10:41     ` Patrick Steinhardt
2021-07-19 10:52       ` Jeff King
2021-07-19 18:40       ` Junio C Hamano
2021-07-19 19:57         ` Felipe Contreras
2021-07-20  6:31           ` Patrick Steinhardt
2021-07-20  7:21             ` Felipe Contreras
2021-07-20  6:32           ` [PATCH] t0000: fix test if run with TEST_OUTPUT_DIRECTORY Patrick Steinhardt
2021-07-20  7:11             ` Jeff King
2021-07-20 16:21               ` Junio C Hamano
2021-07-20  7:24             ` Felipe Contreras

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.