What's cooking in git.git (Jan 2021, #02; Fri, 8)

What's cooking in git.git (Jan 2021, #02; Fri, 8)

[Junio C Hamano]

Here are the topics that have been cooking.  Commits prefixed with '-' are
only in 'seen' (formerly 'pu'---proposed updates) 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.

Many topics that have been cooking in the 'next' branch during the
pre-release freeze at the year end have now been merged to the
'master' branch, and the tip of the 'next' branch has been rewound.

The ".gitignore or .gitattributes cannot be a symlink" topic has
been ejected out of 'next' for now.  We do want to resurrect it
possibly with some opt-in loosening of the rule.

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]

* en/ort-directory-rename (2021-01-07) 18 commits
 - merge-ort: fix a directory rename detection bug
 - merge-ort: process_renames() now needs more defensiveness
 - merge-ort: implement apply_directory_rename_modifications()
 - merge-ort: add a new toplevel_dir field
 - merge-ort: implement handle_path_level_conflicts()
 - merge-ort: implement check_for_directory_rename()
 - merge-ort: implement apply_dir_rename() and check_dir_renamed()
 - merge-ort: implement compute_collisions()
 - merge-ort: modify collect_renames() for directory rename handling
 - merge-ort: implement handle_directory_level_conflicts()
 - merge-ort: implement compute_rename_counts()
 - merge-ort: copy get_renamed_dir_portion() from merge-recursive.c
 - merge-ort: add outline of get_provisional_directory_renames()
 - merge-ort: add outline for computing directory renames
 - merge-ort: collect which directories are removed in dirs_removed
 - merge-ort: initialize and free new directory rename data structures
 - merge-ort: add new data structures for directory rename detection
 - Merge branch 'en/merge-ort-3' into en/ort-directory-rename
 (this branch uses en/merge-ort-3.)

 ORT merge strategy learns to infer "renamed directory" while
 merging.


* jk/forbid-lf-in-git-url (2021-01-07) 2 commits
 - fsck: reject .gitmodules git:// urls with newlines
 - git_connect_git(): forbid newlines in host and path

 Newline characters in the host and path part of git:// URL are
 now forbidden.

 Will merge to 'next'.


* ps/fetch-atomic (2021-01-07) 2 commits
 - fetch: implement support for atomic reference updates
 - fetch: allow passing a transaction to `s_update_ref()`

 "git fetch" learns to treat ref updates atomically in all-or-none
 fashion, just like "git push" does, with the new "--atomic" option.


* jc/sign-off (2021-01-07) 1 commit
 - SubmittingPatches: tighten wording on "sign-off" procedure

 Doc update.

 Will merge to 'next'.

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

* ab/trailers-extra-format (2020-12-09) 5 commits
  (merged to 'next' on 2020-12-14 at 9fc731944e)
 + pretty format %(trailers): add a "key_value_separator"
 + pretty format %(trailers): add a "keyonly"
 + pretty-format %(trailers): fix broken standalone "valueonly"
 + pretty format %(trailers) doc: avoid repetition
 + pretty format %(trailers) test: split a long line

 The "--format=%(trailers)" mechanism gets enhanced to make it
 easier to design output for machine consumption.


* en/merge-ort-2 (2020-12-13) 7 commits
  (merged to 'next' on 2020-12-21 at ef5b184349)
 + merge-ort: add modify/delete handling and delayed output processing
 + merge-ort: add die-not-implemented stub handle_content_merge() function
 + merge-ort: add function grouping comments
 + merge-ort: add a paths_to_free field to merge_options_internal
 + merge-ort: add a path_conflict field to merge_options_internal
 + merge-ort: add a clear_internal_opts helper
 + merge-ort: add a few includes
 (this branch is used by en/merge-ort-3, en/merge-ort-recursive and en/ort-conflict-handling; uses en/merge-ort-impl.)

 More "ORT" merge strategy.


* en/merge-ort-impl (2020-12-13) 21 commits
  (merged to 'next' on 2020-12-21 at c551d7bda9)
 + merge-ort: free data structures in merge_finalize()
 + merge-ort: add implementation of record_conflicted_index_entries()
 + tree: enable cmp_cache_name_compare() to be used elsewhere
 + merge-ort: add implementation of checkout()
 + merge-ort: basic outline for merge_switch_to_result()
 + merge-ort: step 3 of tree writing -- handling subdirectories as we go
 + merge-ort: step 2 of tree writing -- function to create tree object
 + merge-ort: step 1 of tree writing -- record basenames, modes, and oids
 + merge-ort: have process_entries operate in a defined order
 + merge-ort: add a preliminary simple process_entries() implementation
 + merge-ort: avoid recursing into identical trees
 + merge-ort: record stage and auxiliary info for every path
 + merge-ort: compute a few more useful fields for collect_merge_info
 + merge-ort: avoid repeating fill_tree_descriptor() on the same tree
 + merge-ort: implement a very basic collect_merge_info()
 + merge-ort: add an err() function similar to one from merge-recursive
 + merge-ort: use histogram diff
 + merge-ort: port merge_start() from merge-recursive
 + merge-ort: add some high-level algorithm structure
 + merge-ort: setup basic internal data structures
 + Merge branch 'en/strmap' into en/merge-ort-impl
 (this branch is used by en/merge-ort-2, en/merge-ort-3, en/merge-ort-recursive and en/ort-conflict-handling.)

 The merge backend "done right" starts to emerge.


* en/merge-ort-recursive (2020-12-16) 4 commits
  (merged to 'next' on 2020-12-22 at 0dbf60011f)
 + merge-ort: implement merge_incore_recursive()
 + merge-ort: make clear_internal_opts() aware of partial clearing
 + merge-ort: copy a few small helper functions from merge-recursive.c
 + commit: move reverse_commit_list() from merge-recursive
 (this branch uses en/merge-ort-2 and en/merge-ort-impl; is tangled with en/merge-ort-3 and en/ort-conflict-handling.)

 The ORT merge strategy learned to synthesize virtual ancestor tree
 by recursively merging multiple merge bases together, just like the
 recursive backend has done for years.


* es/perf-export-fix (2020-12-22) 1 commit
  (merged to 'next' on 2020-12-22 at d06b0379d9)
 + t/perf: avoid unnecessary test_export() recursion

 Tweak unneeded recursion from a test framework helper function.


* es/worktree-repair-both-moved (2020-12-21) 1 commit
  (merged to 'next' on 2020-12-22 at 9eaae4f5c0)
 + worktree: teach `repair` to fix multi-directional breakage

 "git worktree repair" learned to deal with the case where both the
 repository and the worktree moved.


* fc/pull-merge-rebase (2020-12-15) 5 commits
  (merged to 'next' on 2020-12-21 at acce13e5c4)
 + pull: display default warning only when non-ff
 + pull: correct condition to trigger non-ff advice
 + pull: get rid of unnecessary global variable
 + pull: give the advice for choosing rebase/merge much later
 + pull: refactor fast-forward check

 When a user does not tell "git pull" to use rebase or merge, the
 command gives a loud message telling a user to choose between
 rebase or merge but creates a merge anyway, forcing users who would
 want to rebase to redo the operation.  Fix an early part of this
 problem by tightening the condition to give the message---there is
 no reason to stop or force the user to choose between rebase or
 merge if the history fast-forwards.


* fc/t6030-bisect-reset-removes-auxiliary-files (2020-12-21) 1 commit
  (merged to 'next' on 2020-12-22 at 2ab78ef1e1)
 + test: bisect-porcelain: fix location of files

 A 3-year old test that was not testing anything useful has been
 corrected.


* pk/subsub-fetch-fix-take-2 (2020-12-09) 1 commit
  (merged to 'next' on 2020-12-14 at ccc01a5f66)
 + submodules: fix of regression on fetching of non-init subsub-repo

 "git fetch --recurse-submodules" fix (second attempt).


* tb/pack-bitmap (2020-12-08) 24 commits
  (merged to 'next' on 2020-12-15 at 773268c2fb)
 + pack-bitmap-write: better reuse bitmaps
 + pack-bitmap-write: relax unique revwalk condition
 + pack-bitmap-write: use existing bitmaps
 + pack-bitmap: factor out 'add_commit_to_bitmap()'
 + pack-bitmap: factor out 'bitmap_for_commit()'
 + pack-bitmap-write: ignore BITMAP_FLAG_REUSE
 + pack-bitmap-write: build fewer intermediate bitmaps
 + pack-bitmap.c: check reads more aggressively when loading
 + pack-bitmap-write: rename children to reverse_edges
 + t5310: add branch-based checks
 + commit: implement commit_list_contains()
 + bitmap: implement bitmap_is_subset()
 + pack-bitmap-write: fill bitmap with commit history
 + pack-bitmap-write: pass ownership of intermediate bitmaps
 + pack-bitmap-write: reimplement bitmap writing
 + ewah: add bitmap_dup() function
 + ewah: implement bitmap_or()
 + ewah: make bitmap growth less aggressive
 + ewah: factor out bitmap growth
 + rev-list: die when --test-bitmap detects a mismatch
 + t5310: drop size of truncated ewah bitmap
 + pack-bitmap: bounds-check size of cache extension
 + pack-bitmap: fix header size check
 + ewah/ewah_bitmap.c: avoid open-coding ALLOC_GROW()

 Various improvements to the codepath that writes out pack bitmaps.

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

* ss/submodule-add-in-c (2020-12-15) 3 commits
 . t7400: add test to check 'submodule add' for tracked paths
 . submodule: port submodule subcommand 'add' from shell to C
 . dir: change the scope of function 'directory_exists_in_index()'

 "git submodule add" being rewritten in C.

 Expecting a reroll.
 The patches are split incorrectly; part of 1/3 belongs to 2/3
 cf. <nycvar.QRO.7.76.6.2012190104140.56@tvgsbejvaqbjf.bet>
 It seems to introduce a segfault on 'seen'.
 cf. <xmqqft3xflw7.fsf@gitster.c.googlers.com>


* mt/grep-sparse-checkout (2020-12-06) 10 commits
 - t7817: do not depend on any specific default branch name
 - config: add setting to ignore sparsity patterns in some cmds
 - grep: honor sparse checkout patterns
 - config: correctly read worktree configs in submodules
 - config: make do_git_config_sequence receive a 'struct repository'
 - t/helper/test-config: unify exit labels
 - t/helper/test-config: diagnose missing arguments
 - t/helper/test-config: be consistent with exit codes
 - t1308-config-set: avoid false positives when using test-config
 - doc: grep: unify info on configuration variables
 (this branch is used by mt/rm-sparse-checkout.)

 "git grep" has been tweaked to be limited to the sparse checkout
 paths.

 Break out and fast-track bugfix from the remainder of the topic.
 cf. <CABPp-BFkACtF6LHkFJNt9dTOmwfQbf8ZO=BTrPYwPSmbqc9+hg@mail.gmail.com>


* mt/rm-sparse-checkout (2020-12-08) 1 commit
 - rm: honor sparse checkout patterns
 (this branch uses mt/grep-sparse-checkout.)

 "git rm" follows suit to "git grep" to ignore paths outside the
 sparsity pattern when the sparse checkout feature is in use.

 Need to wait for how these fit in larger picture.
 cf. <CABPp-BGMX3wb7LiS1HkJpGveoW3J1oR0vVHbKTF5+qYLRF+59g@mail.gmail.com>
 cf. <CABPp-BFkACtF6LHkFJNt9dTOmwfQbf8ZO=BTrPYwPSmbqc9+hg@mail.gmail.com>


* jk/symlinked-dotgitx-files (2020-10-23) 9 commits
 - docs: document symlink restrictions for .git* files
 - fsck: complain when .gitattributes or .gitignore is a symlink
 - verify_path(): disallow symlinks in .gitattributes and .gitignore
 - t0060: test obscured .gitattributes and .gitignore matching
 - t7450: test .gitmodules symlink matching against obscured names
 - t7450: test verify_path() handling of gitmodules
 - t7415: rename to expand scope
 - fsck_tree(): wrap some long lines
 - fsck_tree(): fix shadowed variable

 "git fsck" and the corresponding check done during the transport
 learned to ensure that in-tree files like `.gitignore` and
 `.gitattributes` are not symbolic links.

 It seems that there are real projects with .gitignore recorded as
 symlinks, which may need to loosen the fsck setting.  Do we need to
 introduce a class that is separate from symlinked .gitmodules that
 has potential consequences that is more/less grave, so that these
 projects can opt out of the new checks?


* sm/curl-retry (2020-10-13) 3 commits
 - http: automatically retry some requests
 - replace CURLOPT_FILE With CURLOPT_WRITEDATA
 - remote-curl: add testing for intelligent retry for HTTP

 The http transport has been taught to retry a failed request that
 may reasonably be retried.

 Expecting a reroll.
 cf. <20201015000410.GB328643@google.com>
 cf. <CAM4o00eefXK2CJ_FxwwVPpBKL01JsJANf+SdjCtw_0NVV82L+Q@mail.gmail.com>


* sv/t7001-modernize (2020-09-25) 11 commits
 - t7001: move cleanup code from outside the tests into them
 - t7001: use `test` rather than `[`
 - t7001: use here-docs instead of echo
 - t7001: put each command on a separate line
 - t7001: use ': >' rather than 'touch'
 - t7001: change (cd <path> && git foo) to (git -C <path> foo)
 - t7001: remove whitespace after redirect operators
 - t7001: change the style for cd according to subshell
 - t7001: remove unnecessary blank lines
 - t7001: use TAB instead of spaces
 - t7001: convert tests from the old style to the current style

 Test script modernization.

 Expecting a reroll.
 cf. <20200925170256.11490-1-shubhunic@gmail.com>


* ar/fetch-transfer-ipversion (2020-09-16) 1 commit
 - config: option transfer.ipversion to set transport protocol version for network fetches

 Adds transfer.ipversion configuration variable.

 Needs more work.


* jc/war-on-dashed-git (2020-12-21) 2 commits
 - fixup??? git: catch an attempt to run "git-foo"
 - git: catch an attempt to run "git-foo"

 The first step to remove on-disk binaries for built-in subcommands
 by soliciting objections.

 On hold for now.


* mk/use-size-t-in-zlib (2018-10-15) 1 commit
 - zlib.c: use size_t for size

 The wrapper to call into zlib followed our long tradition to use
 "unsigned long" for sizes of regions in memory, which have been
 updated to use "size_t".


* ag/merge-strategies-in-c (2020-11-24) 13 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-index: don't fork if the requested program is `git-merge-one-file'
 - merge-index: libify merge_one_path() and merge_all()
 - merge-one-file: rewrite in C
 - update-index: move add_cacheinfo() to read-cache.c
 - 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.

 Got enough review comments to get updated.

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

* vv/send-email-with-less-secure-apps-access (2021-01-07) 1 commit
 - git-send-email.txt: mention less secure app access with Gmail

 Doc update.

 Will merge to 'next'.


* ab/branch-sort (2021-01-07) 7 commits
 - branch: show "HEAD detached" first under reverse sort
 - branch: sort detached HEAD based on a flag
 - ref-filter: move ref_sorting flags to a bitfield
 - ref-filter: move "cmp_fn" assignment into "else if" arm
 - ref-filter: add braces to if/else if/else chain
 - branch tests: add to --sort tests
 - branch: change "--local" to "--list" in comment

 The implementation of "git branch --sort" wrt the detached HEAD
 display has always been hacky, which has been cleaned up.

 Will merge to 'next'.


* ab/coc-update-to-2.0 (2021-01-07) 3 commits
 - CoC: update to version 2.0 + local changes
 - CoC: explicitly take any whitespace breakage
 - CoC: Update word-wrapping to match upstream

 Update the Code-of-conduct to version 2.0 from the upstream (we've
 been using version 1.4).

 The first step needs to be signed off by the author, and like the
 original discussion thread back in Sep 2019, it also needs to
 collect acks from list regulars to show support.


* ar/t6016-modernise (2021-01-04) 1 commit
  (merged to 'next' on 2021-01-08 at 45f1b43e88)
 + t6016: move to lib-log-graph.sh framework

 Test update.

 Will merge to 'master'.


* dl/reflog-with-single-entry (2021-01-07) 2 commits
 - refs: allow @{n} to work with n-sized reflog
 - refs: factor out set_read_ref_cutoffs()

 After expiring a reflog and making a single commit, the reflog for
 the branch would record a single entry that knows both @{0} and
 @{1}, but we failed to answer "what commit were we on?", i.e. @{1}


* ds/cache-tree-basics (2021-01-07) 10 commits
 - cache-tree: speed up consecutive path comparisons
 - cache-tree: use ce_namelen() instead of strlen()
 - index-format: discuss recursion of cached-tree better
 - index-format: update preamble to cache tree extension
 - index-format: use 'cache tree' over 'cached tree'
 - cache-tree: trace regions for prime_cache_tree
 - cache-tree: trace regions for I/O
 - cache-tree: use trace2 in cache_tree_update()
 - unpack-trees: add trace2 regions
 - tree-walk: report recursion counts

 Document, clean-up and optimize the code around the cache-tree
 extension in the index.


* ds/for-each-repo-noopfix (2021-01-07) 1 commit
 - for-each-repo: do nothing on empty config

 "git for-each-repo --config=<var> <cmd>" should not run <cmd> for
 any repository when the configuration variable <var> is not defined
 even once.

 Will merge to 'next'.


* ds/trace2-topo-walk (2021-01-04) 1 commit
  (merged to 'next' on 2021-01-08 at 794c8f37ee)
 + revision: trace topo-walk statistics

 The topological walk codepath is covered by new trace2 stats.

 Will merge to 'master'.


* en/ort-conflict-handling (2021-01-04) 10 commits
 - merge-ort: add handling for different types of files at same path
 - merge-ort: copy find_first_merges() implementation from merge-recursive.c
 - merge-ort: implement format_commit()
 - merge-ort: copy and adapt merge_submodule() from merge-recursive.c
 - merge-ort: copy and adapt merge_3way() from merge-recursive.c
 - merge-ort: flesh out implementation of handle_content_merge()
 - merge-ort: handle book-keeping around two- and three-way content merge
 - merge-ort: implement unique_path() helper
 - merge-ort: handle directory/file conflicts that remain
 - merge-ort: handle D/F conflict where directory disappears due to merge

 ORT merge strategy learns more support for merge conflicts.


* fc/completion-aliases-support (2021-01-04) 4 commits
  (merged to 'next' on 2021-01-08 at b2714ff1a4)
 + completion: add proper public __git_complete
 + test: completion: add tests for __git_complete
 + completion: bash: improve function detection
 + completion: bash: add __git_have_func helper

 Bash completion (in contrib/) update to make it easier for
 end-users to add completion for their custom "git" subcommands.

 Will merge to 'master'.


* ma/doc-pack-format-varint-for-sizes (2021-01-04) 1 commit
  (merged to 'next' on 2021-01-08 at 8a448c50dd)
 + pack-format.txt: document sizes at start of delta data

 Doc update.

 Will merge to 'master'.


* ma/more-opaque-lock-file (2021-01-06) 5 commits
 - read-cache: try not to peek into `struct {lock_,temp}file`
 - refs/files-backend: don't peek into `struct lock_file`
 - midx: don't peek into `struct lock_file`
 - commit-graph: don't peek into `struct lock_file`
 - builtin/gc: don't peek into `struct lock_file`

 Code clean-up.

 Will merge to 'next'.


* ma/sha1-is-a-hash (2021-01-04) 4 commits
  (merged to 'next' on 2021-01-08 at a25537f7c3)
 + hash-lookup: rename from sha1-lookup
 + sha1-lookup: rename `sha1_pos()` as `hash_pos()`
 + object-file.c: rename from sha1-file.c
 + object-name.c: rename from sha1-name.c

 Retire more names with "sha1" in it.

 Will merge to 'master'.


* ma/t1300-cleanup (2021-01-04) 3 commits
  (merged to 'next' on 2021-01-08 at 51aaae39a1)
 + t1300: don't needlessly work with `core.foo` configs
 + t1300: remove duplicate test for `--file no-such-file`
 + t1300: remove duplicate test for `--file ../foo`

 Code clean-up.

 Will merge to 'master'.


* mt/t4129-with-setgid-dir (2021-01-06) 1 commit
 - t4129: don't fail if setgid is set in the test directory

 Some tests expect that "ls -l" output has either '-' or 'x' for
 group executable bit, but setgid bit can be inherited from parent
 directory and make these fields 'S' or 's' instead, causing test
 failures.

 Will merge to 'next'.


* nk/perf-fsmonitor-cleanup (2021-01-06) 1 commit
  (merged to 'next' on 2021-01-08 at 1837d6c30b)
 + p7519: allow running without watchman prereq

 Test fix.

 Will merge to 'master'.


* pb/doc-modules-git-work-tree-typofix (2021-01-04) 1 commit
  (merged to 'next' on 2021-01-08 at a67ab3e96a)
 + gitmodules.txt: fix 'GIT_WORK_TREE' variable name

 Doc fix.

 Will merge to 'master'.


* pb/mergetool-tool-help-fix (2021-01-06) 1 commit
 - mergetool--lib: fix '--tool-help' to correctly show available tools

 Fix 2.29 regression where "git mergetool --tool-help" fails to list
 all the available tools.

 Will merge to 'next'.


* rs/rebase-commit-validation (2021-01-04) 1 commit
  (merged to 'next' on 2021-01-08 at 2c63eb1cc8)
 + rebase: verify commit parameter

 Diagnose command line error early.

 Will merge to 'master'.


* sg/t7800-difftool-robustify (2021-01-04) 1 commit
 . t7800-difftool: don't accidentally match tmp dirs

 Test fix.

 Not working on Windows.
 cf. https://github.com/git/git/runs/1660588243?check_suite_focus=true#step:7:4186


* ta/doc-typofix (2021-01-04) 1 commit
  (merged to 'next' on 2021-01-08 at 1e579ef94f)
 + doc: fix some typos

 Doc fix.

 Will merge to 'master'.


* zh/arg-help-format (2021-01-06) 2 commits
  (merged to 'next' on 2021-01-08 at 208c98620c)
 + builtin/*: update usage format
 + parse-options: format argh like error messages

 Clean up option descriptions in "git cmd --help".

 Will merge to 'master'.


* ak/corrected-commit-date (2021-01-04) 11 commits
 - doc: add corrected commit date info
 - commit-reach: use corrected commit dates in paint_down_to_common()
 - commit-graph: use generation v2 only if entire chain does
 - commit-graph: implement generation data chunk
 - commit-graph: implement corrected commit date
 - commit-graph: return 64-bit generation number
 - commit-graph: add a slab to store topological levels
 - t6600-test-reach: generalize *_three_modes
 - commit-graph: consolidate fill_commit_graph_info
 - revision: parse parent in indegree_walk_step()
 - commit-graph: fix regression when computing Bloom filters

 The commit-graph learned to use corrected commit dates instead of
 the generation number to help topological revision traversal.

 Getting there, but not needs more help to find and resolve segv.
 cf. <1adabda6-b80b-d543-f6c0-570dadbe589b@gmail.com>


* dl/p4-encode-after-kw-expansion (2020-12-23) 1 commit
 - git-p4: fix syncing file types with pattern

 Text encoding fix for "git p4".


* fc/mergetool-automerge (2021-01-06) 5 commits
 . mergetool: add automerge_enabled tool-specific override function
 . mergetool: break setup_tool out into separate initialization function
 . mergetool: add per-tool support for the autoMerge flag
 . mergetool: alphabetize the mergetool config docs
 . mergetool: add automerge configuration

 "git mergetool" feeds three versions (base, local and remote) of
 a conflicted path unmodified.  The command learned to optionally
 prepare these files with unconflicted parts already resolved.

 Breaks tests on macOS.
 cf. https://github.com/git/git/runs/1659807735?check_suite_focus=true#step:4:1641


* ew/decline-core-abbrev (2020-12-23) 1 commit
  (merged to 'next' on 2021-01-08 at 630dd186a4)
 + core.abbrev=no disables abbreviations

 Allow the configuration to specify no abbreviation regardless of
 the hash algorithm.

 Will merge to 'master'.


* mr/bisect-in-c-4 (2020-12-21) 7 commits
 - bisect--helper: retire `--check-and-set-terms` subcommand
 - bisect--helper: reimplement `bisect_skip` shell function in C
 - bisect--helper: retire `--bisect-auto-next` subcommand
 - bisect--helper: use `res` instead of return in BISECT_RESET case option
 - bisect--helper: retire `--bisect-write` subcommand
 - bisect--helper: reimplement `bisect_replay` shell function in C
 - bisect--helper: reimplement `bisect_log` shell function in C

 Piecemeal of rewrite of "git bisect" in C continues.

 What's the status of this thing?


* jt/clone-unborn-head (2020-12-22) 3 commits
 - clone: respect remote unborn HEAD
 - connect, transport: add no-op arg for future patch
 - ls-refs: report unborn targets of symrefs

 "git clone" tries to locally check out the branch pointed at by
 HEAD of the remote repository after it is done, but the protocol
 did not convey the information necessary to do so when copying an
 empty repository.  The protocol v2 learned how to do so.

 What's the status of this thing?


* fc/bash-completion-post-2.29 (2020-12-23) 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.*

 Seems to break tests on Windows


* jc/deprecate-pack-redundant (2020-12-15) 1 commit
 - pack-redundant: gauge the usage before proposing its removal

 Warn loudly when the "pack-redundant" command, which has been left
 stale with almost unusable performance issues, gets used, as we no
 longer want to recommend its use (instead just "repack -d" instead).

 Will merge to 'next'.


* mt/parallel-checkout-part-1 (2020-12-16) 9 commits
 - entry: add checkout_entry_ca() taking preloaded conv_attrs
 - entry: move conv_attrs lookup up to checkout_entry()
 - entry: extract update_ce_after_write() from write_entry()
 - entry: make fstat_output() and read_blob_entry() public
 - entry: extract a header file for entry.c functions
 - convert: add classification for conv_attrs struct
 - convert: add get_stream_filter_ca() variant
 - convert: add [async_]convert_to_working_tree_ca() variants
 - convert: make convert_attrs() and convert structs public

 Parallel checkout.

 Looking good.


* en/merge-ort-3 (2020-12-15) 11 commits
  (merged to 'next' on 2021-01-08 at fe481b9627)
 + merge-ort: add implementation of type-changed rename handling
 + merge-ort: add implementation of normal rename handling
 + merge-ort: add implementation of rename collisions
 + merge-ort: add implementation of rename/delete conflicts
 + merge-ort: add implementation of both sides renaming differently
 + merge-ort: add implementation of both sides renaming identically
 + merge-ort: add basic outline for process_renames()
 + merge-ort: implement compare_pairs() and collect_renames()
 + merge-ort: implement detect_regular_renames()
 + merge-ort: add initial outline for basic rename detection
 + merge-ort: add basic data structures for handling renames
 (this branch is used by en/ort-directory-rename.)

 Rename detection is added to the "ORT" merge strategy.

 Will merge to 'master'.


* ps/config-env-pairs (2021-01-06) 8 commits
 - config: allow specifying config entries via envvar pairs
 - environment: make `getenv_safe()` a public function
 - config: parse more robust format in GIT_CONFIG_PARAMETERS
 - config: store "git -c" variables using more robust format
 - config: extract function to parse config pairs
 - quote: make sq_dequote_step() a public function
 - config: add new way to pass config via `--config-env`
 - git: add `--super-prefix` to usage string

 Introduce two new ways to feed configuration variable-value pairs
 via environment variables, and tweak the way GIT_CONFIG_PARAMETERS
 encodes variable/value pairs to make it more robust.

 Ready for 'next'?


* bc/hashed-mailmap (2020-12-12) 1 commit
 - mailmap: support hashed entries in mailmaps

 The mailmap database learned to take hashed value as the original
 side of mapping.

 Expecting a reroll.


* so/log-diff-merge (2020-12-21) 32 commits
 - t4013: add tests for --diff-merges=first-parent
 - doc/git-show: include --diff-merges description
 - doc/rev-list-options: document --first-parent changes merges format
 - doc/diff-generate-patch: mention new --diff-merges option
 - doc/git-log: describe new --diff-merges options
 - diff-merges: add '--diff-merges=1' as synonym for 'first-parent'
 - diff-merges: add old mnemonic counterparts to --diff-merges
 - diff-merges: let new options enable diff without -p
 - diff-merges: do not imply -p for new options
 - diff-merges: implement new values for --diff-merges
 - diff-merges: make -m/-c/--cc explicitly mutually exclusive
 - diff-merges: refactor opt settings into separate functions
 - diff-merges: get rid of now empty diff_merges_init_revs()
 - diff-merges: group diff-merge flags next to each other inside 'rev_info'
 - diff-merges: split 'ignore_merges' field
 - diff-merges: fix -m to properly override -c/--cc
 - t4013: add tests for -m failing to override -c/--cc
 - t4013: support test_expect_failure through ':failure' magic
 - diff-merges: revise revs->diff flag handling
 - diff-merges: handle imply -p on -c/--cc logic for log.c
 - diff-merges: introduce revs->first_parent_merges flag
 - diff-merges: new function diff_merges_set_dense_combined_if_unset()
 - diff-merges: new function diff_merges_suppress()
 - diff-merges: re-arrange functions to match the order they are called in
 - diff-merges: rename diff_merges_default_to_enable() to match semantics
 - diff-merges: move checks for first_parent_only out of the module
 - diff-merges: rename all functions to have common prefix
 - revision: move diff merges functions to its own diff-merges.c
 - revision: provide implementation for diff merges tweaks
 - revision: factor out initialization of diff-merge related settings
 - revision: factor out setup of diff-merge related settings
 - revision: factor out parsing of diff-merge related options

 "git log" learned a new "--diff-merges=<how>" option.

 Rerolled.


* bc/rev-parse-path-format (2020-12-12) 2 commits
  (merged to 'next' on 2021-01-08 at 7d51587b7f)
 + rev-parse: add option for absolute or relative path formatting
 + abspath: add a function to resolve paths with missing components

 "git rev-parse" can be explicitly told to give output as absolute
 or relative path.

 Will merge to 'master'.


* es/config-hooks (2020-12-21) 34 commits
 - run-command: stop thinking about hooks
 - 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: replace find_hook() with hook_exists()
 - hook: add 'run' subcommand
 - parse-options: parse into strvec
 - hook: implement hookcmd.<name>.skip
 - hook: respect hook.runHookDir
 - hook: include hookdir hook in list
 - hook: add list command
 - hook: scaffolding for git-hook subcommand
 - doc: propose hooks managed by the config

 The "hooks defined in config" topic.

 Expecting doc updates, but otherwise seems to be progressing nicely.


* hn/reftable (2020-12-21) 16 commits
 - SQUASH??? allow t0031 to run with any default branch name
 - Add "test-tool dump-reftable" command.
 - git-prompt: prepare for reftable refs backend
 - Reftable support for git-core
 - reftable: rest of library
 - reftable: reftable file level tests
 - reftable: read reftable files
 - reftable: write reftable files
 - reftable: a generic binary tree implementation
 - reftable: reading/writing blocks
 - 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

 The "reftable" backend for the refs API.


* ab/mktag (2021-01-06) 23 commits
  (merged to 'next' on 2021-01-08 at 6f9e11ad97)
 + mktag: add a --[no-]strict option
 + mktag: mark strings for translation
 + mktag: convert to parse-options
 + mktag: allow omitting the header/body \n separator
 + mktag: allow turning off fsck.extraHeaderEntry
 + fsck: make fsck_config() re-usable
 + mktag: use fsck instead of custom verify_tag()
 + mktag: use puts(str) instead of printf("%s\n", str)
 + mktag: remove redundant braces in one-line body "if"
 + mktag: use default strbuf_read() hint
 + mktag tests: test verify_object() with replaced objects
 + mktag tests: improve verify_object() test coverage
 + mktag tests: test "hash-object" compatibility
 + mktag tests: stress test whitespace handling
 + mktag tests: run "fsck" after creating "mytag"
 + mktag tests: don't create "mytag" twice
 + mktag tests: don't redirect stderr to a file needlessly
 + mktag tests: remove needless SHA-1 hardcoding
 + mktag tests: use "test_commit" helper
 + mktag tests: don't needlessly use a subshell
 + mktag doc: update to explain why to use this
 + mktag doc: grammar fix, when exists -> when it exists
 + mktag doc: say <hash> not <sha1>

 "git mktag" validates its input using its own rules before writing
 a tag object---it has been updated to share the logic with "git
 fsck".

 Will merge to 'master'.


* en/diffcore-rename (2021-01-04) 9 commits
 - diffcore-rename: remove unnecessary duplicate entry checks
 - diffcore-rename: accelerate rename_dst setup
 - diffcore-rename: simplify and accelerate register_rename_src()
 - t4058: explore duplicate tree entry handling in a bit more detail
 - t4058: add more tests and documentation for duplicate tree entry handling
 - diffcore-rename: reduce jumpiness in progress counters
 - diffcore-rename: simplify limit check
 - diffcore-rename: avoid usage of global in too_many_rename_candidates()
 - diffcore-rename: rename num_create to num_destinations

 File-level rename detection updates.

 Will merge to 'next'.


* en/stash-apply-sparse-checkout (2020-12-01) 3 commits
  (merged to 'next' on 2021-01-08 at cae5b73d99)
 + stash: fix stash application in sparse-checkouts
 + stash: remove unnecessary process forking
 + t7012: add a testcase demonstrating stash apply bugs in sparse checkouts

 "git stash" did not work well in a sparsely checked out working
 tree.

 Will merge to 'master'.


* js/default-branch-name-tests-final-stretch (2020-11-19) 29 commits
 - tests: drop prereq `PREPARE_FOR_MAIN_BRANCH` where no longer needed
 - t99*: adjust the references to the default branch name "main"
 - tests(git-p4): transition to the default branch name `main`
 - t9[5-7]*: adjust the references to the default branch name "main"
 - t9[0-4]*: adjust the references to the default branch name "main"
 - t8*: adjust the references to the default branch name "main"
 - t7[5-9]*: adjust the references to the default branch name "main"
 - t7[0-4]*: adjust the references to the default branch name "main"
 - t6[4-9]*: adjust the references to the default branch name "main"
 - t64*: preemptively adjust alignment to prepare for `master` -> `main`
 - t6[0-3]*: adjust the references to the default branch name "main"
 - t5[6-9]*: adjust the references to the default branch name "main"
 - t55[4-9]*: adjust the references to the default branch name "main"
 - t55[23]*: adjust the references to the default branch name "main"
 - t551*: adjust the references to the default branch name "main"
 - t550*: adjust the references to the default branch name "main"
 - t5503: prepare aligned comment for replacing `master` with `main`
 - t5[0-4]*: adjust the references to the default branch name "main"
 - t5323: prepare centered comment for `master` -> `main`
 - t4*: adjust the references to the default branch name "main"
 - t3[5-9]*: adjust the references to the default branch name "main"
 - t34*: adjust the references to the default branch name "main"
 - t3416: preemptively adjust alignment in a comment
 - t3[0-3]*: adjust the references to the default branch name "main"
 - t2*: adjust the references to the default branch name "main"
 - t[01]*: adjust the references to the default branch name "main"
 - t0060: preemptively adjust alignment
 - tests: mark tests relying on the current default for `init.defaultBranch`
 - Merge 'jk/diff-release-filespec-fix' into js/default-branch-name-tests-final-stretch

 Prepare tests not to be affected by the name of the default branch
 "git init" creates.

 Will merge to 'next'.


* ds/maintenance-part-4 (2021-01-05) 4 commits
  (merged to 'next' on 2021-01-08 at 1f98c859ea)
 + maintenance: use Windows scheduled tasks
 + maintenance: use launchctl on macOS
 + maintenance: include 'cron' details in docs
 + maintenance: extract platform-specific scheduling

 Follow-up on the "maintenance part-3" which introduced scheduled
 maintenance tasks to support platforms whose native scheduling
 methods are not 'cron'.

 Will merge to 'master'.


* sj/untracked-files-in-submodule-directory-is-not-dirty (2020-12-08) 1 commit
 - diff: do not show submodule with untracked files as "-dirty"

 "git diff" showed a submodule working tree with untracked cruft as
 "Submodule commit <objectname>-dirty", but a natural expectation is
 that the "-dirty" indicator would align with "git describe --dirty",
 which does not consider having untracked files in the working tree
 as source of dirtiness.  The inconsistency has been fixed.

 Will merge to 'next'.

--------------------------------------------------
[Discarded]

* jc/config-pretend-gitdir (2020-12-15) 1 commit
 . config: --pretend-git-dir for includeIf:gitdir

 It turns out that the original "problem" that inspired the feature
 was working as designed.
 cf. <CAPQE4+rhWT9kgusNXOw5cnJ-oFq++4G1FMaXvQ3wppQ0GE0hSA@mail.gmail.com>

Re: What's cooking in git.git (Jan 2021, #02; Fri, 8)

[Ævar Arnfjörð Bjarmason]

On Fri, Jan 08 2021, Junio C Hamano wrote:

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

As an aside thanks for following-up on adding the git-vcs/git URL. I
don't think I responded to a question in that E-Mail chain about whether
this repo only has your branches (and not some random topic branches of
mine or whatever). That's the case, it's a strict mirror of your
push-outs.

> * ab/trailers-extra-format (2020-12-09) 5 commits
>   (merged to 'next' on 2020-12-14 at 9fc731944e)
>  + pretty format %(trailers): add a "key_value_separator"
>  + pretty format %(trailers): add a "keyonly"
>  + pretty-format %(trailers): fix broken standalone "valueonly"
>  + pretty format %(trailers) doc: avoid repetition
>  + pretty format %(trailers) test: split a long line
>
>  The "--format=%(trailers)" mechanism gets enhanced to make it
>  easier to design output for machine consumption.

Thanks! Am refactoring some out-of-tree code to take advantage of this
:)

I forgot that, oops. Is just declaring here that all of that's:

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>

Since you have some acks etc. squashed into it at this point...

> * bc/hashed-mailmap (2020-12-12) 1 commit
>  - mailmap: support hashed entries in mailmaps
>
>  The mailmap database learned to take hashed value as the original
>  side of mapping.
>
>  Expecting a reroll.

FWIW there was since a re-roll on 2021-01-03, but the discussion is
sort-of outstanding, so maybe that's intentional...

> * ab/mktag (2021-01-06) 23 commits
>   (merged to 'next' on 2021-01-08 at 6f9e11ad97)
>  + mktag: add a --[no-]strict option
>  + mktag: mark strings for translation
>  + mktag: convert to parse-options
>  + mktag: allow omitting the header/body \n separator
>  + mktag: allow turning off fsck.extraHeaderEntry
>  + fsck: make fsck_config() re-usable
>  + mktag: use fsck instead of custom verify_tag()
>  + mktag: use puts(str) instead of printf("%s\n", str)
>  + mktag: remove redundant braces in one-line body "if"
>  + mktag: use default strbuf_read() hint
>  + mktag tests: test verify_object() with replaced objects
>  + mktag tests: improve verify_object() test coverage
>  + mktag tests: test "hash-object" compatibility
>  + mktag tests: stress test whitespace handling
>  + mktag tests: run "fsck" after creating "mytag"
>  + mktag tests: don't create "mytag" twice
>  + mktag tests: don't redirect stderr to a file needlessly
>  + mktag tests: remove needless SHA-1 hardcoding
>  + mktag tests: use "test_commit" helper
>  + mktag tests: don't needlessly use a subshell
>  + mktag doc: update to explain why to use this
>  + mktag doc: grammar fix, when exists -> when it exists
>  + mktag doc: say <hash> not <sha1>
>
>  "git mktag" validates its input using its own rules before writing
>  a tag object---it has been updated to share the logic with "git
>  fsck".
>
>  Will merge to 'master'.

Thanks. I've got some more local fsck-y fixes I'm hoping to submit soon.

Re: What's cooking in git.git (Jan 2021, #02; Fri, 8)

[Junio C Hamano]

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

>> * ab/trailers-extra-format (2020-12-09) 5 commits
>>  ...
>>
>>  The "--format=%(trailers)" mechanism gets enhanced to make it
>>  easier to design output for machine consumption.
>
> Thanks! Am refactoring some out-of-tree code to take advantage of this
> :)

Thank you for interesting additions.

> I forgot that, oops. Is just declaring here that all of that's:
>
> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
>
> Since you have some acks etc. squashed into it at this point...

Puzzlled.  The patches on the trailers topic were all signed-off by
you, unless I was careless when I checked before merging them to
'next'.

Do the above three lines refer to a different topic, on CoC 2.0?


>> * bc/hashed-mailmap (2020-12-12) 1 commit
>>  - mailmap: support hashed entries in mailmaps
>>
>>  The mailmap database learned to take hashed value as the original
>>  side of mapping.
>>
>>  Expecting a reroll.
>
> FWIW there was since a re-roll on 2021-01-03, but the discussion is
> sort-of outstanding, so maybe that's intentional...

I had an impression that those 4 or 5 patches haven't gained
concensus that they are good as-is.

Thanks.

Re: What's cooking in git.git (Jan 2021, #02; Fri, 8)

[David Aguilar]

On Fri, Jan 8, 2021 at 11:28 AM Junio C Hamano <gitster@pobox.com> wrote:
>
> * fc/mergetool-automerge (2021-01-06) 5 commits
>  . mergetool: add automerge_enabled tool-specific override function
>  . mergetool: break setup_tool out into separate initialization function
>  . mergetool: add per-tool support for the autoMerge flag
>  . mergetool: alphabetize the mergetool config docs
>  . mergetool: add automerge configuration
>
>  "git mergetool" feeds three versions (base, local and remote) of
>  a conflicted path unmodified.  The command learned to optionally
>  prepare these files with unconflicted parts already resolved.
>
>  Breaks tests on macOS.
>  cf. https://github.com/git/git/runs/1659807735?check_suite_focus=true#step:4:1641


Thank you for seeing these changes through.  It's so close now!

I did some investigation into this issue and narrowed down the root cause.

Here is an example input file called "tiger" for testing the sed
invocations in auto_merge():

$ cat tiger
<<<<<<< HEAD
branch1 both added
=======
tiger both added
>>>>>>> tiger

There are two sed invocations that use \r\? to maybe-match \r for crlf support.
\r\? is not portable to macOS (and freebsd?) sed.

For example, auto_merge() does the equivalent of this in one of the invocations:

    sed -e '/^<<<<<<< /,/^=======\r\?$/d' -e '/^>>>>>>> /d' tiger

It prints nothing on macOS.  "gsed" (gnu-sed) from homebrew prints
"tiger both added". This may affect other unix flavors where sed is
not gnu as well.

To verify I changed the sed invocations in auto_merge() to use gsed
and it's then able to pass the tests.

Fun times in sed portability land.  After a bit of experimentation,
this is what I've managed to whip up:

cr=$(printf '\x0d')
sed -e "/^<<<<<<< /,/^=======$cr\{0,1\}$/d" -e '/^>>>>>>> /d' tiger

- Instead of \r use printf to capture CR into a string so that we can
embed the literal using $cr.
- DQ "..." instead of SQ '...' to allow $cr to be substituted in the string.
- Instead of \? use \{0,1\} which seems to work on both macOS and Linux.

That seems to work and the tests now pass.
If not sed, is there perhaps a perl equivalent for these multi-line
delete-from-X-until-Y expressions that might provide better
portability?

I'll start putting together a patch shortly as this seems to work in
practice.  Let me know if y'all have any sugs or if there are any
portability pitfalls I'm not considering.

cheers,

--
David

Re: What's cooking in git.git (Jan 2021, #02; Fri, 8)

[brian m. carlson]

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

On 2021-01-09 at 21:28:58, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
> > FWIW there was since a re-roll on 2021-01-03, but the discussion is
> > sort-of outstanding, so maybe that's intentional...
> 
> I had an impression that those 4 or 5 patches haven't gained
> concensus that they are good as-is.

There will be another reroll.  I'm hoping to get to it this weekend.
-- 
brian m. carlson (he/him or they/them)
Houston, Texas, US

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

Re: What's cooking in git.git (Jan 2021, #02; Fri, 8)

[Junio C Hamano]

David Aguilar <davvid@gmail.com> writes:

> Fun times in sed portability land.  After a bit of experimentation,
> this is what I've managed to whip up:
>
> cr=$(printf '\x0d')
> sed -e "/^<<<<<<< /,/^=======$cr\{0,1\}$/d" -e '/^>>>>>>> /d' tiger
>
> - Instead of \r use printf to capture CR into a string so that we can
> embed the literal using $cr.
> - DQ "..." instead of SQ '...' to allow $cr to be substituted in the string.
> - Instead of \? use \{0,1\} which seems to work on both macOS and Linux.

Ah, all the fun with avoiding GNU-ism in scripts; thanks for
figuring it out.

I am perfectly fine with the above, but I also am OK with Perl
script.  We may even be able to generate three output files in a
single pass by passing their filenames and open them for writing in
the script.

> That seems to work and the tests now pass.
> If not sed, is there perhaps a perl equivalent for these multi-line
> delete-from-X-until-Y expressions that might provide better
> portability?

> I'll start putting together a patch shortly as this seems to work in
> practice.  Let me know if y'all have any sugs or if there are any
> portability pitfalls I'm not considering.

Re: What's cooking in git.git (Jan 2021, #02; Fri, 8)

[Junio C Hamano]

"brian m. carlson" <sandals@crustytoothpaste.net> writes:

> On 2021-01-09 at 21:28:58, Junio C Hamano wrote:
>> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
>> > FWIW there was since a re-roll on 2021-01-03, but the discussion is
>> > sort-of outstanding, so maybe that's intentional...
>> 
>> I had an impression that those 4 or 5 patches haven't gained
>> concensus that they are good as-is.
>
> There will be another reroll.  I'm hoping to get to it this weekend.

Thanks.

Re: What's cooking in git.git (Jan 2021, #02; Fri, 8)

[Ævar Arnfjörð Bjarmason]

On Sat, Jan 09 2021, Junio C Hamano wrote:

> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
>> I forgot that, oops. Is just declaring here that all of that's:
>>
>> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
>>
>> Since you have some acks etc. squashed into it at this point...
>
> Puzzlled.  The patches on the trailers topic were all signed-off by
> you, unless I was careless when I checked before merging them to
> 'next'.
>
> Do the above three lines refer to a different topic, on CoC 2.0?

Yes, I accidentally snipped out the part I should have been quoting. I
meant "please assume my signed-off-by" to be in reply the CoC 2.0
series.

Re: What's cooking in git.git (Jan 2021, #02; Fri, 8)

[Junio C Hamano]

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

> On Sat, Jan 09 2021, Junio C Hamano wrote:
>
>> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
>>> I forgot that, oops. Is just declaring here that all of that's:
>>>
>>> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
>>>
>>> Since you have some acks etc. squashed into it at this point...
>>
>> Puzzlled.  The patches on the trailers topic were all signed-off by
>> you, unless I was careless when I checked before merging them to
>> 'next'.
>>
>> Do the above three lines refer to a different topic, on CoC 2.0?
>
> Yes, I accidentally snipped out the part I should have been quoting. I
> meant "please assume my signed-off-by" to be in reply the CoC 2.0
> series.

Thanks.  Will squash your sign-off in.

Re: What's cooking in git.git (Jan 2021, #02; Fri, 8)

[brian m. carlson]

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

On 2021-01-09 at 23:20:25, Junio C Hamano wrote:
> "brian m. carlson" <sandals@crustytoothpaste.net> writes:
> 
> > On 2021-01-09 at 21:28:58, Junio C Hamano wrote:
> >> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
> >> > FWIW there was since a re-roll on 2021-01-03, but the discussion is
> >> > sort-of outstanding, so maybe that's intentional...
> >> 
> >> I had an impression that those 4 or 5 patches haven't gained
> >> concensus that they are good as-is.
> >
> > There will be another reroll.  I'm hoping to get to it this weekend.
> 
> Thanks.

Having read Ævar's latest comment, I've decided instead to drop this, so
feel free to do so whenever it's convenient.
-- 
brian m. carlson (he/him or they/them)
Houston, Texas, US

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

Re: What's cooking in git.git (Jan 2021, #02; Fri, 8)

[Junio C Hamano]

"brian m. carlson" <sandals@crustytoothpaste.net> writes:

> On 2021-01-09 at 23:20:25, Junio C Hamano wrote:
>> "brian m. carlson" <sandals@crustytoothpaste.net> writes:
>> 
>> > On 2021-01-09 at 21:28:58, Junio C Hamano wrote:
>> >> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
>> >> > FWIW there was since a re-roll on 2021-01-03, but the discussion is
>> >> > sort-of outstanding, so maybe that's intentional...
>> >> 
>> >> I had an impression that those 4 or 5 patches haven't gained
>> >> concensus that they are good as-is.
>> >
>> > There will be another reroll.  I'm hoping to get to it this weekend.
>> 
>> Thanks.
>
> Having read Ævar's latest comment, I've decided instead to drop this, so
> feel free to do so whenever it's convenient.

That's kind of sad.

I view that this is the kind of topic where perfect easily can
become an enemy of good, as there is by definition no perfection
available to us without breaking existing Git.

I do not know about Ævar, but to me, my initial impression while
reading the discussion from sideline was that the goal was to
prevent a mechanical scan of a recent version of .mailmap from
learning that Joe used to use Jane as his/her name, and that was the
reason why I asked to be convinced why encoding for obfuscation was
insufficient.  In the above, I meant "mechanical scan" as something
like "a web search engine crawls and finds a .mailmap---a query for
Joe produces a line with some garbage on it that is not Jane." and a
casual attacker would stop there.

But of course, a casual attacker who knows urlencode or whatever
obfuscation in use can read that "garbage" once he/she knows that
"garbage" is worth attacking (i.e. it is known to be associated to
Joe, the person the attacker is interested in).

If your goal is to make it harder than just urlencode, even though
we all have to accept that scanning "git log --all" for all names
that appear in the history and hashing them all to see what name
hashes to the "garbage" in question, then @sha256:<hash> approach
does make sense as a stopping point.  Perhaps we need to sell this
with a clear definition of what kind of attackes we are protecting
the name data from:

    The attacker is required to obtain sufficient amount of history
    in the project to uncover the obfuscation; a more casual
    attackers will fail to uncover, and we declare that it is better
    than nothing and it is good enough in practice.

or something like that?  I am not sure if I drew the line at the
level you intended to draw in the above, if I think that it is good
enough in practice, or if I agree to a change that is better than
nothing but not good enough in practice, but having such a statement
would help to see where we agree or disagree.

Thanks.

Re: What's cooking in git.git (Jan 2021, #02; Fri, 8)

[Ævar Arnfjörð Bjarmason]

On Mon, Jan 11 2021, Junio C Hamano wrote:

> "brian m. carlson" <sandals@crustytoothpaste.net> writes:
>
>> On 2021-01-09 at 23:20:25, Junio C Hamano wrote:
>>> "brian m. carlson" <sandals@crustytoothpaste.net> writes:
>>> 
>>> > On 2021-01-09 at 21:28:58, Junio C Hamano wrote:
>>> >> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
>>> >> > FWIW there was since a re-roll on 2021-01-03, but the discussion is
>>> >> > sort-of outstanding, so maybe that's intentional...
>>> >> 
>>> >> I had an impression that those 4 or 5 patches haven't gained
>>> >> concensus that they are good as-is.
>>> >
>>> > There will be another reroll.  I'm hoping to get to it this weekend.
>>> 
>>> Thanks.
>>
>> Having read Ævar's latest comment, I've decided instead to drop this, so
>> feel free to do so whenever it's convenient.
>
> That's kind of sad.

Agreed. I mean, I'm just one contributor with an opinion. I certainly
don't mean my "meh" on a patch to be some sort of veto.

If you follow this list you'll see that if you're going to take anyone's
opinion on whether a thing should make it into git as a matter of
empirical data on patches I submit that aren't changed meaningfully,
then, uh, maybe pick someone else :)

> I view that this is the kind of topic where perfect easily can
> become an enemy of good, as there is by definition no perfection
> available to us without breaking existing Git.
>
> I do not know about Ævar, but to me, my initial impression while
> reading the discussion from sideline was that the goal was to
> prevent a mechanical scan of a recent version of .mailmap from
> learning that Joe used to use Jane as his/her name, and that was the
> reason why I asked to be convinced why encoding for obfuscation was
> insufficient.  In the above, I meant "mechanical scan" as something
> like "a web search engine crawls and finds a .mailmap---a query for
> Joe produces a line with some garbage on it that is not Jane." and a
> casual attacker would stop there.
>
> But of course, a casual attacker who knows urlencode or whatever
> obfuscation in use can read that "garbage" once he/she knows that
> "garbage" is worth attacking (i.e. it is known to be associated to
> Joe, the person the attacker is interested in).
>
> If your goal is to make it harder than just urlencode, even though
> we all have to accept that scanning "git log --all" for all names
> that appear in the history and hashing them all to see what name
> hashes to the "garbage" in question, then @sha256:<hash> approach
> does make sense as a stopping point.  Perhaps we need to sell this
> with a clear definition of what kind of attackes we are protecting
> the name data from:
>
>     The attacker is required to obtain sufficient amount of history
>     in the project to uncover the obfuscation; a more casual
>     attackers will fail to uncover, and we declare that it is better
>     than nothing and it is good enough in practice.
>
> or something like that?  I am not sure if I drew the line at the
> level you intended to draw in the above, if I think that it is good
> enough in practice, or if I agree to a change that is better than
> nothing but not good enough in practice, but having such a statement
> would help to see where we agree or disagree.

My reading of the general thread & brian's reply at [1] is that the
difference in the minds of the users who want the feature (who're not
on-list, and we're getting brian's's summary of their views) is closer
to:

    We want the X-Y problem of "hide this data" solved with solution "Y"
    because git's current tooling to retrieve the data is currently
    rather tedious & obscure.

So when I asked whether those users would feel the same if the tooling
was less tedious and suggested that I might patch it to be so brian
replied with "[yes,] we do rely on this being inconvenient".

I do have a 20-something series patch to the mailmap code in my local
queue that in the light of this series's status I think I'll submit
soon.

It doesn't have anything to do with adding a "spew out a materialized
map" feature currently, nor do I really plan to do that any time soon. I
do genuinely think it would be a good addition to git for reasons that
have nothing to do with trying to make a point about this
series. E.g. you'd be able to more easily validate/check/fsck a mailmap
that way. Or e.g. use a git repository's .mailmap as a source to export
to your MTA rules or whatever.

The external tools I referred to which consume the exported .mailmap
data are something I worked on at a previous job, but I no longer have
that immediate itch to scratch personally.

The "march of history" point was rather that if the difference between
URI encoding and this solution is current tooling, it seems all but
inevitable that we'll bridge that gap sooner than later in a way that
makes that difference useless to some of the users that want this now.

And not even because some people don't like this feature in particular
and wish to submit patches to make it less useful. But just because we
continue implementing stuff that's been talked about for years & is
being generally slowly worked towards. E.g. more client<->server
cooperation for expensive queries over protocol v2, or a filter clone
mode where you get only commit objects.

It even seems like something brian's series itself could benefit
from. I.e. having the hashed values in the history is a performance hit
in some cases. The patch caches the computation.

Another way to do it would be to just save a
".git/objects/info/mailmap.{hash-of-original-file}". Either on the fly
or generated by "maintenance" or whatever. It would guarantee a 0%
performance hit. At that point we'd already have the plumbing to
materialize the file & would need to go out of our way to make it
inaccessible in porcelain.

1. https://lore.kernel.org/git/X%2FtxB8b3%2FqqbwbmC@camp.crustytoothpaste.net/

Re: What's cooking in git.git (Jan 2021, #02; Fri, 8)

[Emily Shaffer]

On Fri, Jan 08, 2021 at 11:22:23AM -0800, Junio C Hamano wrote:
> * ds/maintenance-part-4 (2021-01-05) 4 commits
>   (merged to 'next' on 2021-01-08 at 1f98c859ea)
>  + maintenance: use Windows scheduled tasks
>  + maintenance: use launchctl on macOS
>  + maintenance: include 'cron' details in docs
>  + maintenance: extract platform-specific scheduling
> 
>  Follow-up on the "maintenance part-3" which introduced scheduled
>  maintenance tasks to support platforms whose native scheduling
>  methods are not 'cron'.
> 
>  Will merge to 'master'.

This series again has troubles running inside a directory with regex
metachars in the path. Courtesy of Jonathan Nieder, I think this fix
matches the intent a little better; but if we don't like this, the same
lines could be diffed just to add --fixed-value instead.

Before this patch, the test said "Is there something configured in
maintenance.repo that looks like $PWD?" and after this patch, the test
says, "Does the config in maintenance.repo look like $PWD?" - so it is
not quite semantically identical but I think may be clearer.

 - Emily

-- >8 --
Subject: [PATCH] maintenace: explicitly test value of maintenance.repo

Make t7900-maintenance.sh easier to debug by printing and checking the
value of maintenance.repo rather than using a search string. Since only
one maintenance.repo is configured, this is fine; in the event that
multiple maintenance.repo are configured during the test, instead the
directory under test should be provided along with '--fixed-value'.

Signed-off-by: Emily Shaffer <emilyshaffer@google.com>
---
 t/t7900-maintenance.sh | 16 ++++++++++++----
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/t/t7900-maintenance.sh b/t/t7900-maintenance.sh
index 2e0c8a4c31..0edad63227 100755
--- a/t/t7900-maintenance.sh
+++ b/t/t7900-maintenance.sh
@@ -487,7 +487,9 @@ test_expect_success 'start and stop macOS maintenance' '
 	GIT_TEST_MAINT_SCHEDULER=launchctl:./print-args git maintenance start &&
 
 	# start registers the repo
-	git config --get --global maintenance.repo "$(pwd)" &&
+	pwd >expect &&
+	git config --get --global maintenance.repo >actual &&
+	test_cmp expect actual &&
 
 	ls "$HOME/Library/LaunchAgents" >actual &&
 	cat >expect <<-\EOF &&
@@ -512,7 +514,9 @@ test_expect_success 'start and stop macOS maintenance' '
 	GIT_TEST_MAINT_SCHEDULER=launchctl:./print-args git maintenance stop &&
 
 	# stop does not unregister the repo
-	git config --get --global maintenance.repo "$(pwd)" &&
+	pwd >expect &&
+	git config --get --global maintenance.repo >actual &&
+	test_cmp expect actual &&
 
 	printf "bootout gui/[UID] $pfx/Library/LaunchAgents/org.git-scm.git.%s.plist\n" \
 		hourly daily weekly >expect &&
@@ -538,7 +542,9 @@ test_expect_success 'start and stop Windows maintenance' '
 	GIT_TEST_MAINT_SCHEDULER="schtasks:./print-args" git maintenance start &&
 
 	# start registers the repo
-	git config --get --global maintenance.repo "$(pwd)" &&
+	pwd >expect &&
+	git config --get --global maintenance.repo >actual &&
+	test_cmp expect actual &&
 
 	for frequency in hourly daily weekly
 	do
@@ -551,7 +557,9 @@ test_expect_success 'start and stop Windows maintenance' '
 	GIT_TEST_MAINT_SCHEDULER="schtasks:./print-args" git maintenance stop &&
 
 	# stop does not unregister the repo
-	git config --get --global maintenance.repo "$(pwd)" &&
+	pwd >expect &&
+	git config --get --global maintenance.repo >actual &&
+	test_cmp expect actual &&
 
 	printf "/delete /tn Git Maintenance (%s) /f\n" \
 		hourly daily weekly >expect &&
-- 
2.29.2.490.gc7ae633391

Re: What's cooking in git.git (Jan 2021, #02; Fri, 8)

[Emily Shaffer]

On Tue, Jan 12, 2021 at 03:00:30PM +0100, Ævar Arnfjörð Bjarmason wrote:
> 
> 
> On Mon, Jan 11 2021, Junio C Hamano wrote:
> 
> > "brian m. carlson" <sandals@crustytoothpaste.net> writes:
> >
> >> On 2021-01-09 at 23:20:25, Junio C Hamano wrote:
> >>> "brian m. carlson" <sandals@crustytoothpaste.net> writes:
> >>> 
> >>> > On 2021-01-09 at 21:28:58, Junio C Hamano wrote:
> >>> >> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
> >>> >> > FWIW there was since a re-roll on 2021-01-03, but the discussion is
> >>> >> > sort-of outstanding, so maybe that's intentional...
> >>> >> 
> >>> >> I had an impression that those 4 or 5 patches haven't gained
> >>> >> concensus that they are good as-is.
> >>> >
> >>> > There will be another reroll.  I'm hoping to get to it this weekend.
> >>> 
> >>> Thanks.
> >>
> >> Having read Ævar's latest comment, I've decided instead to drop this, so
> >> feel free to do so whenever it's convenient.
> >
> > That's kind of sad.
> 
> Agreed. I mean, I'm just one contributor with an opinion. I certainly
> don't mean my "meh" on a patch to be some sort of veto.
> 
> If you follow this list you'll see that if you're going to take anyone's
> opinion on whether a thing should make it into git as a matter of
> empirical data on patches I submit that aren't changed meaningfully,
> then, uh, maybe pick someone else :)
> 
> > I view that this is the kind of topic where perfect easily can
> > become an enemy of good, as there is by definition no perfection
> > available to us without breaking existing Git.
> >
> > I do not know about Ævar, but to me, my initial impression while
> > reading the discussion from sideline was that the goal was to
> > prevent a mechanical scan of a recent version of .mailmap from
> > learning that Joe used to use Jane as his/her name, and that was the
> > reason why I asked to be convinced why encoding for obfuscation was
> > insufficient.  In the above, I meant "mechanical scan" as something
> > like "a web search engine crawls and finds a .mailmap---a query for
> > Joe produces a line with some garbage on it that is not Jane." and a
> > casual attacker would stop there.
> >
> > But of course, a casual attacker who knows urlencode or whatever
> > obfuscation in use can read that "garbage" once he/she knows that
> > "garbage" is worth attacking (i.e. it is known to be associated to
> > Joe, the person the attacker is interested in).
> >
> > If your goal is to make it harder than just urlencode, even though
> > we all have to accept that scanning "git log --all" for all names
> > that appear in the history and hashing them all to see what name
> > hashes to the "garbage" in question, then @sha256:<hash> approach
> > does make sense as a stopping point.  Perhaps we need to sell this
> > with a clear definition of what kind of attackes we are protecting
> > the name data from:
> >
> >     The attacker is required to obtain sufficient amount of history
> >     in the project to uncover the obfuscation; a more casual
> >     attackers will fail to uncover, and we declare that it is better
> >     than nothing and it is good enough in practice.
> >
> > or something like that?  I am not sure if I drew the line at the
> > level you intended to draw in the above, if I think that it is good
> > enough in practice, or if I agree to a change that is better than
> > nothing but not good enough in practice, but having such a statement
> > would help to see where we agree or disagree.
> 
> My reading of the general thread & brian's reply at [1] is that the
> difference in the minds of the users who want the feature (who're not
> on-list, and we're getting brian's's summary of their views) is closer
> to:
> 
>     We want the X-Y problem of "hide this data" solved with solution "Y"
>     because git's current tooling to retrieve the data is currently
>     rather tedious & obscure.
> 
> So when I asked whether those users would feel the same if the tooling
> was less tedious and suggested that I might patch it to be so brian
> replied with "[yes,] we do rely on this being inconvenient".
> 
> I do have a 20-something series patch to the mailmap code in my local
> queue that in the light of this series's status I think I'll submit
> soon.
> 
> It doesn't have anything to do with adding a "spew out a materialized
> map" feature currently, nor do I really plan to do that any time soon. I
> do genuinely think it would be a good addition to git for reasons that
> have nothing to do with trying to make a point about this
> series. E.g. you'd be able to more easily validate/check/fsck a mailmap
> that way. Or e.g. use a git repository's .mailmap as a source to export
> to your MTA rules or whatever.
> 
> The external tools I referred to which consume the exported .mailmap
> data are something I worked on at a previous job, but I no longer have
> that immediate itch to scratch personally.
> 
> The "march of history" point was rather that if the difference between
> URI encoding and this solution is current tooling, it seems all but
> inevitable that we'll bridge that gap sooner than later in a way that
> makes that difference useless to some of the users that want this now.
> 
> And not even because some people don't like this feature in particular
> and wish to submit patches to make it less useful. But just because we
> continue implementing stuff that's been talked about for years & is
> being generally slowly worked towards. E.g. more client<->server
> cooperation for expensive queries over protocol v2, or a filter clone
> mode where you get only commit objects.
> 
> It even seems like something brian's series itself could benefit
> from. I.e. having the hashed values in the history is a performance hit
> in some cases. The patch caches the computation.
> 
> Another way to do it would be to just save a
> ".git/objects/info/mailmap.{hash-of-original-file}". Either on the fly
> or generated by "maintenance" or whatever. It would guarantee a 0%
> performance hit. At that point we'd already have the plumbing to
> materialize the file & would need to go out of our way to make it
> inaccessible in porcelain.

I've got quite a few sporadic thoughts about this series and this
discussion, so I'll braindump and hopefully it turns into something
useful.

Firstly: this design comes from a conversation amongst a pretty small (4
people? 6 people?) group at the virtual inclusion summit some months
ago. At that time, we discussed the ease of brute-force decoding the
one-way-hashed mailmap and decided that, as long as Git didn't ship a
tool to do this for you for free, it was better than the current
solution for avoiding deadnames (i.e. "sorry"). I'm disappointed to see
the larger list feel otherwise, but not terribly surprised, since the
list contains more people than the group who came up with the design.

Secondly: it seems like a restatement of the goals of this patch would
help guide a discussion of designs; I would be so pleased to see a
cleaner solution than any that's been proposed so far, because I agree
that this feature is not perfect. So please append what I have missed:

Axiom: The current Git solution for avoiding deadnaming is insufficient.
Axiom: We want to improve Git's solution for avoiding deadnaming.
(That is, I don't think either of these statements are or should be up
for discussion.)

Goal: Projects which are contributed to by trans individuals who
transition during their contribution period should provide a good,
supportive experience, which does not deadname the individual.
Goal: Git's performance should not suffer unduly from any change unless
necessary.
Goal: Project maintainers should have an understanding of the threat
model (e.g. automated tools scraping for names, malicious individuals
with time on their hands and experience with the project, etc)
Goal: Audit trails required by e.g. SOB lines should exist for the
project maintainer, if necessary
Goal: Mailmap, in general, should work better than it does now
Goal: An imperfect solution should not disallow a more perfect solution
later down the road
Bonus goal: For the sake of Git project contributors, it would be nice
to avoid a troll storm on list.

Thirdly: As is stated elsewhere, I think this topic is falling victim to
perfect vs. good. Git is gaining increasing notoriety in circles I can
see about the ultimately crappy experience for people who change their
names and don't want to hear the old names (and don't want to know the
old names). In my opinion, literally anything we could do to improve
this experience would be better than doing nothing. So I feel sad to see
the topic dropped because of pushback, especially when that pushback is
"I'd like to write a tool to reverse this thing, because <vague reasons>
- and I don't mean that tool maliciously so that should be OK."

Fourthly: The perfect solution, as has been mentioned, is to stop using
user.name/user.email in commits and start using some generic ID instead.
I think I mentioned this during the summit as well, but one meh idea -
which maybe someone else can be inspired by and come up with something
better - may be to just start wedging genericness into those fields
anyways. That is, generating commits with user.name like "abc123def" and
user.email like "<requires-git-v2-31-or-later@generic.submitter>". I
don't like the idea of carrying that technical debt around forever, but
the experience it provides on older Git versions isn't terrible,
especially if you pair it with a mailmap entry from "abc123def" to
"Emily Shaffer <emilyshaffer@google.com>", for example.

Food for thought.
 - Emily

> 
> 1. https://lore.kernel.org/git/X%2FtxB8b3%2FqqbwbmC@camp.crustytoothpaste.net/

Re: What's cooking in git.git (Jan 2021, #02; Fri, 8)

[Emily Shaffer]

On Thu, Jan 14, 2021 at 03:52:42PM -0800, Emily Shaffer wrote:
> Fourthly: The perfect solution, as has been mentioned, is to stop using
> user.name/user.email in commits and start using some generic ID instead.

Another throwaway thought:

Taking the time to redesign commit format (e.g. use user.id instead of
user.name/user.email) also gives us room to improve other things we
don't like about the commit format (e.g. limited to single author). How
many things-we-don't-like do we need to collect before we have enough
inertia to go through the long/painful process of starting to use a new
commit format?

Re: What's cooking in git.git (Jan 2021, #02; Fri, 8)

[brian m. carlson]

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

On 2021-01-14 at 23:52:42, Emily Shaffer wrote:
> Firstly: this design comes from a conversation amongst a pretty small (4
> people? 6 people?) group at the virtual inclusion summit some months
> ago. At that time, we discussed the ease of brute-force decoding the
> one-way-hashed mailmap and decided that, as long as Git didn't ship a
> tool to do this for you for free, it was better than the current
> solution for avoiding deadnames (i.e. "sorry"). I'm disappointed to see
> the larger list feel otherwise, but not terribly surprised, since the
> list contains more people than the group who came up with the design.

Yes, thank you for sharing this helpful context.  I will add that there
were a couple folks in that conversation who had mentioned that the
hashed mailmap was an idea they'd thought of (of which I was one) and I
did commit to bringing it to the list.

> Secondly: it seems like a restatement of the goals of this patch would
> help guide a discussion of designs; I would be so pleased to see a
> cleaner solution than any that's been proposed so far, because I agree
> that this feature is not perfect. So please append what I have missed:

I completely agree.  If there are better ideas, I'd be delighted to hear
them, even if the proposer isn't interested in implementing them.

> Axiom: The current Git solution for avoiding deadnaming is insufficient.
> Axiom: We want to improve Git's solution for avoiding deadnaming.
> (That is, I don't think either of these statements are or should be up
> for discussion.)
> 
> Goal: Projects which are contributed to by trans individuals who
> transition during their contribution period should provide a good,
> supportive experience, which does not deadname the individual.
> Goal: Git's performance should not suffer unduly from any change unless
> necessary.
> Goal: Project maintainers should have an understanding of the threat
> model (e.g. automated tools scraping for names, malicious individuals
> with time on their hands and experience with the project, etc)
> Goal: Audit trails required by e.g. SOB lines should exist for the
> project maintainer, if necessary
> Goal: Mailmap, in general, should work better than it does now
> Goal: An imperfect solution should not disallow a more perfect solution
> later down the road
> Bonus goal: For the sake of Git project contributors, it would be nice
> to avoid a troll storm on list.

I agree with all of these.

Considering the last point, part of the reason I volunteered to present
this idea to the list was that I expected some trolling and general poor
behavior (hence my reminder about the CoC) and I'm comfortable with
taking the flak here.  I am (and I'm sure everyone else on the list is)
delighted that we didn't see that.

> Thirdly: As is stated elsewhere, I think this topic is falling victim to
> perfect vs. good. Git is gaining increasing notoriety in circles I can
> see about the ultimately crappy experience for people who change their
> names and don't want to hear the old names (and don't want to know the
> old names). In my opinion, literally anything we could do to improve
> this experience would be better than doing nothing. So I feel sad to see
> the topic dropped because of pushback, especially when that pushback is
> "I'd like to write a tool to reverse this thing, because <vague reasons>
> - and I don't mean that tool maliciously so that should be OK."

If folks feel that my series is at least better than the status quo and
do want it to be picked up, I can do the reroll I was planning on doing.
It sounds like there may be some support for that.

I think that does implicitly mean, though, that we're agreeing that
maybe adding a tool to reverse hashes isn't something we want to adopt
in Git, at least until we have a better or different solution in place.
While I agree there could be some legitimate uses for it, we do have to
be cognizant of the potential for misuse and abuse (as when writing any
software).
-- 
brian m. carlson (he/him or they/them)
Houston, Texas, US

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

Re: What's cooking in git.git (Jan 2021, #02; Fri, 8)

[Junio C Hamano]

Emily Shaffer <emilyshaffer@google.com> writes:

> Secondly: it seems like a restatement of the goals of this patch would
> help guide a discussion of designs; I would be so pleased to see a
> cleaner solution than any that's been proposed so far, because I agree
> that this feature is not perfect. So please append what I have missed:
>
> Axiom: The current Git solution for avoiding deadnaming is insufficient.
> Axiom: We want to improve Git's solution for avoiding deadnaming.
> (That is, I don't think either of these statements are or should be up
> for discussion.)

Another one [*1*]:

Axiom: It is, by nature of how Git works, impossible to come up with
a solution that avoids deadnaming perfectly.  The best we can do is
to aim for "good enough".

> Goal: Projects which are contributed to by trans individuals who
> transition during their contribution period should provide a good,
> supportive experience, which does not deadname the individual.
> Goal: Git's performance should not suffer unduly from any change unless
> necessary.
> Goal: Project maintainers should have an understanding of the threat
> model (e.g. automated tools scraping for names, malicious individuals
> with time on their hands and experience with the project, etc)

Goal: the design should clearly describe the thread model it
supports, so that "good enough" can be judged against it.



[Footnote]

*1* This may be clear from what both you and I said about perfection
and being good enough.  I usually do not like to see people punt for
an imperfect solution too early without even trying, but in a case
like this where we know perfection is theoretically impossible, it
is a totally different story.

Re: What's cooking in git.git (Jan 2021, #02; Fri, 8)

[Junio C Hamano]

Emily Shaffer <emilyshaffer@google.com> writes:

> On Fri, Jan 08, 2021 at 11:22:23AM -0800, Junio C Hamano wrote:
>> * ds/maintenance-part-4 (2021-01-05) 4 commits
>>   (merged to 'next' on 2021-01-08 at 1f98c859ea)
>>  + maintenance: use Windows scheduled tasks
>>  + maintenance: use launchctl on macOS
>>  + maintenance: include 'cron' details in docs
>>  + maintenance: extract platform-specific scheduling
>> 
>>  Follow-up on the "maintenance part-3" which introduced scheduled
>>  maintenance tasks to support platforms whose native scheduling
>>  methods are not 'cron'.
>> 
>>  Will merge to 'master'.
>
> This series again has troubles running inside a directory with regex
> metachars in the path. Courtesy of Jonathan Nieder, I think this fix
> matches the intent a little better; but if we don't like this, the same
> lines could be diffed just to add --fixed-value instead.

Thanks.

>  	# start registers the repo
> -	git config --get --global maintenance.repo "$(pwd)" &&
> +	pwd >expect &&
> +	git config --get --global maintenance.repo >actual &&
> +	test_cmp expect actual &&

> Before this patch, the test said "Is there something configured in
> maintenance.repo that looks like $PWD?" and after this patch, the test
> says, "Does the config in maintenance.repo look like $PWD?" - so it is
> not quite semantically identical but I think may be clearer.

Sounds sensible.  Derrick (CC'ed), thoughts?

Re: What's cooking in git.git (Jan 2021, #02; Fri, 8)

[Taylor Blau]

On Thu, Jan 14, 2021 at 05:50:08PM -0800, Junio C Hamano wrote:
> Emily Shaffer <emilyshaffer@google.com> writes:
> >  	# start registers the repo
> > -	git config --get --global maintenance.repo "$(pwd)" &&
> > +	pwd >expect &&
> > +	git config --get --global maintenance.repo >actual &&
> > +	test_cmp expect actual &&
>
> > Before this patch, the test said "Is there something configured in
> > maintenance.repo that looks like $PWD?" and after this patch, the test
> > says, "Does the config in maintenance.repo look like $PWD?" - so it is
> > not quite semantically identical but I think may be clearer.
>
> Sounds sensible.  Derrick (CC'ed), thoughts?

I'm not Stolee, but isn't this what 'git config --fixed-value' is for?
ISTM that what is written here (writing the cwd into 'expect', and then
comparing it to the value of maintenance.repo) is correct, but I think
it may be unnecessarily verbose.

I.e., wouldn't the following do the trick?

-	git config --get --global maintenance.repo "$(pwd)" &&
+	git config --get --fixed-value --global maintenance.repo "$(pwd)" &&

Thanks,
Taylor

Re: What's cooking in git.git (Jan 2021, #02; Fri, 8)

[Derrick Stolee]

On 1/14/2021 6:06 PM, Emily Shaffer wrote:
> On Fri, Jan 08, 2021 at 11:22:23AM -0800, Junio C Hamano wrote:
>> * ds/maintenance-part-4 (2021-01-05) 4 commits
>>   (merged to 'next' on 2021-01-08 at 1f98c859ea)
>>  + maintenance: use Windows scheduled tasks
>>  + maintenance: use launchctl on macOS
>>  + maintenance: include 'cron' details in docs
>>  + maintenance: extract platform-specific scheduling
>>
>>  Follow-up on the "maintenance part-3" which introduced scheduled
>>  maintenance tasks to support platforms whose native scheduling
>>  methods are not 'cron'.
>>
>>  Will merge to 'master'.
> 
> This series again has troubles running inside a directory with regex
> metachars in the path. Courtesy of Jonathan Nieder, I think this fix
> matches the intent a little better; but if we don't like this, the same
> lines could be diffed just to add --fixed-value instead.
> 
> Before this patch, the test said "Is there something configured in
> maintenance.repo that looks like $PWD?" and after this patch, the test
> says, "Does the config in maintenance.repo look like $PWD?" - so it is
> not quite semantically identical but I think may be clearer.

This appears to be a case of mixing up the order in which these
submissions came into place. js/t7900-protect-pwd-in-config-get added
--fixed-value, but that was simultaneous with ds/maintenance-part-4
which added more tests in this vein without including --fixed-value.

Looking at the history, ds/maintenance-part-4 doesn't have
js/t7900-protect-pwd-in-config-get in its history, which is probably
why you don't include --fixed-value in your patch.

Perhaps it would be better to have a --fixed-value patch on top
of the merge that combines the two topics?

> -- >8 --
> Subject: [PATCH] maintenace: explicitly test value of maintenance.repo

s/maintenace/maintenance/

> Make t7900-maintenance.sh easier to debug by printing and checking the
> value of maintenance.repo rather than using a search string. Since only
> one maintenance.repo is configured, this is fine; in the event that
> multiple maintenance.repo are configured during the test, instead the
> directory under test should be provided along with '--fixed-value'.

Here you mention --fixed-value as if you plan to use it. I'm all for
that plan.

> Signed-off-by: Emily Shaffer <emilyshaffer@google.com>
> ---
>  t/t7900-maintenance.sh | 16 ++++++++++++----
>  1 file changed, 12 insertions(+), 4 deletions(-)
> 
> diff --git a/t/t7900-maintenance.sh b/t/t7900-maintenance.sh
> index 2e0c8a4c31..0edad63227 100755
> --- a/t/t7900-maintenance.sh
> +++ b/t/t7900-maintenance.sh
> @@ -487,7 +487,9 @@ test_expect_success 'start and stop macOS maintenance' '
>  	GIT_TEST_MAINT_SCHEDULER=launchctl:./print-args git maintenance start &&
>  
>  	# start registers the repo
> -	git config --get --global maintenance.repo "$(pwd)" &&
> +	pwd >expect &&
> +	git config --get --global maintenance.repo >actual &&
> +	test_cmp expect actual &&

Sorry again, but this (and others) would probably be better as

+	git config --get --global --fixed-value maintenance.repo "$(pwd)" &&

Thanks,
-Stolee

Re: What's cooking in git.git (Jan 2021, #02; Fri, 8)

[Taylor Blau]

On Thu, Jan 14, 2021 at 09:24:17PM -0500, Taylor Blau wrote:
> I'm not Stolee, but isn't this what 'git config --fixed-value' is for?

My apologies: Emily suggested this in her original patch and I
completely read past it. I do think that this is better than repeating
pwd >expect, git config >actual, test_cmp expect actual over and over,
but credit where it's due.

Thanks,
Taylor

Re: What's cooking in git.git (Jan 2021, #02; Fri, 8)

[Derrick Stolee]

On 1/14/2021 9:36 PM, Derrick Stolee wrote:
> On 1/14/2021 6:06 PM, Emily Shaffer wrote:
>> On Fri, Jan 08, 2021 at 11:22:23AM -0800, Junio C Hamano wrote:
>>> * ds/maintenance-part-4 (2021-01-05) 4 commits
>>>   (merged to 'next' on 2021-01-08 at 1f98c859ea)
>>>  + maintenance: use Windows scheduled tasks
>>>  + maintenance: use launchctl on macOS
>>>  + maintenance: include 'cron' details in docs
>>>  + maintenance: extract platform-specific scheduling
>>>
>>>  Follow-up on the "maintenance part-3" which introduced scheduled
>>>  maintenance tasks to support platforms whose native scheduling
>>>  methods are not 'cron'.
>>>
>>>  Will merge to 'master'.
>>
>> This series again has troubles running inside a directory with regex
>> metachars in the path. Courtesy of Jonathan Nieder, I think this fix
>> matches the intent a little better; but if we don't like this, the same
>> lines could be diffed just to add --fixed-value instead.
...
>>
>> diff --git a/t/t7900-maintenance.sh b/t/t7900-maintenance.sh
>> index 2e0c8a4c31..0edad63227 100755
>> --- a/t/t7900-maintenance.sh
>> +++ b/t/t7900-maintenance.sh
>> @@ -487,7 +487,9 @@ test_expect_success 'start and stop macOS maintenance' '
>>  	GIT_TEST_MAINT_SCHEDULER=launchctl:./print-args git maintenance start &&
>>  
>>  	# start registers the repo
>> -	git config --get --global maintenance.repo "$(pwd)" &&
>> +	pwd >expect &&
>> +	git config --get --global maintenance.repo >actual &&
>> +	test_cmp expect actual &&
> 
> Sorry again, but this (and others) would probably be better as
> 
> +	git config --get --global --fixed-value maintenance.repo "$(pwd)" &&

Alternatively, the additional cases of "git config --get --global" in
ds/maintenance-part-4 could actually be simply _removed_ because we
are running all tests on all platforms. We already verify this behavior
in the cron tests, such as 'start from empty cron table'.

Thanks,
-Stolee

Re: What's cooking in git.git (Jan 2021, #02; Fri, 8)

[Junio C Hamano]

Derrick Stolee <stolee@gmail.com> writes:

> Perhaps it would be better to have a --fixed-value patch on top
> of the merge that combines the two topics?

Thanks.  That is how we usually handle this kind of fallouts from
multiple topics.

In fact, there already are conflicting hunks in t/t7900 when the
topic is merged into the current 'master', and rerere database knows
about them; I'll need to teach "--fixed-value" to these places.

Here is how eventual merge of the topic into 'master' would resolve
conflicts.  The straight merge chain from master..seen would have
such a merge with the resolution shown below, but 'next' already has
a mismerge, so I'll be applying a single-parent commit to fix the
mismerge directly on 'next' (which I'll send in a separate message).

Thanks, all, for all the help.



diff --cc t/t7900-maintenance.sh
index 99bf0c7582,135505f619..0000000000
--- i/t/t7900-maintenance.sh
+++ w/t/t7900-maintenance.sh
@@@ -406,23 -380,11 +419,23 @@@ test_expect_success 'register and unreg
  	test_cmp before actual
  '
  
 +test_expect_success !MINGW 'register and unregister with regex metacharacters' '
 +	META="a+b*c" &&
 +	git init "$META" &&
 +	git -C "$META" maintenance register &&
 +	git config --get-all --show-origin maintenance.repo &&
 +	git config --get-all --global --fixed-value \
 +		maintenance.repo "$(pwd)/$META" &&
 +	git -C "$META" maintenance unregister &&
 +	test_must_fail git config --get-all --global --fixed-value \
 +		maintenance.repo "$(pwd)/$META"
 +'
 +
  test_expect_success 'start from empty cron table' '
- 	GIT_TEST_CRONTAB="test-tool crontab cron.txt" git maintenance start &&
+ 	GIT_TEST_MAINT_SCHEDULER="crontab:test-tool crontab cron.txt" git maintenance start &&
  
  	# start registers the repo
 -	git config --get --global maintenance.repo "$(pwd)" &&
 +	git config --get --global --fixed-value maintenance.repo "$(pwd)" &&
  
  	grep "for-each-repo --config=maintenance.repo maintenance run --schedule=daily" cron.txt &&
  	grep "for-each-repo --config=maintenance.repo maintenance run --schedule=hourly" cron.txt &&
@@@ -430,13 -392,13 +443,13 @@@
  '
  
  test_expect_success 'stop from existing schedule' '
- 	GIT_TEST_CRONTAB="test-tool crontab cron.txt" git maintenance stop &&
+ 	GIT_TEST_MAINT_SCHEDULER="crontab:test-tool crontab cron.txt" git maintenance stop &&
  
  	# stop does not unregister the repo
 -	git config --get --global maintenance.repo "$(pwd)" &&
 +	git config --get --global --fixed-value maintenance.repo "$(pwd)" &&
  
  	# Operation is idempotent
- 	GIT_TEST_CRONTAB="test-tool crontab cron.txt" git maintenance stop &&
+ 	GIT_TEST_MAINT_SCHEDULER="crontab:test-tool crontab cron.txt" git maintenance stop &&
  	test_must_be_empty cron.txt
  '
  
@@@ -446,22 -408,89 +459,105 @@@ test_expect_success 'start preserves ex
  	grep "Important information!" cron.txt
  '
  
 +test_expect_success 'magic markers are correct' '
 +	grep "GIT MAINTENANCE SCHEDULE" cron.txt >actual &&
 +	cat >expect <<-\EOF &&
 +	# BEGIN GIT MAINTENANCE SCHEDULE
 +	# END GIT MAINTENANCE SCHEDULE
 +	EOF
 +	test_cmp actual expect
 +'
 +
 +test_expect_success 'stop preserves surrounding schedule' '
 +	echo "Crucial information!" >>cron.txt &&
- 	GIT_TEST_CRONTAB="test-tool crontab cron.txt" git maintenance stop &&
++	GIT_TEST_MAINT_SCHEDULER="crontab:test-tool crontab cron.txt" git maintenance stop &&
 +	grep "Important information!" cron.txt &&
 +	grep "Crucial information!" cron.txt
 +'
 +
+ test_expect_success 'start and stop macOS maintenance' '
+ 	# ensure $HOME can be compared against hook arguments on all platforms
+ 	pfx=$(cd "$HOME" && pwd) &&
+ 
+ 	write_script print-args <<-\EOF &&
+ 	echo $* | sed "s:gui/[0-9][0-9]*:gui/[UID]:" >>args
+ 	EOF
+ 
+ 	rm -f args &&
+ 	GIT_TEST_MAINT_SCHEDULER=launchctl:./print-args git maintenance start &&
+ 
+ 	# start registers the repo
 -	git config --get --global maintenance.repo "$(pwd)" &&
++	git config --get --global --fixed-value maintenance.repo "$(pwd)" &&
+ 
+ 	ls "$HOME/Library/LaunchAgents" >actual &&
+ 	cat >expect <<-\EOF &&
+ 	org.git-scm.git.daily.plist
+ 	org.git-scm.git.hourly.plist
+ 	org.git-scm.git.weekly.plist
+ 	EOF
+ 	test_cmp expect actual &&
+ 
+ 	rm -f expect &&
+ 	for frequency in hourly daily weekly
+ 	do
+ 		PLIST="$pfx/Library/LaunchAgents/org.git-scm.git.$frequency.plist" &&
+ 		test_xmllint "$PLIST" &&
+ 		grep schedule=$frequency "$PLIST" &&
+ 		echo "bootout gui/[UID] $PLIST" >>expect &&
+ 		echo "bootstrap gui/[UID] $PLIST" >>expect || return 1
+ 	done &&
+ 	test_cmp expect args &&
+ 
+ 	rm -f args &&
+ 	GIT_TEST_MAINT_SCHEDULER=launchctl:./print-args git maintenance stop &&
+ 
+ 	# stop does not unregister the repo
 -	git config --get --global maintenance.repo "$(pwd)" &&
++	git config --get --global --fixed-value maintenance.repo "$(pwd)" &&
+ 
+ 	printf "bootout gui/[UID] $pfx/Library/LaunchAgents/org.git-scm.git.%s.plist\n" \
+ 		hourly daily weekly >expect &&
+ 	test_cmp expect args &&
+ 	ls "$HOME/Library/LaunchAgents" >actual &&
+ 	test_line_count = 0 actual
+ '
+ 
+ test_expect_success 'start and stop Windows maintenance' '
+ 	write_script print-args <<-\EOF &&
+ 	echo $* >>args
+ 	while test $# -gt 0
+ 	do
+ 		case "$1" in
+ 		/xml) shift; xmlfile=$1; break ;;
+ 		*) shift ;;
+ 		esac
+ 	done
+ 	test -z "$xmlfile" || cp "$xmlfile" "$xmlfile.xml"
+ 	EOF
+ 
+ 	rm -f args &&
+ 	GIT_TEST_MAINT_SCHEDULER="schtasks:./print-args" git maintenance start &&
+ 
+ 	# start registers the repo
 -	git config --get --global maintenance.repo "$(pwd)" &&
++	git config --get --global --fixed-value maintenance.repo "$(pwd)" &&
+ 
+ 	for frequency in hourly daily weekly
+ 	do
+ 		grep "/create /tn Git Maintenance ($frequency) /f /xml" args &&
+ 		file=$(ls .git/schedule_${frequency}*.xml) &&
+ 		test_xmllint "$file" || return 1
+ 	done &&
+ 
+ 	rm -f args &&
+ 	GIT_TEST_MAINT_SCHEDULER="schtasks:./print-args" git maintenance stop &&
+ 
+ 	# stop does not unregister the repo
 -	git config --get --global maintenance.repo "$(pwd)" &&
++	git config --get --global --fixed-value maintenance.repo "$(pwd)" &&
+ 
+ 	printf "/delete /tn Git Maintenance (%s) /f\n" \
+ 		hourly daily weekly >expect &&
+ 	test_cmp expect args
+ '
+ 
  test_expect_success 'register preserves existing strategy' '
  	git config maintenance.strategy none &&
  	git maintenance register &&

Re: What's cooking in git.git (Jan 2021, #02; Fri, 8)

[Junio C Hamano]

Junio C Hamano <gitster@pobox.com> writes:

> Here is how eventual merge of the topic into 'master' would resolve
> conflicts.  The straight merge chain from master..seen would have
> such a merge with the resolution shown below, but 'next' already has
> a mismerge, so I'll be applying a single-parent commit to fix the
> mismerge directly on 'next' (which I'll send in a separate message).

And this is the 'next' mismerge fix.

----- >8 ----- >8 ----- >8 ----- >8 ----- >8 -----
Subject: [PATCH] Fix mismerge of ds/maintenance-part-4 topic

At 1f98c859 (Merge branch 'ds/maintenance-part-4' into next, 2021-01-08)
the ds/maintenance-part-4 topic, which had an incorrect invocation
of internal "git config" when $(pwd) had ERE special characters, was
merged into the mainline that added "--fixed-value" feature to the
"git config" command to address this exact issue, and also changed
how test-tool stubbed out crontab calls.

The semantic conflicts for the latter have been fully resolved at
that commit, but four places that "git config" was invoked to look
for entries with the same value as "$(pwd)" were not adjusted to use
the "--fixed-value".  They should have been.

Helped-by: Emily Shaffer <emilyshaffer@google.com>
Helped-by: Taylor Blau <me@ttaylorr.com>
Helped-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 t/t7900-maintenance.sh | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/t/t7900-maintenance.sh b/t/t7900-maintenance.sh
index 2e0c8a4c31..1074009cc0 100755
--- a/t/t7900-maintenance.sh
+++ b/t/t7900-maintenance.sh
@@ -487,7 +487,7 @@ test_expect_success 'start and stop macOS maintenance' '
 	GIT_TEST_MAINT_SCHEDULER=launchctl:./print-args git maintenance start &&
 
 	# start registers the repo
-	git config --get --global maintenance.repo "$(pwd)" &&
+	git config --get --global --fixed-value maintenance.repo "$(pwd)" &&
 
 	ls "$HOME/Library/LaunchAgents" >actual &&
 	cat >expect <<-\EOF &&
@@ -512,7 +512,7 @@ test_expect_success 'start and stop macOS maintenance' '
 	GIT_TEST_MAINT_SCHEDULER=launchctl:./print-args git maintenance stop &&
 
 	# stop does not unregister the repo
-	git config --get --global maintenance.repo "$(pwd)" &&
+	git config --get --global --fixed-value maintenance.repo "$(pwd)" &&
 
 	printf "bootout gui/[UID] $pfx/Library/LaunchAgents/org.git-scm.git.%s.plist\n" \
 		hourly daily weekly >expect &&
@@ -538,7 +538,7 @@ test_expect_success 'start and stop Windows maintenance' '
 	GIT_TEST_MAINT_SCHEDULER="schtasks:./print-args" git maintenance start &&
 
 	# start registers the repo
-	git config --get --global maintenance.repo "$(pwd)" &&
+	git config --get --global --fixed-value maintenance.repo "$(pwd)" &&
 
 	for frequency in hourly daily weekly
 	do
@@ -551,7 +551,7 @@ test_expect_success 'start and stop Windows maintenance' '
 	GIT_TEST_MAINT_SCHEDULER="schtasks:./print-args" git maintenance stop &&
 
 	# stop does not unregister the repo
-	git config --get --global maintenance.repo "$(pwd)" &&
+	git config --get --global --fixed-value maintenance.repo "$(pwd)" &&
 
 	printf "/delete /tn Git Maintenance (%s) /f\n" \
 		hourly daily weekly >expect &&
-- 
2.30.0-386-gfb533afdb4

Re: What's cooking in git.git (Jan 2021, #02; Fri, 8)

[Junio C Hamano]

Emily Shaffer <emilyshaffer@google.com> writes:

> Taking the time to redesign commit format (e.g. use user.id instead of
> user.name/user.email) ...

I have seen that "ID", which doesn't have permanent association to
<name, email>, has been raised as a solution from time to time, but
I am not quite sure what problem is being solved.  At some point,
you'd need to translate the "ID" to a way humans use to refer to
each other---you cannot forever be saying "Ah, commits by this
contributor #70763 is consistently good and seems to know the
history traversal quite well.  We wish who it is so that we can ask
to review what we have been working on."

So we must have a mapping from ID to <name, email> or something.
How is that mapping maintained?  Even though Git is a version
tracking system and the mapping will change over time, we'll only
keep the "latest"?  That may not work very well, as a work for hire
contract a company made with one of the project participants would
have been made with a real person with a name, not just an anonymous
contributor #70763---the work done under the contract would not
become invalid merely because mapping from ID to <name, email>
changes, and those who made contract with a person with a certain
name would want to make sure the contributor #70763 who made the
work is actually who they thought they had contract with.

If we do not keep track of the change of the mapping ourselves, the
ecosystem around us will start doing so to fill the gap, so I do not
think use of "ID" would help you dissociate from your past self,
while keeping the credit for your past commits.

And if the mapping is version controlled in such a way that an "ID"
can be used to look up its name at any given time in the past, it
would not be so different from what we already have.

One advantage I could imagine that "ID" based system may have is
that one who wants to completely dissociate from an older name
and/or email can just start using a totally different "ID" with
totally different name, and pretend that s/he has no relationship
with the old person associated with the old "ID", and nobody would
be able to tell.  But again, I suspect that it can also be done
without "ID".  So...

> ... also gives us room to improve other things we
> don't like about the commit format (e.g. limited to single author).

I personally think having "author" is a mistake, iff some people do
not like "limited to a single author".  You can write everybody's
name in the trailer as "Co-Authored-by:" and at that point you do
not need any author in the commit object header.

But that is so miniscule a feature that I do not think it is worth
making a backward incompatible change to change the number of the
commit object header for the author from 1 to either 0 or many.

Anyway, thanks for an opportunity for a (somewhat) fun thought
experiment.

Goodnight.

Re: What's cooking in git.git (Jan 2021, #02; Fri, 8)

[Derrick Stolee]

On 1/15/2021 1:38 AM, Junio C Hamano wrote:
> Junio C Hamano <gitster@pobox.com> writes:
> 
>> Here is how eventual merge of the topic into 'master' would resolve
>> conflicts.  The straight merge chain from master..seen would have
>> such a merge with the resolution shown below, but 'next' already has
>> a mismerge, so I'll be applying a single-parent commit to fix the
>> mismerge directly on 'next' (which I'll send in a separate message).
> 
> And this is the 'next' mismerge fix.
> 
> ----- >8 ----- >8 ----- >8 ----- >8 ----- >8 -----
> Subject: [PATCH] Fix mismerge of ds/maintenance-part-4 topic
> 
> At 1f98c859 (Merge branch 'ds/maintenance-part-4' into next, 2021-01-08)
> the ds/maintenance-part-4 topic, which had an incorrect invocation
> of internal "git config" when $(pwd) had ERE special characters, was
> merged into the mainline that added "--fixed-value" feature to the
> "git config" command to address this exact issue, and also changed
> how test-tool stubbed out crontab calls.
> 
> The semantic conflicts for the latter have been fully resolved at
> that commit, but four places that "git config" was invoked to look
> for entries with the same value as "$(pwd)" were not adjusted to use
> the "--fixed-value".  They should have been.

Thanks for dealing with this fallout. Sorry for the mixup.

> Helped-by: Emily Shaffer <emilyshaffer@google.com>

Would it be appropriate to convert this to a Co-authored-by?

Thanks,
-Stolee

Re: What's cooking in git.git (Jan 2021, #02; Fri, 8)

[Junio C Hamano]

Derrick Stolee <stolee@gmail.com> writes:

> Thanks for dealing with this fallout. Sorry for the mixup.
>
>> Helped-by: Emily Shaffer <emilyshaffer@google.com>
>
> Would it be appropriate to convert this to a Co-authored-by?

Or more like "Inspired-by-a-patch-by".  Also you three have about
the same amount of input and deserve credit.

Sorry, but it already is on 'next', which will be discarded in a few
months when the new cycle begins, so I am not sure if it is worth
reverting and reapplying with updated credit trailers.

FWIW, I ended up redoing the merge and did "checkout -m" to recreate
conflicts, and then looked for "config.*pwd" in the block of text
that came from the "part-4" topic and fixed them up manually.  I
then compared the result of this new merge with the earlier merge
that had the issue.  The resulting diff is what went into the patch
you are responding to.  It is good that we had Emily's input as a
comparison material to see that both of us independently touched the
same places to fix.

By the way, the merge into 'master' will directly reuse the conflict
resolution of e47c3632 (Merge branch 'ds/maintenance-part-4' into
jch, 2021-01-14) from the rerere database, without any separate
"merge fix" commit.

Thanks.

Re: What's cooking in git.git (Jan 2021, #02; Fri, 8)

[Jeff King]

On Fri, Jan 08, 2021 at 11:22:23AM -0800, Junio C Hamano wrote:

> * ps/config-env-pairs (2021-01-06) 8 commits
>  - config: allow specifying config entries via envvar pairs
>  - environment: make `getenv_safe()` a public function
>  - config: parse more robust format in GIT_CONFIG_PARAMETERS
>  - config: store "git -c" variables using more robust format
>  - config: extract function to parse config pairs
>  - quote: make sq_dequote_step() a public function
>  - config: add new way to pass config via `--config-env`
>  - git: add `--super-prefix` to usage string
> 
>  Introduce two new ways to feed configuration variable-value pairs
>  via environment variables, and tweak the way GIT_CONFIG_PARAMETERS
>  encodes variable/value pairs to make it more robust.
> 
>  Ready for 'next'?

I looked over the first 7, and noticed two of the patches are flipped in
roder (I sent a separate reply in the thread, but I wanted to catch your
attention, since I guess this may be on the list for integrating today).

I didn't see any problems in the code of the 8th one, but I didn't spend
a lot of brain power thinking about the overall design. I feel like that
was hashed out pretty well in the early discussions, though.

-Peff

Re: What's cooking in git.git (Jan 2021, #02; Fri, 8)

[Emily Shaffer]

On Fri, Jan 15, 2021 at 11:44:50AM -0800, Junio C Hamano wrote:
> 
> Derrick Stolee <stolee@gmail.com> writes:
> 
> > Thanks for dealing with this fallout. Sorry for the mixup.
> >
> >> Helped-by: Emily Shaffer <emilyshaffer@google.com>
> >
> > Would it be appropriate to convert this to a Co-authored-by?
> 
> Or more like "Inspired-by-a-patch-by".  Also you three have about
> the same amount of input and deserve credit.
> 
> Sorry, but it already is on 'next', which will be discarded in a few
> months when the new cycle begins, so I am not sure if it is worth
> reverting and reapplying with updated credit trailers.
> 
> FWIW, I ended up redoing the merge and did "checkout -m" to recreate
> conflicts, and then looked for "config.*pwd" in the block of text
> that came from the "part-4" topic and fixed them up manually.  I
> then compared the result of this new merge with the earlier merge
> that had the issue.  The resulting diff is what went into the patch
> you are responding to.  It is good that we had Emily's input as a
> comparison material to see that both of us independently touched the
> same places to fix.

Thanks for the action on this, glad to see it resolved in 'next' when I
pull today.

 - Emily

Re: What's cooking in git.git (Jan 2021, #02; Fri, 8)

[Junio C Hamano]

Emily Shaffer <emilyshaffer@google.com> writes:

> Thanks for the action on this, glad to see it resolved in 'next' when I
> pull today.

Thanks for double checking.

Re: What's cooking in git.git (Jan 2021, #02; Fri, 8)

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> I looked over the first 7, and noticed two of the patches are flipped in
> roder (I sent a separate reply in the thread, but I wanted to catch your
> attention, since I guess this may be on the list for integrating today).

Thanks.  Let's "rebase -i" the kinks out before merging it.

> I didn't see any problems in the code of the 8th one, but I didn't spend
> a lot of brain power thinking about the overall design. I feel like that
> was hashed out pretty well in the early discussions, though.

The same here.  I do not have a need for the KEY/VALUE pairs myself,
but I think the design is sound and I didn't see anything wrong in
the implementation.

Re: What's cooking in git.git (Jan 2021, #02; Fri, 8)

[Ævar Arnfjörð Bjarmason]

On Fri, Jan 15 2021, Emily Shaffer wrote:

> On Tue, Jan 12, 2021 at 03:00:30PM +0100, Ævar Arnfjörð Bjarmason wrote:
>> 
>> 
>> On Mon, Jan 11 2021, Junio C Hamano wrote:
>> 
>> > "brian m. carlson" <sandals@crustytoothpaste.net> writes:
>> >
>> >> On 2021-01-09 at 23:20:25, Junio C Hamano wrote:
>> >>> "brian m. carlson" <sandals@crustytoothpaste.net> writes:
>> >>> 
>> >>> > On 2021-01-09 at 21:28:58, Junio C Hamano wrote:
>> >>> >> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
>> >>> >> > FWIW there was since a re-roll on 2021-01-03, but the discussion is
>> >>> >> > sort-of outstanding, so maybe that's intentional...
>> >>> >> 
>> >>> >> I had an impression that those 4 or 5 patches haven't gained
>> >>> >> concensus that they are good as-is.
>> >>> >
>> >>> > There will be another reroll.  I'm hoping to get to it this weekend.
>> >>> 
>> >>> Thanks.
>> >>
>> >> Having read Ævar's latest comment, I've decided instead to drop this, so
>> >> feel free to do so whenever it's convenient.
>> >
>> > That's kind of sad.
>> 
>> Agreed. I mean, I'm just one contributor with an opinion. I certainly
>> don't mean my "meh" on a patch to be some sort of veto.
>> 
>> If you follow this list you'll see that if you're going to take anyone's
>> opinion on whether a thing should make it into git as a matter of
>> empirical data on patches I submit that aren't changed meaningfully,
>> then, uh, maybe pick someone else :)
>> 
>> > I view that this is the kind of topic where perfect easily can
>> > become an enemy of good, as there is by definition no perfection
>> > available to us without breaking existing Git.
>> >
>> > I do not know about Ævar, but to me, my initial impression while
>> > reading the discussion from sideline was that the goal was to
>> > prevent a mechanical scan of a recent version of .mailmap from
>> > learning that Joe used to use Jane as his/her name, and that was the
>> > reason why I asked to be convinced why encoding for obfuscation was
>> > insufficient.  In the above, I meant "mechanical scan" as something
>> > like "a web search engine crawls and finds a .mailmap---a query for
>> > Joe produces a line with some garbage on it that is not Jane." and a
>> > casual attacker would stop there.
>> >
>> > But of course, a casual attacker who knows urlencode or whatever
>> > obfuscation in use can read that "garbage" once he/she knows that
>> > "garbage" is worth attacking (i.e. it is known to be associated to
>> > Joe, the person the attacker is interested in).
>> >
>> > If your goal is to make it harder than just urlencode, even though
>> > we all have to accept that scanning "git log --all" for all names
>> > that appear in the history and hashing them all to see what name
>> > hashes to the "garbage" in question, then @sha256:<hash> approach
>> > does make sense as a stopping point.  Perhaps we need to sell this
>> > with a clear definition of what kind of attackes we are protecting
>> > the name data from:
>> >
>> >     The attacker is required to obtain sufficient amount of history
>> >     in the project to uncover the obfuscation; a more casual
>> >     attackers will fail to uncover, and we declare that it is better
>> >     than nothing and it is good enough in practice.
>> >
>> > or something like that?  I am not sure if I drew the line at the
>> > level you intended to draw in the above, if I think that it is good
>> > enough in practice, or if I agree to a change that is better than
>> > nothing but not good enough in practice, but having such a statement
>> > would help to see where we agree or disagree.
>> 
>> My reading of the general thread & brian's reply at [1] is that the
>> difference in the minds of the users who want the feature (who're not
>> on-list, and we're getting brian's's summary of their views) is closer
>> to:
>> 
>>     We want the X-Y problem of "hide this data" solved with solution "Y"
>>     because git's current tooling to retrieve the data is currently
>>     rather tedious & obscure.
>> 
>> So when I asked whether those users would feel the same if the tooling
>> was less tedious and suggested that I might patch it to be so brian
>> replied with "[yes,] we do rely on this being inconvenient".
>> 
>> I do have a 20-something series patch to the mailmap code in my local
>> queue that in the light of this series's status I think I'll submit
>> soon.
>> 
>> It doesn't have anything to do with adding a "spew out a materialized
>> map" feature currently, nor do I really plan to do that any time soon. I
>> do genuinely think it would be a good addition to git for reasons that
>> have nothing to do with trying to make a point about this
>> series. E.g. you'd be able to more easily validate/check/fsck a mailmap
>> that way. Or e.g. use a git repository's .mailmap as a source to export
>> to your MTA rules or whatever.
>> 
>> The external tools I referred to which consume the exported .mailmap
>> data are something I worked on at a previous job, but I no longer have
>> that immediate itch to scratch personally.
>> 
>> The "march of history" point was rather that if the difference between
>> URI encoding and this solution is current tooling, it seems all but
>> inevitable that we'll bridge that gap sooner than later in a way that
>> makes that difference useless to some of the users that want this now.
>> 
>> And not even because some people don't like this feature in particular
>> and wish to submit patches to make it less useful. But just because we
>> continue implementing stuff that's been talked about for years & is
>> being generally slowly worked towards. E.g. more client<->server
>> cooperation for expensive queries over protocol v2, or a filter clone
>> mode where you get only commit objects.
>> 
>> It even seems like something brian's series itself could benefit
>> from. I.e. having the hashed values in the history is a performance hit
>> in some cases. The patch caches the computation.
>> 
>> Another way to do it would be to just save a
>> ".git/objects/info/mailmap.{hash-of-original-file}". Either on the fly
>> or generated by "maintenance" or whatever. It would guarantee a 0%
>> performance hit. At that point we'd already have the plumbing to
>> materialize the file & would need to go out of our way to make it
>> inaccessible in porcelain.
>
> I've got quite a few sporadic thoughts about this series and this
> discussion, so I'll braindump and hopefully it turns into something
> useful.
>
> Firstly: this design comes from a conversation amongst a pretty small (4
> people? 6 people?) group at the virtual inclusion summit some months
> ago.

As a brief aside I did attend that virtual inclusion summit, but had to
mostly not attend it in practice for timezone reasons. So this was one
of the discussions/groups I managed to miss entirely.

There's some small joke in there somewhere about the inclusivity of the
inclusion summit being a function of how close you are to California :)

> At that time, we discussed the ease of brute-force decoding the
> one-way-hashed mailmap and decided that, as long as Git didn't ship a
> tool to do this for you for free, it was better than the current
> solution for avoiding deadnames (i.e. "sorry"). I'm disappointed to see
> the larger list feel otherwise, but not terribly surprised, since the
> list contains more people than the group who came up with the design.

I think it has less to do with the list containing more people, and more
to do with no versions of the patch making any mention of this idea or
approach implicitly relying on a forward promise that there never be
such a tool shipped with git.

Having found that out in trying to help this topic along I still think
that's very questionable approach in the terms of helping the users
you're concerned about.

For one what most people think about as "I'm looking at the thing in
Git" isn't UI controlled by us, but probably some website or Git GUI. So
any commitment we make about not implementing something in git.git is at
best going to be rather ineffective in the grand scheme of things.

But at least stating that upfront doesn't require the rest of us to read
minds.

And let's be clear, I'm not putting any blame on anyone's shoulders
(least of all brian's) for that. Just pointing out that our patch review
process works best when stated aims, caveats, implicit assumptions
etc. with a given technical are all clearly stated.

> [...]
> Thirdly: As is stated elsewhere, I think this topic is falling victim to
> perfect vs. good. Git is gaining increasing notoriety in circles I can
> see about the ultimately crappy experience for people who change their
> names and don't want to hear the old names (and don't want to know the
> old names). [...]

> So I feel sad to see the topic dropped because of pushback[...]

The topic is currently dropped because the submitted requested it to be
dropped (see <X/uvhc5Hpu792qA/@camp.crustytoothpaste.net> upthread,
https://lore.kernel.org/git/X%2Fuvhc5Hpu792qA%2F@camp.crustytoothpaste.net/). When
a submitter asks Junio to drop a topic he'll usually just do it. So it's
convenient because of any pushback from me or anyone else.

I'm only replying to this part because...

> [...] especially when that pushback is "I'd like to write a tool to
> reverse this thing, because <vague reasons> - and I don't mean that
> tool maliciously so that should be OK."

... this point in particular seems to be an attempt to summarize my
views or motivations.

I don't see how you could read my E-Mails on the subject (especially
what you're replying to,
https://lore.kernel.org/git/87k0si5k75.fsf@evledraar.gmail.com/) and
think that in any way reflects my views on the matter.

In lieu of repeating much/any of that I'll just say that that doesn't in
any way reflect my views, and from having read all the rest of the
message traffic associated with this topic I don't see who else you
could be referring to with those comments.

Re: What's cooking in git.git (Jan 2021, #02; Fri, 8)

[Jeff King]

On Sat, Jan 16, 2021 at 05:23:38PM +0100, Ævar Arnfjörð Bjarmason wrote:

> > [...] especially when that pushback is "I'd like to write a tool to
> > reverse this thing, because <vague reasons> - and I don't mean that
> > tool maliciously so that should be OK."
> 
> ... this point in particular seems to be an attempt to summarize my
> views or motivations.
> 
> I don't see how you could read my E-Mails on the subject (especially
> what you're replying to,
> https://lore.kernel.org/git/87k0si5k75.fsf@evledraar.gmail.com/) and
> think that in any way reflects my views on the matter.
> 
> In lieu of repeating much/any of that I'll just say that that doesn't in
> any way reflect my views, and from having read all the rest of the
> message traffic associated with this topic I don't see who else you
> could be referring to with those comments.

This is sort orthogonal to what you're saying here, and possibly I
missed this part of the discussion, but...I'm confused about this
talk of a tool for unblinding the mailmap. Isn't:

  git log --all --format='%aE %ae'

basically that tool already?

-Peff

Re: What's cooking in git.git (Jan 2021, #02; Fri, 8)

[Ævar Arnfjörð Bjarmason]

On Sun, Jan 17 2021, Jeff King wrote:

> On Sat, Jan 16, 2021 at 05:23:38PM +0100, Ævar Arnfjörð Bjarmason wrote:
>
>> > [...] especially when that pushback is "I'd like to write a tool to
>> > reverse this thing, because <vague reasons> - and I don't mean that
>> > tool maliciously so that should be OK."
>> 
>> ... this point in particular seems to be an attempt to summarize my
>> views or motivations.
>> 
>> I don't see how you could read my E-Mails on the subject (especially
>> what you're replying to,
>> https://lore.kernel.org/git/87k0si5k75.fsf@evledraar.gmail.com/) and
>> think that in any way reflects my views on the matter.
>> 
>> In lieu of repeating much/any of that I'll just say that that doesn't in
>> any way reflect my views, and from having read all the rest of the
>> message traffic associated with this topic I don't see who else you
>> could be referring to with those comments.
>
> This is sort orthogonal to what you're saying here, and possibly I
> missed this part of the discussion, but...I'm confused about this
> talk of a tool for unblinding the mailmap. Isn't:
>
>   git log --all --format='%aE %ae'
>
> basically that tool already?

Yes, but I belive from brian's mails on the topic[1][2][3] that the
issue at hand is that doing that is just the right level of
inconvienience in the minds of the users who want this feature, and that
e.g. having some/any of:

    git check-mailmap --porcelain --materialize-hashed
    git for-each-mailmap --format="%(authornamefrom:unhashed) %(authoremailfrom:unhashed) %(authornameto)"
    git ask-remote https://github.com/chromium/chromium -- <that for-each-mailmap-command> # (or whatever..)
    <open .mailmap in your $EDITOR and see/edit/save only materialized values>

Would tip it over the edge into the territory of this
socially-signalled-to-be-private information being too convenient to
extract from the DAG.

1. https://lore.kernel.org/git/X%2FtxB8b3%2FqqbwbmC@camp.crustytoothpaste.net/
2. https://lore.kernel.org/git/YADh2DHDrdAs6Jbj@camp.crustytoothpaste.net/
3. https://lore.kernel.org/git/X9xEnpLeZ4mCjwWF@coredump.intra.peff.net/