What's cooking in git.git (Jun 2021, #06; Thu, 17)

What's cooking in git.git (Jun 2021, #06; Thu, 17)

[Junio C Hamano]

Here are the topics that have been cooking in my tree.  Commits
prefixed with '-' are only in 'seen' while commits prefixed with '+'
are in 'next'.  The ones marked with '.' do not appear in any of the
integration branches, but I am still holding onto them.  Generally,
being in 'next' is a sign that a topic is stable enough to be used
and are candidate to be in a future release, while being in 'seen'
means nothing more than that the maintainer has found it interesting
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 tip of 'next' has been rewound.  We'll start merging topics that
have been reviewed well down.  On the other hand, some topics have
been waiting for updates for too long.  I've started marking them
for discarding.  Motivated contributors may want to take a look of
them, pick an easy one or two, reroll them on behalf of the original
authors, to resurrect 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/

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

* ab/config-based-hooks-base (2021-06-16) 30 commits
 - hook-list.h: add a generated list of hooks, like config-list.h
 - 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.c: add a hook_exists() wrapper and use it in bugreport.c
 - run-command.h: move find_hook() to hook.h
 - hook: add 'run' subcommand

 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/config-hooks-path-testfix (2021-06-16) 1 commit
 - pre-commit hook tests: don't leave "actual" nonexisting on failure

 Test fix.

 Will merge to 'next'.


* 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"


* ab/pre-auto-gc-hook-test (2021-06-16) 1 commit
 - gc tests: add a test for the "pre-auto-gc" hook

 Test fix.

 Will merge to 'next'.


* jv/userdiff-csharp-update (2021-06-16) 1 commit
 - userdiff: add support for C# record types

 The userdiff pattern for C# learned the token "record".

 Will merge to 'next'.


* en/ort-perf-batch-13 (2021-06-16) 5 commits
 - 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.


* ab/serve-cleanup (2021-06-17) 5 commits
 - serve: use designated initializers
 - transport: use designated initializers
 - transport: rename "fetch" in transport_vtable to "fetch_refs"
 - SQUASH??? struct strvec no longer needed
 - serve: mark has_capability() as static

 Code clean-up around "git serve".


* js/stop-exporting-bogus-columns (2021-06-17) 1 commit
 - pager: do not unnecessarily set COLUMNS on Windows

 When we cannot figure out how wide the terminal is, we use a
 fallback value of 80 ourselves (which cannot be avoided), but when
 we run the pager, we export it in COLUMNS, which forces the pager
 to use the hardcoded value, even when the pager is perfectly
 capable to figure it out itself.  Stop exporting COLUMNS
 only when building on Windows to work around this issue.

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

* hn/reftable (2021-05-20) 28 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
 . refs: make explicit that ref_iterator_peel returns boolean

 The "reftable" backend for the refs API.

 Waiting for reviews.
 Seems to break tests when merged to 'seen'.


* 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.


* ds/status-with-sparse-index (2021-05-22) 14 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
 - dir.c: accept a directory as part of cone-mode patterns
 - unpack-trees: be careful around sparse directory entries
 - 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
 - sparse-index: include EXTENDED flag when expanding
 - sparse-index: skip indexes with unmerged entries
 - Merge branch 'mt/add-rm-in-sparse-checkout' into ds/status-with-sparse-index
 - Merge branch 'ds/sparse-index-protections' into ds/status-with-sparse-index

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

 Expecting a reroll.
 cf. <2784d29b-b22a-2bf6-2450-7b4a0a72df54@gmail.com>


* ab/describe-tests-fix (2021-05-11) 5 commits
 - 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"

 Will merge to 'next'.


* ab/pickaxe-pcre2 (2021-05-11) 22 commits
 - 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.

 Will merge to 'next'.

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

* ah/uninitialized-reads-fix (2021-06-15) 3 commits
 - builtin/checkout--worker: zero-initialise struct to avoid MSAN complaints
 - split-index: use oideq instead of memcmp to compare object_id's
 - bulk-checkin: make buffer reuse more obvious and safer

 Make the codebase MSAN clean.

 Will merge to 'next'.


* ar/typofix (2021-06-14) 1 commit
 - *: fix typos which duplicate a word

 Typofixes.

 Will merge to 'next'.


* jk/revision-squelch-gcc-warning (2021-06-11) 1 commit
 - add_pending_object_with_path(): work around "gcc -O3" complaint

 Warning fix.

 Will merge to 'next'.


* jk/union-merge-binary (2021-06-11) 3 commits
 - 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 resultion variant misbehaved when used with
 binary merge driver.

 Will merge to 'next'.


* js/no-more-multimail (2021-06-11) 1 commit
 - multimail: stop shipping a copy

 Remove multimail from contrib/

 Will merge to 'next'.


* js/subtree-on-windows-fix (2021-06-15) 2 commits
 - subtree: fix assumption about the directory separator
 - subtree: fix the GIT_EXEC_PATH sanity check to work on Windows

 Update "git subtree" to work better on Windows.

 Will merge to 'next'.


* jt/partial-clone-submodule-1 (2021-06-11) 5 commits
 - 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.

 Waiting for reviews.


* ab/mktag-tests (2021-06-15) 6 commits
 - 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.

 Expecting a reroll.
 cf. <87czsnyyt8.fsf@evledraar.gmail.com>


* ab/show-branch-tests (2021-06-15) 4 commits
 - show-branch tests: add missing tests
 - show-branch: fix and test --color output
 - show-branch tests: modernize test code
 - show-branch tests: rename the one "show-branch" test file

 Fill test gaps.

 Waiting for review discussion to settle.
 cf. <162374905722.40525.516266574605586007.git@grubix.eu>


* ah/graph-typofix (2021-06-15) 1 commit
 - graph: improve grammar of "invalid color" error message

 Typofix in an error message.

 Will merge to 'next'.


* 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.


* fc/pull-cleanups (2021-06-15) 3 commits
 - pull: trivial whitespace style fix
 - pull: trivial cleanup
 - pull: cleanup autostash check

 Code cleanup.

 Will merge to 'next'.


* jk/bitmap-tree-optim (2021-06-15) 1 commit
 - bitmaps: don't recurse into trees already in the bitmap

 Avoid duplicated work while building reachability bitmaps.

 Will merge to 'next'.


* jx/t6020-with-older-bash (2021-06-14) 1 commit
 - t6020: fix bash incompatible issue

 Work around inefficient glob substitution in older versions of bash
 by rewriting parts of a test.


* 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.

 Waiting for reviews.


* hn/refs-errno-cleanup (2021-06-11) 8 commits
 - refs: explicitly propagate errno from refs_read_raw_ref
 - refs: clear errno return in refs_resolve_ref_unsafe()
 - refs: add failure_errno to refs_read_raw_ref() signature
 - refs: use refs_resolve_ref_unsafe_with_errno() where needed
 - refs: make errno output explicit for refs_resolve_ref_unsafe
 - 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.

 Will merge to 'next'?


* ab/cmd-foo-should-return (2021-06-09) 1 commit
 - builtins + test helpers: use return instead of exit() in cmd_*

 Code clean-up.

 Will merge to 'next'.


* ab/progress-cleanup (2021-06-08) 1 commit
 - read-cache.c: don't guard calls to progress.c API

 Code clean-up.

 Will merge to 'next'.


* 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/xdiff-bug-cleanup (2021-06-08) 1 commit
 - xdiff: use BUG(...), not xdl_bug(...)

 Code clean-up.

 Will merge to 'next'.


* ar/test-code-cleanup (2021-06-08) 1 commit
 - t: fix whitespace around &&

 Test code clean-up.

 Will merge to 'next'.


* ba/object-info (2021-06-08) 1 commit
 - protocol-caps.h: add newline at end of file

 Code clean-up.

 Will merge to 'next'.


* dd/document-log-decorate-default (2021-06-08) 1 commit
 - doc/log: correct default for --decorate

 Doc clean-up.

 Will merge to 'next'.


* fc/doc-default-to-upstream-config (2021-06-08) 1 commit
 - doc: merge: mention default of defaulttoupstream

 Doc clean-up.

 Will merge to 'next'.


* ms/mergetools-kdiff3-on-windows (2021-06-08) 1 commit
 - mergetools/kdiff3: make kdiff3 work on Windows too

 On Windows, mergetool has been taught to find kdiff3.exe just like
 it finds winmerge.exe.

 Will merge to 'next'.


* ab/pack-objects-stdin (2021-06-09) 4 commits
 - pack-objects.c: make use of REV_INFO_STDIN_LINE_PROCESS
 - pack-objects.c: do stdin parsing via revision.c's API
 - revision.h: unify "disable_stdin" and "read_from_stdin"
 - upload-pack: run is_repository_shallow() before setup_revisions()

 Code clean-up.

 Waiting for reviews.


* ar/doc-libera-chat-in-my-first-contrib (2021-06-09) 1 commit
 - MyFirstContribution: link #git-devel to Libera Chat

 Update MyFirst document.

 Will merge to 'next'.


* ar/mailinfo-memcmp-to-skip-prefix (2021-06-09) 1 commit
 - mailinfo: use starts_with() when checking scissors

 Code clean-up.

 Will merge to 'next'.


* ar/submodule-add (2021-06-16) 3 commits
 - submodule--helper: introduce add-config subcommand
 - submodule--helper: introduce add-clone subcommand
 - submodule--helper: refactor module_clone()

 Rewrite of "git submodule" in C continues.

 Waiting for reviews.


* ds/gender-neutral-doc (2021-06-16) 5 commits
 - SQUASH??? replace neutering tips with that of Æver
 - CodingGuidelines: recommend singular they
 - *: fix typos
 - comments: avoid using the gender of our users
 - doc: avoid using the gender of other people

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

 Will wait for conclusion of the on-list discussion.
 It appears that the updates to the text are favourably accepted by
 reviewers, but not necessarily the update to the guidelines.


* 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.


* jk/doc-max-pack-size (2021-06-09) 1 commit
 - doc: warn people against --max-pack-size

 Doc update.

 Will merge to 'next'.


* lh/systemd-timers (2021-06-14) 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.


* dd/svn-test-wo-locale-a (2021-06-08) 1 commit
 - t: use user-specified utf-8 locale for testing svn

 "git-svn" tests assumed that "locale -a", which is used to pick an
 available UTF-8 locale, is available everywhere.  A knob has been
 introduced to allow testers to specify a suitable locale to use.

 Will merge to 'next'.


* 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>


* mr/cmake (2021-06-11) 3 commits
 - cmake: add warning for ignored MSGFMT_EXE
 - cmake: create compile_commands.json by default
 - cmake: add knob to disable vcpkg

 CMake update.

 Will merge to 'next'.


* 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>


* hn/prep-tests-for-reftable (2021-06-02) 22 commits
 - 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.

 Will merge to 'next'.


* js/trace2-discard-event-docfix (2021-06-04) 1 commit
 - docs: fix api-trace2 doc for "too_many_files" event

 Docfix.

 Will merge to 'next'.


* tk/partial-clone-repack-doc (2021-06-04) 1 commit
 - Remove warning that repack only works on non-promisor packfiles

 Docfix.

 Will merge to 'next'.


* zh/cat-file-batch-fix (2021-06-04) 2 commits
 - cat-file: merge two block into one
 - cat-file: handle trivial --batch format with --batch-all-objects

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

 Will merge to 'next'.


* fc/push-simple-updates (2021-06-02) 7 commits
 - 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".

 Will merge to 'next'.


* fc/push-simple-updates-cleanup (2021-06-02) 13 commits
 - 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".

 Will merge to 'next'.


* tb/complete-diff-anchored (2021-05-31) 1 commit
 - completion: add --anchored to diff's options

 The command line completion (in contrib/) learned that "git diff"
 takes the "--anchored" option.

 Will merge to 'next'.


* en/ort-perf-batch-12 (2021-06-09) 4 commits
 - 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 'next'.


* zh/ref-filter-raw-data (2021-06-16) 9 commits
 . cat-file: re-implement --textconv, --filters options
 . cat-file: reuse err buf in batch_objet_write()
 . cat-file: reuse ref-filter logic
 . ref-filter: introduce free_array_item_internal() function
 . ref-filter: teach get_object() return useful value
 . ref-filter: add %(rest) atom
 . ref-filter: use non-const ref_format in *_atom_parser()
 . ref-filter: add %(raw) atom
 . ref-filter: add obj-type check in grab contents

 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".

 This conflicts with the other topic on "cat-file --batch" by the
 same author.


* jh/builtin-fsmonitor (2021-05-24) 30 commits
 - t/perf: avoid copying builtin fsmonitor files into test repo
 - t7527: test status with untracked-cache and fsmonitor--daemon
 - p7519: add fsmonitor--daemon
 - t7527: create test for 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
 - 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--daemon: implement daemon command options
 - 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 client command options
 - fsmonitor--daemon: add a built-in fsmonitor daemon
 - fsmonitor: introduce `core.useBuiltinFSMonitor` to call the daemon via IPC
 - config: FSMonitor is 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.
 - Merge branch 'jk/perf-in-worktrees' into HEAD
 - Merge branch 'jh/simple-ipc' into jh/rfc-builtin-fsmonitor

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

 What's the status of this one?


* 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.

 Will merge to 'next'?


* ab/send-email-optim (2021-05-28) 13 commits
 - 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 'next'.


* bc/doc-asciidoctor-to-man-wo-xmlto (2021-05-14) 2 commits
 - doc: remove GNU_ROFF option
 - doc: add an option to have Asciidoctor build man pages directly

 An option to render the manual pages via AsciiDoctor bypassing
 xmlto has been introduced.

 What is the status of this one?


* ab/fsck-unexpected-type (2021-05-21) 17 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 -1, not "status" from unpack_loose_header()
 . object-file.c: return -2 on "header too long" in unpack_loose_header()
 . object-file.c: stop dying in parse_loose_header()
 . object-file.c: add missing braces to loose_object_info()
 . object-file.c: make parse_loose_header_extended() public
 . 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.

 Seems to break tests when merged to 'seen'.

--------------------------------------------------
[Will Discard]

* ag/merge-strategies-in-c (2021-03-17) 15 commits
 . sequencer: use the "octopus" merge strategy without forking
 . sequencer: use the "resolve" strategy without forking
 . merge: use the "octopus" strategy without forking
 . merge: use the "resolve" strategy without forking
 . merge-octopus: rewrite in C
 . merge-recursive: move better_branch_name() to merge.c
 . merge-resolve: rewrite in C
 . merge-one-file: rewrite in C
 . update-index: move add_cacheinfo() to read-cache.c
 . merge-index: add a new way to invoke `git-merge-one-file'
 . merge-index: drop the index
 . merge-index: libify merge_one_path() and merge_all()
 . t6060: add tests for removed files
 . t6060: modify multiple files to expose a possible issue with merge-index
 . t6407: modernise tests

 The resolve and octopus merge strategy backends have been rewritten
 in C.

 Will discard.
 We had to wait for a reroll for too long.
 cf. <nycvar.QRO.7.76.6.2103241142220.50@tvgsbejvaqbjf.bet>


* mr/bisect-in-c-4 (2021-04-11) 4 commits
 . bisect--helper: retire `--bisect-next-check` subcommand
 . bisect--helper: reimplement `bisect_run` shell function in C
 . bisect--helper: reimplement `bisect_visualize()`shell function in C
 . run-command: make `exists_in_PATH()` non-static

 The codepaths involved in running "git bisect visualize" and "git
 bisect run" has been rewritten in C.

 Will discard.
 We had to wait for a reroll for too long.
 cf. <xmqq35vwh8qk.fsf@gitster.g>, <xmqqy2doftrj.fsf@gitster.g>,
 <CAP8UFD3X24F3qgefHpi00PM-KUk+vcqxwy2Dbngbyj7ciavCVQ@mail.gmail.com>
 May want to boost the test coverage.


* ma/t0091-bugreport-fix (2021-04-12) 1 commit
 . t0091-bugreport.sh: actually verify some content of report

 Test fix.

 Will discard.
 We had to wait for a reroll for too long.
 Expecting a reroll.
 cf. <YHYZTLl90rkWWVOr@google.com>, <87a6q22dei.fsf@evledraar.gmail.com>


* ls/fast-export-signed (2021-05-03) 5 commits
 . fast-export, fast-import: add support for signed-commits
 . fast-export: do not modify memory from get_commit_buffer
 . git-fast-export.txt: clarify why 'verbatim' may not be a good idea
 . fast-export: rename --signed-tags='warn' to 'warn-verbatim'
 . git-fast-import.txt: add missing LF in the BNF

 "git fast-export" offers a way to control how signed tags are
 handled; the mechanism has been extended to allow specifying how
 signed commits are handled as well.

 Will discard.
 We had to wait for a reroll for too long.
 cf. <xmqqa6pca0pv.fsf@gitster.g>, <xmqq1rao9zev.fsf@gitster.g>


* tb/multi-pack-bitmaps (2021-04-10) 23 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
 . 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: 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
 . Merge branch 'tb/pack-preferred-tips-to-give-bitmap' into tb/multi-pack-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.

 Will discard.
 We had to wait for a reroll for too long.
 cf. <cover.1617991824.git.me@ttaylorr.com>
 Seems to break tests when merged to 'seen'.


* fc/neuter-doc (2021-06-14) 2 commits
 . comments: avoid using the gender of our users
 . doc: avoid using the gender of other people

 An attempt to avoid gendered pronouns by rewriting parts of docs.

 This seems to give more readable result than Stolee's "use singular
 they" topic.

 Now will be part of the ds/gender-neutral-doc topic.


* es/config-based-hooks (2021-05-27) 37 commits
 . docs: link githooks and git-hook manpages
 . doc: clarify fsmonitor-watchman specification
 . run-command: stop thinking about hooks
 . git-send-email: use 'git hook run' for 'sendemail-validate'
 . bugreport: use hook_exists instead of find_hook
 . receive-pack: convert receive hooks to hook.h
 . post-update: use hook.h library
 . proc-receive: acquire hook list from hook.h
 . receive-pack: convert 'update' hook to hook.h
 . reference-transaction: look for hooks in config
 . transport: convert pre-push hook to use config
 . hook: convert 'post-rewrite' hook to config
 . hooks: convert 'post-checkout' hook to hook library
 . git-p4: use 'git hook' to run hooks
 . receive-pack: convert push-to-checkout hook to hook.h
 . read-cache: convert post-index-change hook to use config
 . rebase: teach pre-rebase to use hook.h
 . gc: use hook library for pre-auto-gc hook
 . merge: use config-based hooks for post-merge hook
 . am: convert applypatch hooks to use config
 . commit: use config-based hooks
 . hooks: allow callers to capture output
 . run-command: allow capturing of collated output
 . hook: provide stdin by string_list or callback
 . run-command: add stdin callback for parallelization
 . hook: allow specifying working directory for hooks
 . hook: allow parallel hook execution
 . run-command: allow stdin for run_processes_parallel
 . hook: support passing stdin to hooks
 . hook: introduce hook_exists()
 . hook: add 'run' subcommand
 . parse-options: parse into strvec
 . hook: implement hookcmd.<name>.skip
 . hook: teach hook.runHookDir
 . hook: include hookdir hook in list
 . hook: introduce git-hook subcommand
 . doc: propose hooks managed by the config

 Propose hook scripts defined in the configuration.

 Tentatively kicked out to give ab/config-based-hooks-base a chance
 to interact with other topics in flight.

jh/builtin-fsmonitor, was Re: What's cooking in git.git (Jun 2021, #06; Thu, 17)

[Johannes Schindelin]

Hi Junio,

On Thu, 17 Jun 2021, Junio C Hamano wrote:

> * jh/builtin-fsmonitor (2021-05-24) 30 commits
>  - t/perf: avoid copying builtin fsmonitor files into test repo
>  - t7527: test status with untracked-cache and fsmonitor--daemon
>  - p7519: add fsmonitor--daemon
>  - t7527: create test for 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
>  - 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--daemon: implement daemon command options
>  - 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 client command options
>  - fsmonitor--daemon: add a built-in fsmonitor daemon
>  - fsmonitor: introduce `core.useBuiltinFSMonitor` to call the daemon via IPC
>  - config: FSMonitor is 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.
>  - Merge branch 'jk/perf-in-worktrees' into HEAD
>  - Merge branch 'jh/simple-ipc' into jh/rfc-builtin-fsmonitor
>
>  An attempt to write and ship with a watchman equivalent tailored
>  for our use.
>
>  What's the status of this one?

I am not Jeff, but I know that he is busy getting back to it, and plans on
submitting a third iteration.

This is an important topic: it allows working with quite large worktrees,
i.e. it is a crucial component in our endeavor to make Git scale better.

Ciao,
Dscho

js/subtree-on-windows-fix, was Re: What's cooking in git.git (Jun 2021, #06; Thu, 17)

[Johannes Schindelin]

Hi Junio,


On Thu, 17 Jun 2021, Junio C Hamano wrote:

> * js/subtree-on-windows-fix (2021-06-15) 2 commits
>  - subtree: fix assumption about the directory separator
>  - subtree: fix the GIT_EXEC_PATH sanity check to work on Windows
>
>  Update "git subtree" to work better on Windows.

Technically, it is not "better". Without the GIT_EXEC_PATH fix, it does
not work _at all_ on Windows ;-)

>  Will merge to 'next'.

Thank you. Once it hits `next`, I will merge the corresponding PR in Git
for Windows so that a new snapshot is available for users who rely on `git
subtree`.

Ciao,
Dscho

Contributions which I feel are dangerous and/or deceptive (Was: Re: What's cooking in git.git (Jun 2021, #06; Thu, 17))

[Elijah Newren]

Hi,

I hate doing this, but...

On Wed, Jun 16, 2021 at 7:58 PM Junio C Hamano <gitster@pobox.com> wrote:

> * fc/pull-cleanups (2021-06-15) 3 commits
>  - pull: trivial whitespace style fix
>  - pull: trivial cleanup
>  - pull: cleanup autostash check
>
>  Code cleanup.
>
>  Will merge to 'next'.

Please don't.

Let me quote from four recent emails, three of which will look
unrelated at first, and then I'll tie it together:

From https://lore.kernel.org/git/CABPp-BGrKjpjb5epv1nXcvn4Z1OHP4Uf6G1f9FARmwUcFVa96Q@mail.gmail.com/
:
(a quote of mine to Felipe)
"""
You clearly have talent.
With regards to the zdiff3 patches, I've stated above why I think you
haven't done your due diligence.  Sometimes people make mistakes;
that's something that can be corrected.  What I find egregious here is
that even when Peff and I have pointed out how more due diligence is
expected and needed, you've dug in to explain why you think your
course of action was reasonable (both here and in
https://lore.kernel.org/git/60c82a622ae66_e5292087f@natae.notmuch/).
That in my mind raises your submissions from careless to glaringly
cavalier.  Further, it makes me suspect we may continue to see you
repeat such behavior.  That worries me.
"""

From https://lore.kernel.org/git/CABPp-BEXtJtkkh9Diuo4e1K1ci=vggGxkLRDfkpOH12LM8TCfA@mail.gmail.com/
:
(another quote of mine to Felipe)
"""
...you
are willing to eschew what I view as even the most basic of
responsibilities in ensuring you are submitting valid patches, and
even worse, you are unwilling to change how you approach the project
even when those are pointed out to you.
"""

From https://lore.kernel.org/git/YMhx2BFlwUxZ2aFJ@coredump.intra.peff.net/ :
(a quote from Peff to Felipe)
"""
But much more important, in my opinion: that you would dismiss without
further investigation a report of a bug from the one person who actually
had experience running with the patch implies a level of carelessness
that I'm not comfortable with for the project.

I had already given up on having substantive discussion with you, but I
had hoped I could help the project by pointing out relevant facts in
areas that you were working in. But if a simple statement like "this
segfaulted for me" is not even useful, then I don't see much point in
communicating with you at all.
"""

From https://lore.kernel.org/git/60c887f678c88_e63320846@natae.notmuch/ :
(a quote from Felipe responding to me)
"""
> * `Reviewed-by:`, unlike the other tags, can only be offered by the
>   reviewer and means that she is completely satisfied that the patch
>   is ready for application.  It is usually offered only after a
>   detailed review.

Yeah, I read that after I sent v3. In this series I simply cherry-picked
it from a previous series.
"""

The first three quotes highlight what I feel is a reckless submission
from Felipe; from the threads you can read in the linked messages, I
believe he sees no problems in his approach and appears intent to
continue that course in the future.

But the fourth raises the alarm levels for me further.  In the fourth
quote, Felipe admits to having learned what "Reviewed-by" meant, then
cherry-picked a patch of his own with an inappropriate Reviewed-by and
resubmitted it anyway.  And he did not resubmit the series with the
error corrected when it was raised to his attention.  That feels
deceptive to me.

If I were in charge, at this point I would drop all of Felipe's
patches on the floor (not just the ones from these threads), and not
accept any further ones.  I am not in charge, though, and you have
more patience than me.  But I will not be reviewing or responding to
Felipe's patches further.  Please do not trust future submissions from
him that have an "Acked-by" or "Reviewed-by" from me, including
resubmissions of past patches.

I will allow Felipe to have the last word if he so chooses; I won't
respond further.

RE: Contributions which I feel are dangerous and/or deceptive (Was: Re: What's cooking in git.git (Jun 2021, #06; Thu, 17))

[Felipe Contreras]

Elijah Newren wrote:
> I hate doing this, but...
> 
> On Wed, Jun 16, 2021 at 7:58 PM Junio C Hamano <gitster@pobox.com> wrote:
> 
> > * fc/pull-cleanups (2021-06-15) 3 commits
> >  - pull: trivial whitespace style fix
> >  - pull: trivial cleanup
> >  - pull: cleanup autostash check
> >
> >  Code cleanup.
> >
> >  Will merge to 'next'.
> 
> Please don't.
> 
> Let me quote from four recent emails, three of which will look
> unrelated at first, and then I'll tie it together:

This is called an ad hominem attack: you are attacking the person
submitting the patches, not the patches themselves.

Do you see anything wrong with these particular patches?

You are mentioning another completely unrelated thread with completely
unrelated patches. I already said I did my best on that other thread,
and I wished you good luck with those patches.

Now you are coming here to personally attack me. This is harassment,
and it goes against the code of conduct.


These are examples of what constitutes positive behavior:

  * Demonstrating empathy and kindness toward other people

This is definitely not happening from you.

  * Being respectful of differing opinions, viewpoints, and experiences

You are disrespecting a differing opinion.

  * Giving and gracefully accepting constructive feedback

You are not giving constructive feedback.

What do you want me to do with the 3 patches above? Be constructive.

  * Accepting responsibility and apologizing to those affected by our mistakes,
    and learning from the experience

I believe your personal attacks merit an apology, but I'm not even going
to request that, all I wish is that you focus on the patches at hand.

  * Focusing on what is best not just for us as individuals, but for the
    overall community

You are not doing this either. Forget about me and think about the
community. Do you see the patches above helping or hindering the
community?

If they hinder, please state how, and I'll fix them.


Examples of **unacceptable** behavior:

  * Trolling, insulting or derogatory comments, and personal or political attacks

This is a personal attack: it's directed towards me, not the patches.

  * Public or private harassment

This is public harassment.


I have a pretty thick skin, and I rarely do use my emotions for the
basis of anything, but your personal attacks are draining me
emotionally. I receive personal attacks in a multitude of media, but I
did not expect them on the git mailing list, and especially not from
you.

I have no problem soldiering through personal attacks if doing so is
going to result in a better outcome, in this case better patches. But I
don't see any better outcome on the horizon. These personal attacks are
gratuitous.

Once again, please focus on the patches, and I'll be happy to address
any and all of your concerns.

Cheers.

-- 
Felipe Contreras

RE: What's cooking in git.git (Jun 2021, #06; Thu, 17)

[Felipe Contreras]

Junio C Hamano wrote:
> * 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>

As I already stated in my previous reply [1] to your what's cooking of
June 10, I already rerolled these:

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

I've sent a v4 [2] identical to v3 so they don't get lost again.

[1] https://lore.kernel.org/git/60c22863185f4_b25b1208e2@natae.notmuch/
[2] https://lore.kernel.org/git/20210617143527.77329-1-felipe.contreras@gmail.com/

-- 
Felipe Contreras

Re: Contributions which I feel are dangerous and/or deceptive (Was: Re: What's cooking in git.git (Jun 2021, #06; Thu, 17))

[Elijah Newren]

On Thu, Jun 17, 2021 at 7:19 AM Felipe Contreras
<felipe.contreras@gmail.com> wrote:
>
> Elijah Newren wrote:
> > I hate doing this, but...
> >
> > On Wed, Jun 16, 2021 at 7:58 PM Junio C Hamano <gitster@pobox.com> wrote:
> >
> > > * fc/pull-cleanups (2021-06-15) 3 commits
> > >  - pull: trivial whitespace style fix
> > >  - pull: trivial cleanup
> > >  - pull: cleanup autostash check
> > >
> > >  Code cleanup.
> > >
> > >  Will merge to 'next'.
...
> Do you see anything wrong with these particular patches?
...

Sorry for responding when I said I wouldn't but let me clarify my own email.

The *code* changes in fc/pull-cleanups are good, I said as much
previously.  The commit messages are also fine, except for the
misleading Reviewed-by claim that you still aren't addressing.  That
could be overlooked on its own.

Any other problematic patches or portions thereof of yours could
easily have been written off as mistakes and been no big deal.

My concern is primarily in how you *respond* to feedback.  I feel you
have displayed a callous disregard for what others find critical and
important, and appear to be unwilling or unable to adapt and work with
the community.  It was particularly your recent emails with Peff at
[1], [2], and [3] that have me deeply troubled.  Troubled enough that
I do not want my name used to endorse your changes, particularly when
I already pointed out that you have used my name in a false
endorsement of your patch and you have now responded to but not
corrected that problem (including again just now in this thread),
making it appear to me that this was no mistake.  I do not want such
false endorsements to occur again, and felt I needed to speak up to
make that happen.

[1] https://lore.kernel.org/git/60c647c1d9b5c_41f452089@natae.notmuch/
[2] https://lore.kernel.org/git/60c82a622ae66_e5292087f@natae.notmuch/
[3] https://lore.kernel.org/git/60c87fc6a87ba_e6332084f@natae.notmuch/

Re: Contributions which I feel are dangerous and/or deceptive (Was: Re: What's cooking in git.git (Jun 2021, #06; Thu, 17))

[Felipe Contreras]

Elijah Newren wrote:
> On Thu, Jun 17, 2021 at 7:19 AM Felipe Contreras
> <felipe.contreras@gmail.com> wrote:
> >
> > Elijah Newren wrote:
> > > I hate doing this, but...
> > >
> > > On Wed, Jun 16, 2021 at 7:58 PM Junio C Hamano <gitster@pobox.com> wrote:
> > >
> > > > * fc/pull-cleanups (2021-06-15) 3 commits
> > > >  - pull: trivial whitespace style fix
> > > >  - pull: trivial cleanup
> > > >  - pull: cleanup autostash check
> > > >
> > > >  Code cleanup.
> > > >
> > > >  Will merge to 'next'.
> ...
> > Do you see anything wrong with these particular patches?
> ...
> 
> Sorry for responding when I said I wouldn't but let me clarify my own email.
> 
> The *code* changes in fc/pull-cleanups are good, I said as much
> previously.  The commit messages are also fine, except for the
> misleading Reviewed-by claim that you still aren't addressing.

I did address that two days ago:

https://lore.kernel.org/git/60c887f678c88_e63320846@natae.notmuch/

I said I guess I'll avoid reviewed-by.

Do you want me to resend the patches without that trailer? If that's
what you wanted all you needed was to say so.

I just did so, to be safe [1].

> That could be overlooked on its own.
> 
> Any other problematic patches or portions thereof of yours could
> easily have been written off as mistakes and been no big deal.
> 
> My concern is primarily in how you *respond* to feedback.

You titled this sub-thread "Contributions which I feel are dangerous
and/or deceptive", that has nothing to do with feedback.

Additionally, responses to feedback have nothing to do with the parent
thread "What's cooking in git.git".

I'd be happy to discuss any comments you might have regarding my
responses to feedback in the appropriate thread, but I don't think this
is it.

> I feel you have displayed a callous disregard for what others find
> critical and important, and appear to be unwilling or unable to adapt
> and work with the community.

OK. You are entitled to having that opinion, that doesn't mean it's
necessarily true.

I am entitled to have my own opinion and disagree with you, and so can
others.

> It was particularly your recent emails with Peff at [1], [2], and [3]
> that have me deeply troubled.

All those responses are from the same thread for the same patch [2].
That patch never even landed on "seen", nor is there any remote
possibility of it ever landing on "seen", so I don't see any urgency in
dealing with those responses.

That patch has been removed from the archive even though it's a direct
copy of Uwe's patch [3], and Uwe's patch remains there. So this is
clearly an ad hominem thing: if Uwe sends it it's OK, if I send it it's
not OK.

There is nothing urgent for me to do regarding [2], so I'll deal with
the dangling responses of that thread (which likely include personal
attacks) later.

> Troubled enough that I do not want my name used to endorse your
> changes, particularly when I already pointed out that you have used my
> name in a false endorsement of your patch

You may disagree on what "endorsement" means, but most people take:

  Yes, very nice!  Thanks. [4]

to mean an endorsement (approval).

Although the Git project doesn't explicitely state an equivalence, the
Linux project does:

  Hence patch mergers will sometimes manually convert an acker's "yep,
  looks good to me" into an Acked-by: (but note that it is usually
  better to ask for an explicit ack).

Yes, I mistakenly used reviewed-by instead of very-nice-by (or something
similar), which in Git's by-laws could be considered a no-no. I did not
know that at the time, so it wouldn't be generous of you to attribute
that mistake to malice.

But that most definitely is not "false endorsement".

For some reason you decided to launch a personal vendetta against me,
threw personal attacks, and now you are slandering me, implying that I
forged your endorsement of my patch.

This is not true. You did endorse my patch [4].


For reference, here are all the last 5 comments that got translated to a
Reviewed-by line:

  This looks good - it's exactly the same as the change I approved previously
  Looks good to me [Elijah Newren]
  this v2 patch looks good to me
  This change looks good to me [Elijah Newren] (explicit Reviewed-by)
  Thanks, this version looks good to me

Only *one* has an explicit Reviewed-by, and it's by you. I think it's
safe to say it's not a generalized practice.

Moreover, you yourself said "Looks good to me" without an explicit
Reviewed-by [5], and Derrick Stolee used that in his next version of the
series [6].

Why aren't you accusing Derrick Stolee of "false endorsement"?

Could it be that this has absolutely nothing to do with the action, and
everything to do with the person doing the action?


None of this has anything to do with "[c]ontributions which [you] feel are
dangerous and/or deceptive".

Cheers.

[1] https://lore.kernel.org/git/20210617161710.81730-1-felipe.contreras@gmail.com/
[2] https://lore.kernel.org/git/20210613143155.836591-1-felipe.contreras@gmail.com/
[3] https://lore.kernel.org/git/1362602202-29749-1-git-send-email-u.kleine-koenig@pengutronix.de/
[4] https://lore.kernel.org/git/CABPp-BEsQWsHMAmwc3gmJnXcS+aR-FtoMJxBRQ=BpARP49-L-Q@mail.gmail.com/
[5] https://lore.kernel.org/git/CABPp-BFudyBP8c_ROmxDEeuu5AfdoyVW8hNPYqVdFPFNofJnCQ@mail.gmail.com/
[6] https://lore.kernel.org/git/1d825dfdc70b8c658c4b6317310706bb6386f468.1620432501.git.gitgitgadget@gmail.com/

-- 
Felipe Contreras

Re: What's cooking in git.git (Jun 2021, #06; Thu, 17)

[brian m. carlson]

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

On 2021-06-17 at 02:55:26, Junio C Hamano wrote:
> * bc/doc-asciidoctor-to-man-wo-xmlto (2021-05-14) 2 commits
>  - doc: remove GNU_ROFF option
>  - doc: add an option to have Asciidoctor build man pages directly
> 
>  An option to render the manual pages via AsciiDoctor bypassing
>  xmlto has been introduced.
> 
>  What is the status of this one?

Probably best to drop it.  I think Felipe didn't want his sign-off on
it, and I don't think there's a good way to produce an equivalent patch
without incorporating his changes.  We don't seem to see eye to eye on
an appropriate solution to the problem, and I don't feel like arguing
about it further.
-- 
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA

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

Re: What's cooking in git.git (Jun 2021, #06; Thu, 17)

[Jeff King]

On Thu, Jun 17, 2021 at 11:58:25PM +0000, brian m. carlson wrote:

> On 2021-06-17 at 02:55:26, Junio C Hamano wrote:
> > * bc/doc-asciidoctor-to-man-wo-xmlto (2021-05-14) 2 commits
> >  - doc: remove GNU_ROFF option
> >  - doc: add an option to have Asciidoctor build man pages directly
> > 
> >  An option to render the manual pages via AsciiDoctor bypassing
> >  xmlto has been introduced.
> > 
> >  What is the status of this one?
> 
> Probably best to drop it.  I think Felipe didn't want his sign-off on
> it, and I don't think there's a good way to produce an equivalent patch
> without incorporating his changes.  We don't seem to see eye to eye on
> an appropriate solution to the problem, and I don't feel like arguing
> about it further.

Hmm. I'm not sure if that's a good resolution here. I do think many
people were positive in moving in that direction. If there's a
contributor that people have trouble working with, I'm OK giving up on
possible contributions they could make, even adaptations of their work.

But if by working in an area they poison it for others (because there's
no desire to work with them, but no desire to step on their toes) that
doesn't seem like a workable long-term strategy.

I don't think this topic is particularly urgent, so I'm OK to drop it
for now (and as always, it's your choice what you work on). But I'm
worried about the general precedent / principle.

-Peff

Re: What's cooking in git.git (Jun 2021, #06; Thu, 17)

[Felipe Contreras]

brian m. carlson wrote:
> On 2021-06-17 at 02:55:26, Junio C Hamano wrote:
> > * bc/doc-asciidoctor-to-man-wo-xmlto (2021-05-14) 2 commits
> >  - doc: remove GNU_ROFF option
> >  - doc: add an option to have Asciidoctor build man pages directly
> > 
> >  An option to render the manual pages via AsciiDoctor bypassing
> >  xmlto has been introduced.
> > 
> >  What is the status of this one?
> 
> Probably best to drop it.

> I think Felipe didn't want his sign-off on it, and I don't think
> there's a good way to produce an equivalent patch without
> incorporating his changes.

I explained very clearly what I would expect to happen for this patch to
be valid [1]; you don't need to drop the patch, simply state that *you*
wrote the commit message, not me.

Here, I'm copying *exactly* what I wrote so there's no confusion:

  Hard to tell in this frankenstein commit. I'd be fine with a
  Commit-message-by line.

> We don't seem to see eye to eye on an appropriate solution to the
> problem, and I don't feel like arguing about it further.

I don't see what is the big problem. I said you should split your patch
into multiple patches, since I believe your patch is doing multiple
unlrelated changes at once.

In fact, your patches don't not apply to master anymore (since you made too
many changes), while my patch series [2] does apply cleanly.

I don't mind our competening series to hash it out again, but first you
need to send another round which does applie cleanly on top of
master--unlike your previous one. And then I'd comment my objections to
it, yet again.

Cheers.

[1] https://lore.kernel.org/git/609b5c85b7c61_678ff20848@natae.notmuch/
[2] https://lore.kernel.org/git/20210608090026.1737348-1-felipe.contreras@gmail.com/

-- 
Felipe Contreras

Re: What's cooking in git.git (Jun 2021, #06; Thu, 17)

[Felipe Contreras]

Jeff King wrote:
> On Thu, Jun 17, 2021 at 11:58:25PM +0000, brian m. carlson wrote:
> 
> > On 2021-06-17 at 02:55:26, Junio C Hamano wrote:
> > > * bc/doc-asciidoctor-to-man-wo-xmlto (2021-05-14) 2 commits
> > >  - doc: remove GNU_ROFF option
> > >  - doc: add an option to have Asciidoctor build man pages directly
> > > 
> > >  An option to render the manual pages via AsciiDoctor bypassing
> > >  xmlto has been introduced.
> > > 
> > >  What is the status of this one?
> > 
> > Probably best to drop it.  I think Felipe didn't want his sign-off on
> > it, and I don't think there's a good way to produce an equivalent patch
> > without incorporating his changes.  We don't seem to see eye to eye on
> > an appropriate solution to the problem, and I don't feel like arguing
> > about it further.
> 
> Hmm. I'm not sure if that's a good resolution here. I do think many
> people were positive in moving in that direction.

I don't know what you mean by "that direction", but I was the one that
included your patches on top of his series [1], not brian.

So, if your patches have anything to do with "that directioon", you are
on my side.

Cheers.

[1] https://lore.kernel.org/git/20210521224452.530852-1-felipe.contreras@gmail.com/

-- 
Felipe Contreras

Re: What's cooking in git.git (Jun 2021, #06; Thu, 17)

[Jeff Hostetler]

On 6/16/21 10:55 PM, Junio C Hamano wrote:
...
> 
> * jh/builtin-fsmonitor (2021-05-24) 30 commits
>   - t/perf: avoid copying builtin fsmonitor files into test repo
>   - t7527: test status with untracked-cache and fsmonitor--daemon
>   - p7519: add fsmonitor--daemon
>   - t7527: create test for 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
>   - 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--daemon: implement daemon command options
>   - 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 client command options
>   - fsmonitor--daemon: add a built-in fsmonitor daemon
>   - fsmonitor: introduce `core.useBuiltinFSMonitor` to call the daemon via IPC
>   - config: FSMonitor is 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.
>   - Merge branch 'jk/perf-in-worktrees' into HEAD
>   - Merge branch 'jh/simple-ipc' into jh/rfc-builtin-fsmonitor
> 
>   An attempt to write and ship with a watchman equivalent tailored
>   for our use.
> 
>   What's the status of this one?
> 

I went on vacation shortly after I send V2.  I'm back now, but still
catching up on my various inboxes.

I'll send a V3 after I get caught up.

Thanks,
Jeff

Re: What's cooking in git.git (Jun 2021, #06; Thu, 17)

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> Hmm. I'm not sure if that's a good resolution here. I do think many
> people were positive in moving in that direction. If there's a
> contributor that people have trouble working with, I'm OK giving up on
> possible contributions they could make, even adaptations of their work.
>
> But if by working in an area they poison it for others (because there's
> no desire to work with them, but no desire to step on their toes) that
> doesn't seem like a workable long-term strategy.

You may lick a corner of a piece of cake and think that it would
repel other people enough to leave only you to consider eating it,
but no, in this project, you aren't allowed to lick a Makefile and
claim that you own it.  Also, if some contributors get too annoying
to be worth our time interacting with, it is OK to ignore them.

> I don't think this topic is particularly urgent, so I'm OK to drop it
> for now (and as always, it's your choice what you work on). But I'm
> worried about the general precedent / principle.

Ignoring valid work

[Felipe Contreras]

Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
> 
> > Hmm. I'm not sure if that's a good resolution here. I do think many
> > people were positive in moving in that direction. If there's a
> > contributor that people have trouble working with, I'm OK giving up on
> > possible contributions they could make, even adaptations of their work.
> >
> > But if by working in an area they poison it for others (because there's
> > no desire to work with them, but no desire to step on their toes) that
> > doesn't seem like a workable long-term strategy.
> 
> You may lick a corner of a piece of cake and think that it would
> repel other people enough to leave only you to consider eating it,
> but no, in this project, you aren't allowed to lick a Makefile and
> claim that you own it.

I wonder who might have attempted to do that in your view.

In reality have I have never attempted to do anything remotely close to
that.

> Also, if some contributors get too annoying to be worth our time
> interacting with, it is OK to ignore them.

But do you have a valid reason? Or is it just petty personal animus?

Talk is cheap. Code is what speaks.

I'm doing valid, useful, and substantial code.

It is the project that suffers from ignoring it.

Ignore me all you want, but the code doesn't stop being valid.

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

-- 
Felipe Contreras

Re: What's cooking in git.git (Jun 2021, #06; Thu, 17)

[Emily Shaffer]

On Thu, Jun 17, 2021 at 11:55:26AM +0900, Junio C Hamano wrote:
> * 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.
> 
>  Will merge to 'next'?

I've still not seen much in the way of reviews on this series; mostly
Randall and I have been talking about ramifications for NonStop, but
those conversations haven't resulted in changes to the series itself.
I think it's fine to merge, but I wrote it, so you shouldn't trust my
opinion. :)

We've been running this series internally at Google, though, and it
looks like we do want to look up more ancestors than just the one
generation, after all. However, I'd prefer to send that as a follow-on
patch, compared stalling this topic further.

We do have some early insights from these, though. One interesting
observation is that it appears Git is more often invoked via some
wrapper than interactively; that's not too surprising given that we have
a lot of builders who perform Git operations.

Anyway, all this to say that we've found this trace useful at Google and
it's working well for us. Anybody interested in a speedy review would be
very welcome.

 - Emily

RE: What's cooking in git.git (Jun 2021, #06; Thu, 17)

[Randall S. Becker]

On June 25, 2021 6:22 PM, Emily Shaffer wrote:
>On Thu, Jun 17, 2021 at 11:55:26AM +0900, Junio C Hamano wrote:
>> * 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.
>>
>>  Will merge to 'next'?
>
>I've still not seen much in the way of reviews on this series; mostly Randall and I have been talking about ramifications for
NonStop, but
>those conversations haven't resulted in changes to the series itself.

I'm waiting for the merge to try it in our environment in some real-world situations on the platform. It should be interesting to
see what can be reported and subsequently contributed.

>I think it's fine to merge, but I wrote it, so you shouldn't trust my opinion. :)
>
>We've been running this series internally at Google, though, and it looks like we do want to look up more ancestors than just the
one
>generation, after all. However, I'd prefer to send that as a follow-on patch, compared stalling this topic further.
>
>We do have some early insights from these, though. One interesting observation is that it appears Git is more often invoked via
some
>wrapper than interactively; that's not too surprising given that we have a lot of builders who perform Git operations.
>
>Anyway, all this to say that we've found this trace useful at Google and it's working well for us. Anybody interested in a speedy
review
>would be very welcome.

Re: What's cooking in git.git (Jun 2021, #06; Thu, 17)

[Jeff Hostetler]

On 6/25/21 6:21 PM, Emily Shaffer wrote:
> On Thu, Jun 17, 2021 at 11:55:26AM +0900, Junio C Hamano wrote:
>> * 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.
>>
>>   Will merge to 'next'?
> 
> I've still not seen much in the way of reviews on this series; mostly
> Randall and I have been talking about ramifications for NonStop, but
> those conversations haven't resulted in changes to the series itself.
> I think it's fine to merge, but I wrote it, so you shouldn't trust my
> opinion. :)
> 
> We've been running this series internally at Google, though, and it
> looks like we do want to look up more ancestors than just the one
> generation, after all. However, I'd prefer to send that as a follow-on
> patch, compared stalling this topic further.
> 
> We do have some early insights from these, though. One interesting
> observation is that it appears Git is more often invoked via some
> wrapper than interactively; that's not too surprising given that we have
> a lot of builders who perform Git operations.
> 
> Anyway, all this to say that we've found this trace useful at Google and
> it's working well for us. Anybody interested in a speedy review would be
> very welcome.
> 
>   - Emily
> 

I just took a look at your V5 and made a few comments.
Jeff