{"thread":{"id":"54964","subject":"What's cooking in git.git (Jan 2021, #02; Fri, 8)","startedAt":"2021-01-08T19:23:35Z","lastAt":"2021-01-17T20:23:43Z","messageCount":34,"participants":["Junio C Hamano","Ævar Arnfjörð Bjarmason","David Aguilar","brian m. carlson","Emily Shaffer","Taylor Blau","Derrick Stolee","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"413867","messageId":"xmqqk0sni68g.fsf@gitster.c.googlers.com","threadId":"54964","inReplyTo":null,"subject":"What's cooking in git.git (Jan 2021, #02; Fri, 8)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-01-08T19:22:23Z","receivedAt":"2021-01-08T19:23:35Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Here are the topics that have been cooking. Commits prefixed with '-' are\nonly in 'seen' (formerly 'pu'---proposed updates) while commits prefixed\nwith '+' are in 'next'. The ones marked with '.' do not appear in any of\nthe integration branches, but I am still holding onto them.\n\nMany topics that have been cooking in the 'next' branch during the\npre-release freeze at the year end have now been merged to the\n'master' branch, and the tip of the 'next' branch has been rewound.\n\nThe \".gitignore or .gitattributes cannot be a symlink\" topic has\nbeen ejected out of 'next' for now. We do want to resurrect it\npossibly with some opt-in loosening of the rule.\n\nCopies of the source code to Git live in many repositories, and the\nfollowing is a list of the ones I push into or their mirrors. Some\nrepositories have only a subset of branches.\n\nWith maint, master, next, seen, todo:\n\n\tgit://git.kernel.org/pub/scm/git/git.git/\n\tgit://repo.or.cz/alt-git.git/\n\thttps://kernel.googlesource.com/pub/scm/git/git/\n\thttps://github.com/git/git/\n\thttps://gitlab.com/git-vcs/git/\n\nWith all the integration branches and topics broken out:\n\n\thttps://github.com/gitster/git/\n\nEven though the preformatted documentation in HTML and man format\nare not sources, they are published in these repositories for\nconvenience (replace \"htmldocs\" with \"manpages\" for the manual\npages):\n\n\tgit://git.kernel.org/pub/scm/git/git-htmldocs.git/\n\thttps://github.com/gitster/git-htmldocs.git/\n\nRelease tarballs are available at:\n\n\thttps://www.kernel.org/pub/software/scm/git/\n\n--------------------------------------------------\n[New Topics]\n\n* en/ort-directory-rename (2021-01-07) 18 commits\n - merge-ort: fix a directory rename detection bug\n - merge-ort: process_renames() now needs more defensiveness\n - merge-ort: implement apply_directory_rename_modifications()\n - merge-ort: add a new toplevel_dir field\n - merge-ort: implement handle_path_level_conflicts()\n - merge-ort: implement check_for_directory_rename()\n - merge-ort: implement apply_dir_rename() and check_dir_renamed()\n - merge-ort: implement compute_collisions()\n - merge-ort: modify collect_renames() for directory rename handling\n - merge-ort: implement handle_directory_level_conflicts()\n - merge-ort: implement compute_rename_counts()\n - merge-ort: copy get_renamed_dir_portion() from merge-recursive.c\n - merge-ort: add outline of get_provisional_directory_renames()\n - merge-ort: add outline for computing directory renames\n - merge-ort: collect which directories are removed in dirs_removed\n - merge-ort: initialize and free new directory rename data structures\n - merge-ort: add new data structures for directory rename detection\n - Merge branch 'en/merge-ort-3' into en/ort-directory-rename\n (this branch uses en/merge-ort-3.)\n\n ORT merge strategy learns to infer \"renamed directory\" while\n merging.\n\n\n* jk/forbid-lf-in-git-url (2021-01-07) 2 commits\n - fsck: reject .gitmodules git:// urls with newlines\n - git_connect_git(): forbid newlines in host and path\n\n Newline characters in the host and path part of git:// URL are\n now forbidden.\n\n Will merge to 'next'.\n\n\n* ps/fetch-atomic (2021-01-07) 2 commits\n - fetch: implement support for atomic reference updates\n - fetch: allow passing a transaction to `s_update_ref()`\n\n \"git fetch\" learns to treat ref updates atomically in all-or-none\n fashion, just like \"git push\" does, with the new \"--atomic\" option.\n\n\n* jc/sign-off (2021-01-07) 1 commit\n - SubmittingPatches: tighten wording on \"sign-off\" procedure\n\n Doc update.\n\n Will merge to 'next'.\n\n--------------------------------------------------\n[Graduated to 'master']\n\n* ab/trailers-extra-format (2020-12-09) 5 commits\n (merged to 'next' on 2020-12-14 at 9fc731944e)\n + pretty format %(trailers): add a \"key_value_separator\"\n + pretty format %(trailers): add a \"keyonly\"\n + pretty-format %(trailers): fix broken standalone \"valueonly\"\n + pretty format %(trailers) doc: avoid repetition\n + pretty format %(trailers) test: split a long line\n\n The \"--format=%(trailers)\" mechanism gets enhanced to make it\n easier to design output for machine consumption.\n\n\n* en/merge-ort-2 (2020-12-13) 7 commits\n (merged to 'next' on 2020-12-21 at ef5b184349)\n + merge-ort: add modify/delete handling and delayed output processing\n + merge-ort: add die-not-implemented stub handle_content_merge() function\n + merge-ort: add function grouping comments\n + merge-ort: add a paths_to_free field to merge_options_internal\n + merge-ort: add a path_conflict field to merge_options_internal\n + merge-ort: add a clear_internal_opts helper\n + merge-ort: add a few includes\n (this branch is used by en/merge-ort-3, en/merge-ort-recursive and en/ort-conflict-handling; uses en/merge-ort-impl.)\n\n More \"ORT\" merge strategy.\n\n\n* en/merge-ort-impl (2020-12-13) 21 commits\n (merged to 'next' on 2020-12-21 at c551d7bda9)\n + merge-ort: free data structures in merge_finalize()\n + merge-ort: add implementation of record_conflicted_index_entries()\n + tree: enable cmp_cache_name_compare() to be used elsewhere\n + merge-ort: add implementation of checkout()\n + merge-ort: basic outline for merge_switch_to_result()\n + merge-ort: step 3 of tree writing -- handling subdirectories as we go\n + merge-ort: step 2 of tree writing -- function to create tree object\n + merge-ort: step 1 of tree writing -- record basenames, modes, and oids\n + merge-ort: have process_entries operate in a defined order\n + merge-ort: add a preliminary simple process_entries() implementation\n + merge-ort: avoid recursing into identical trees\n + merge-ort: record stage and auxiliary info for every path\n + merge-ort: compute a few more useful fields for collect_merge_info\n + merge-ort: avoid repeating fill_tree_descriptor() on the same tree\n + merge-ort: implement a very basic collect_merge_info()\n + merge-ort: add an err() function similar to one from merge-recursive\n + merge-ort: use histogram diff\n + merge-ort: port merge_start() from merge-recursive\n + merge-ort: add some high-level algorithm structure\n + merge-ort: setup basic internal data structures\n + Merge branch 'en/strmap' into en/merge-ort-impl\n (this branch is used by en/merge-ort-2, en/merge-ort-3, en/merge-ort-recursive and en/ort-conflict-handling.)\n\n The merge backend \"done right\" starts to emerge.\n\n\n* en/merge-ort-recursive (2020-12-16) 4 commits\n (merged to 'next' on 2020-12-22 at 0dbf60011f)\n + merge-ort: implement merge_incore_recursive()\n + merge-ort: make clear_internal_opts() aware of partial clearing\n + merge-ort: copy a few small helper functions from merge-recursive.c\n + commit: move reverse_commit_list() from merge-recursive\n (this branch uses en/merge-ort-2 and en/merge-ort-impl; is tangled with en/merge-ort-3 and en/ort-conflict-handling.)\n\n The ORT merge strategy learned to synthesize virtual ancestor tree\n by recursively merging multiple merge bases together, just like the\n recursive backend has done for years.\n\n\n* es/perf-export-fix (2020-12-22) 1 commit\n (merged to 'next' on 2020-12-22 at d06b0379d9)\n + t/perf: avoid unnecessary test_export() recursion\n\n Tweak unneeded recursion from a test framework helper function.\n\n\n* es/worktree-repair-both-moved (2020-12-21) 1 commit\n (merged to 'next' on 2020-12-22 at 9eaae4f5c0)\n + worktree: teach `repair` to fix multi-directional breakage\n\n \"git worktree repair\" learned to deal with the case where both the\n repository and the worktree moved.\n\n\n* fc/pull-merge-rebase (2020-12-15) 5 commits\n (merged to 'next' on 2020-12-21 at acce13e5c4)\n + pull: display default warning only when non-ff\n + pull: correct condition to trigger non-ff advice\n + pull: get rid of unnecessary global variable\n + pull: give the advice for choosing rebase/merge much later\n + pull: refactor fast-forward check\n\n When a user does not tell \"git pull\" to use rebase or merge, the\n command gives a loud message telling a user to choose between\n rebase or merge but creates a merge anyway, forcing users who would\n want to rebase to redo the operation. Fix an early part of this\n problem by tightening the condition to give the message---there is\n no reason to stop or force the user to choose between rebase or\n merge if the history fast-forwards.\n\n\n* fc/t6030-bisect-reset-removes-auxiliary-files (2020-12-21) 1 commit\n (merged to 'next' on 2020-12-22 at 2ab78ef1e1)\n + test: bisect-porcelain: fix location of files\n\n A 3-year old test that was not testing anything useful has been\n corrected.\n\n\n* pk/subsub-fetch-fix-take-2 (2020-12-09) 1 commit\n (merged to 'next' on 2020-12-14 at ccc01a5f66)\n + submodules: fix of regression on fetching of non-init subsub-repo\n\n \"git fetch --recurse-submodules\" fix (second attempt).\n\n\n* tb/pack-bitmap (2020-12-08) 24 commits\n (merged to 'next' on 2020-12-15 at 773268c2fb)\n + pack-bitmap-write: better reuse bitmaps\n + pack-bitmap-write: relax unique revwalk condition\n + pack-bitmap-write: use existing bitmaps\n + pack-bitmap: factor out 'add_commit_to_bitmap()'\n + pack-bitmap: factor out 'bitmap_for_commit()'\n + pack-bitmap-write: ignore BITMAP_FLAG_REUSE\n + pack-bitmap-write: build fewer intermediate bitmaps\n + pack-bitmap.c: check reads more aggressively when loading\n + pack-bitmap-write: rename children to reverse_edges\n + t5310: add branch-based checks\n + commit: implement commit_list_contains()\n + bitmap: implement bitmap_is_subset()\n + pack-bitmap-write: fill bitmap with commit history\n + pack-bitmap-write: pass ownership of intermediate bitmaps\n + pack-bitmap-write: reimplement bitmap writing\n + ewah: add bitmap_dup() function\n + ewah: implement bitmap_or()\n + ewah: make bitmap growth less aggressive\n + ewah: factor out bitmap growth\n + rev-list: die when --test-bitmap detects a mismatch\n + t5310: drop size of truncated ewah bitmap\n + pack-bitmap: bounds-check size of cache extension\n + pack-bitmap: fix header size check\n + ewah/ewah_bitmap.c: avoid open-coding ALLOC_GROW()\n\n Various improvements to the codepath that writes out pack bitmaps.\n\n--------------------------------------------------\n[Stalled]\n\n* ss/submodule-add-in-c (2020-12-15) 3 commits\n . t7400: add test to check 'submodule add' for tracked paths\n . submodule: port submodule subcommand 'add' from shell to C\n . dir: change the scope of function 'directory_exists_in_index()'\n\n \"git submodule add\" being rewritten in C.\n\n Expecting a reroll.\n The patches are split incorrectly; part of 1/3 belongs to 2/3\n cf. \n It seems to introduce a segfault on 'seen'.\n cf. \n\n\n* mt/grep-sparse-checkout (2020-12-06) 10 commits\n - t7817: do not depend on any specific default branch name\n - config: add setting to ignore sparsity patterns in some cmds\n - grep: honor sparse checkout patterns\n - config: correctly read worktree configs in submodules\n - config: make do_git_config_sequence receive a 'struct repository'\n - t/helper/test-config: unify exit labels\n - t/helper/test-config: diagnose missing arguments\n - t/helper/test-config: be consistent with exit codes\n - t1308-config-set: avoid false positives when using test-config\n - doc: grep: unify info on configuration variables\n (this branch is used by mt/rm-sparse-checkout.)\n\n \"git grep\" has been tweaked to be limited to the sparse checkout\n paths.\n\n Break out and fast-track bugfix from the remainder of the topic.\n cf. \n\n\n* mt/rm-sparse-checkout (2020-12-08) 1 commit\n - rm: honor sparse checkout patterns\n (this branch uses mt/grep-sparse-checkout.)\n\n \"git rm\" follows suit to \"git grep\" to ignore paths outside the\n sparsity pattern when the sparse checkout feature is in use.\n\n Need to wait for how these fit in larger picture.\n cf. \n cf. \n\n\n* jk/symlinked-dotgitx-files (2020-10-23) 9 commits\n - docs: document symlink restrictions for .git* files\n - fsck: complain when .gitattributes or .gitignore is a symlink\n - verify_path(): disallow symlinks in .gitattributes and .gitignore\n - t0060: test obscured .gitattributes and .gitignore matching\n - t7450: test .gitmodules symlink matching against obscured names\n - t7450: test verify_path() handling of gitmodules\n - t7415: rename to expand scope\n - fsck_tree(): wrap some long lines\n - fsck_tree(): fix shadowed variable\n\n \"git fsck\" and the corresponding check done during the transport\n learned to ensure that in-tree files like `.gitignore` and\n `.gitattributes` are not symbolic links.\n\n It seems that there are real projects with .gitignore recorded as\n symlinks, which may need to loosen the fsck setting. Do we need to\n introduce a class that is separate from symlinked .gitmodules that\n has potential consequences that is more/less grave, so that these\n projects can opt out of the new checks?\n\n\n* sm/curl-retry (2020-10-13) 3 commits\n - http: automatically retry some requests\n - replace CURLOPT_FILE With CURLOPT_WRITEDATA\n - remote-curl: add testing for intelligent retry for HTTP\n\n The http transport has been taught to retry a failed request that\n may reasonably be retried.\n\n Expecting a reroll.\n cf. <20201015000410.GB328643@google.com>\n cf. \n\n\n* sv/t7001-modernize (2020-09-25) 11 commits\n - t7001: move cleanup code from outside the tests into them\n - t7001: use `test` rather than `[`\n - t7001: use here-docs instead of echo\n - t7001: put each command on a separate line\n - t7001: use ': >' rather than 'touch'\n - t7001: change (cd && git foo) to (git -C foo)\n - t7001: remove whitespace after redirect operators\n - t7001: change the style for cd according to subshell\n - t7001: remove unnecessary blank lines\n - t7001: use TAB instead of spaces\n - t7001: convert tests from the old style to the current style\n\n Test script modernization.\n\n Expecting a reroll.\n cf. <20200925170256.11490-1-shubhunic@gmail.com>\n\n\n* ar/fetch-transfer-ipversion (2020-09-16) 1 commit\n - config: option transfer.ipversion to set transport protocol version for network fetches\n\n Adds transfer.ipversion configuration variable.\n\n Needs more work.\n\n\n* jc/war-on-dashed-git (2020-12-21) 2 commits\n - fixup??? git: catch an attempt to run \"git-foo\"\n - git: catch an attempt to run \"git-foo\"\n\n The first step to remove on-disk binaries for built-in subcommands\n by soliciting objections.\n\n On hold for now.\n\n\n* mk/use-size-t-in-zlib (2018-10-15) 1 commit\n - zlib.c: use size_t for size\n\n The wrapper to call into zlib followed our long tradition to use\n \"unsigned long\" for sizes of regions in memory, which have been\n updated to use \"size_t\".\n\n\n* ag/merge-strategies-in-c (2020-11-24) 13 commits\n - sequencer: use the \"octopus\" merge strategy without forking\n - sequencer: use the \"resolve\" strategy without forking\n - merge: use the \"octopus\" strategy without forking\n - merge: use the \"resolve\" strategy without forking\n - merge-octopus: rewrite in C\n - merge-recursive: move better_branch_name() to merge.c\n - merge-resolve: rewrite in C\n - merge-index: don't fork if the requested program is `git-merge-one-file'\n - merge-index: libify merge_one_path() and merge_all()\n - merge-one-file: rewrite in C\n - update-index: move add_cacheinfo() to read-cache.c\n - t6060: modify multiple files to expose a possible issue with merge-index\n - t6407: modernise tests\n\n The resolve and octopus merge strategy backends have been rewritten\n in C.\n\n Got enough review comments to get updated.\n\n--------------------------------------------------\n[Cooking]\n\n* vv/send-email-with-less-secure-apps-access (2021-01-07) 1 commit\n - git-send-email.txt: mention less secure app access with Gmail\n\n Doc update.\n\n Will merge to 'next'.\n\n\n* ab/branch-sort (2021-01-07) 7 commits\n - branch: show \"HEAD detached\" first under reverse sort\n - branch: sort detached HEAD based on a flag\n - ref-filter: move ref_sorting flags to a bitfield\n - ref-filter: move \"cmp_fn\" assignment into \"else if\" arm\n - ref-filter: add braces to if/else if/else chain\n - branch tests: add to --sort tests\n - branch: change \"--local\" to \"--list\" in comment\n\n The implementation of \"git branch --sort\" wrt the detached HEAD\n display has always been hacky, which has been cleaned up.\n\n Will merge to 'next'.\n\n\n* ab/coc-update-to-2.0 (2021-01-07) 3 commits\n - CoC: update to version 2.0 + local changes\n - CoC: explicitly take any whitespace breakage\n - CoC: Update word-wrapping to match upstream\n\n Update the Code-of-conduct to version 2.0 from the upstream (we've\n been using version 1.4).\n\n The first step needs to be signed off by the author, and like the\n original discussion thread back in Sep 2019, it also needs to\n collect acks from list regulars to show support.\n\n\n* ar/t6016-modernise (2021-01-04) 1 commit\n (merged to 'next' on 2021-01-08 at 45f1b43e88)\n + t6016: move to lib-log-graph.sh framework\n\n Test update.\n\n Will merge to 'master'.\n\n\n* dl/reflog-with-single-entry (2021-01-07) 2 commits\n - refs: allow @{n} to work with n-sized reflog\n - refs: factor out set_read_ref_cutoffs()\n\n After expiring a reflog and making a single commit, the reflog for\n the branch would record a single entry that knows both @{0} and\n @{1}, but we failed to answer \"what commit were we on?\", i.e. @{1}\n\n\n* ds/cache-tree-basics (2021-01-07) 10 commits\n - cache-tree: speed up consecutive path comparisons\n - cache-tree: use ce_namelen() instead of strlen()\n - index-format: discuss recursion of cached-tree better\n - index-format: update preamble to cache tree extension\n - index-format: use 'cache tree' over 'cached tree'\n - cache-tree: trace regions for prime_cache_tree\n - cache-tree: trace regions for I/O\n - cache-tree: use trace2 in cache_tree_update()\n - unpack-trees: add trace2 regions\n - tree-walk: report recursion counts\n\n Document, clean-up and optimize the code around the cache-tree\n extension in the index.\n\n\n* ds/for-each-repo-noopfix (2021-01-07) 1 commit\n - for-each-repo: do nothing on empty config\n\n \"git for-each-repo --config= \" should not run for\n any repository when the configuration variable is not defined\n even once.\n\n Will merge to 'next'.\n\n\n* ds/trace2-topo-walk (2021-01-04) 1 commit\n (merged to 'next' on 2021-01-08 at 794c8f37ee)\n + revision: trace topo-walk statistics\n\n The topological walk codepath is covered by new trace2 stats.\n\n Will merge to 'master'.\n\n\n* en/ort-conflict-handling (2021-01-04) 10 commits\n - merge-ort: add handling for different types of files at same path\n - merge-ort: copy find_first_merges() implementation from merge-recursive.c\n - merge-ort: implement format_commit()\n - merge-ort: copy and adapt merge_submodule() from merge-recursive.c\n - merge-ort: copy and adapt merge_3way() from merge-recursive.c\n - merge-ort: flesh out implementation of handle_content_merge()\n - merge-ort: handle book-keeping around two- and three-way content merge\n - merge-ort: implement unique_path() helper\n - merge-ort: handle directory/file conflicts that remain\n - merge-ort: handle D/F conflict where directory disappears due to merge\n\n ORT merge strategy learns more support for merge conflicts.\n\n\n* fc/completion-aliases-support (2021-01-04) 4 commits\n (merged to 'next' on 2021-01-08 at b2714ff1a4)\n + completion: add proper public __git_complete\n + test: completion: add tests for __git_complete\n + completion: bash: improve function detection\n + completion: bash: add __git_have_func helper\n\n Bash completion (in contrib/) update to make it easier for\n end-users to add completion for their custom \"git\" subcommands.\n\n Will merge to 'master'.\n\n\n* ma/doc-pack-format-varint-for-sizes (2021-01-04) 1 commit\n (merged to 'next' on 2021-01-08 at 8a448c50dd)\n + pack-format.txt: document sizes at start of delta data\n\n Doc update.\n\n Will merge to 'master'.\n\n\n* ma/more-opaque-lock-file (2021-01-06) 5 commits\n - read-cache: try not to peek into `struct {lock_,temp}file`\n - refs/files-backend: don't peek into `struct lock_file`\n - midx: don't peek into `struct lock_file`\n - commit-graph: don't peek into `struct lock_file`\n - builtin/gc: don't peek into `struct lock_file`\n\n Code clean-up.\n\n Will merge to 'next'.\n\n\n* ma/sha1-is-a-hash (2021-01-04) 4 commits\n (merged to 'next' on 2021-01-08 at a25537f7c3)\n + hash-lookup: rename from sha1-lookup\n + sha1-lookup: rename `sha1_pos()` as `hash_pos()`\n + object-file.c: rename from sha1-file.c\n + object-name.c: rename from sha1-name.c\n\n Retire more names with \"sha1\" in it.\n\n Will merge to 'master'.\n\n\n* ma/t1300-cleanup (2021-01-04) 3 commits\n (merged to 'next' on 2021-01-08 at 51aaae39a1)\n + t1300: don't needlessly work with `core.foo` configs\n + t1300: remove duplicate test for `--file no-such-file`\n + t1300: remove duplicate test for `--file ../foo`\n\n Code clean-up.\n\n Will merge to 'master'.\n\n\n* mt/t4129-with-setgid-dir (2021-01-06) 1 commit\n - t4129: don't fail if setgid is set in the test directory\n\n Some tests expect that \"ls -l\" output has either '-' or 'x' for\n group executable bit, but setgid bit can be inherited from parent\n directory and make these fields 'S' or 's' instead, causing test\n failures.\n\n Will merge to 'next'.\n\n\n* nk/perf-fsmonitor-cleanup (2021-01-06) 1 commit\n (merged to 'next' on 2021-01-08 at 1837d6c30b)\n + p7519: allow running without watchman prereq\n\n Test fix.\n\n Will merge to 'master'.\n\n\n* pb/doc-modules-git-work-tree-typofix (2021-01-04) 1 commit\n (merged to 'next' on 2021-01-08 at a67ab3e96a)\n + gitmodules.txt: fix 'GIT_WORK_TREE' variable name\n\n Doc fix.\n\n Will merge to 'master'.\n\n\n* pb/mergetool-tool-help-fix (2021-01-06) 1 commit\n - mergetool--lib: fix '--tool-help' to correctly show available tools\n\n Fix 2.29 regression where \"git mergetool --tool-help\" fails to list\n all the available tools.\n\n Will merge to 'next'.\n\n\n* rs/rebase-commit-validation (2021-01-04) 1 commit\n (merged to 'next' on 2021-01-08 at 2c63eb1cc8)\n + rebase: verify commit parameter\n\n Diagnose command line error early.\n\n Will merge to 'master'.\n\n\n* sg/t7800-difftool-robustify (2021-01-04) 1 commit\n . t7800-difftool: don't accidentally match tmp dirs\n\n Test fix.\n\n Not working on Windows.\n cf. https://github.com/git/git/runs/1660588243?check_suite_focus=true#step:7:4186\n\n\n* ta/doc-typofix (2021-01-04) 1 commit\n (merged to 'next' on 2021-01-08 at 1e579ef94f)\n + doc: fix some typos\n\n Doc fix.\n\n Will merge to 'master'.\n\n\n* zh/arg-help-format (2021-01-06) 2 commits\n (merged to 'next' on 2021-01-08 at 208c98620c)\n + builtin/*: update usage format\n + parse-options: format argh like error messages\n\n Clean up option descriptions in \"git cmd --help\".\n\n Will merge to 'master'.\n\n\n* ak/corrected-commit-date (2021-01-04) 11 commits\n - doc: add corrected commit date info\n - commit-reach: use corrected commit dates in paint_down_to_common()\n - commit-graph: use generation v2 only if entire chain does\n - commit-graph: implement generation data chunk\n - commit-graph: implement corrected commit date\n - commit-graph: return 64-bit generation number\n - commit-graph: add a slab to store topological levels\n - t6600-test-reach: generalize *_three_modes\n - commit-graph: consolidate fill_commit_graph_info\n - revision: parse parent in indegree_walk_step()\n - commit-graph: fix regression when computing Bloom filters\n\n The commit-graph learned to use corrected commit dates instead of\n the generation number to help topological revision traversal.\n\n Getting there, but not needs more help to find and resolve segv.\n cf. <1adabda6-b80b-d543-f6c0-570dadbe589b@gmail.com>\n\n\n* dl/p4-encode-after-kw-expansion (2020-12-23) 1 commit\n - git-p4: fix syncing file types with pattern\n\n Text encoding fix for \"git p4\".\n\n\n* fc/mergetool-automerge (2021-01-06) 5 commits\n . mergetool: add automerge_enabled tool-specific override function\n . mergetool: break setup_tool out into separate initialization function\n . mergetool: add per-tool support for the autoMerge flag\n . mergetool: alphabetize the mergetool config docs\n . mergetool: add automerge configuration\n\n \"git mergetool\" feeds three versions (base, local and remote) of\n a conflicted path unmodified. The command learned to optionally\n prepare these files with unconflicted parts already resolved.\n\n Breaks tests on macOS.\n cf. https://github.com/git/git/runs/1659807735?check_suite_focus=true#step:4:1641\n\n\n* ew/decline-core-abbrev (2020-12-23) 1 commit\n (merged to 'next' on 2021-01-08 at 630dd186a4)\n + core.abbrev=no disables abbreviations\n\n Allow the configuration to specify no abbreviation regardless of\n the hash algorithm.\n\n Will merge to 'master'.\n\n\n* mr/bisect-in-c-4 (2020-12-21) 7 commits\n - bisect--helper: retire `--check-and-set-terms` subcommand\n - bisect--helper: reimplement `bisect_skip` shell function in C\n - bisect--helper: retire `--bisect-auto-next` subcommand\n - bisect--helper: use `res` instead of return in BISECT_RESET case option\n - bisect--helper: retire `--bisect-write` subcommand\n - bisect--helper: reimplement `bisect_replay` shell function in C\n - bisect--helper: reimplement `bisect_log` shell function in C\n\n Piecemeal of rewrite of \"git bisect\" in C continues.\n\n What's the status of this thing?\n\n\n* jt/clone-unborn-head (2020-12-22) 3 commits\n - clone: respect remote unborn HEAD\n - connect, transport: add no-op arg for future patch\n - ls-refs: report unborn targets of symrefs\n\n \"git clone\" tries to locally check out the branch pointed at by\n HEAD of the remote repository after it is done, but the protocol\n did not convey the information necessary to do so when copying an\n empty repository. The protocol v2 learned how to do so.\n\n What's the status of this thing?\n\n\n* fc/bash-completion-post-2.29 (2020-12-23) 4 commits\n - completion: bash: add correct suffix in variables\n - completion: bash: fix for multiple dash commands\n - completion: bash: fix for suboptions with value\n - completion: bash: fix prefix detection in branch.*\n\n Seems to break tests on Windows\n\n\n* jc/deprecate-pack-redundant (2020-12-15) 1 commit\n - pack-redundant: gauge the usage before proposing its removal\n\n Warn loudly when the \"pack-redundant\" command, which has been left\n stale with almost unusable performance issues, gets used, as we no\n longer want to recommend its use (instead just \"repack -d\" instead).\n\n Will merge to 'next'.\n\n\n* mt/parallel-checkout-part-1 (2020-12-16) 9 commits\n - entry: add checkout_entry_ca() taking preloaded conv_attrs\n - entry: move conv_attrs lookup up to checkout_entry()\n - entry: extract update_ce_after_write() from write_entry()\n - entry: make fstat_output() and read_blob_entry() public\n - entry: extract a header file for entry.c functions\n - convert: add classification for conv_attrs struct\n - convert: add get_stream_filter_ca() variant\n - convert: add [async_]convert_to_working_tree_ca() variants\n - convert: make convert_attrs() and convert structs public\n\n Parallel checkout.\n\n Looking good.\n\n\n* en/merge-ort-3 (2020-12-15) 11 commits\n (merged to 'next' on 2021-01-08 at fe481b9627)\n + merge-ort: add implementation of type-changed rename handling\n + merge-ort: add implementation of normal rename handling\n + merge-ort: add implementation of rename collisions\n + merge-ort: add implementation of rename/delete conflicts\n + merge-ort: add implementation of both sides renaming differently\n + merge-ort: add implementation of both sides renaming identically\n + merge-ort: add basic outline for process_renames()\n + merge-ort: implement compare_pairs() and collect_renames()\n + merge-ort: implement detect_regular_renames()\n + merge-ort: add initial outline for basic rename detection\n + merge-ort: add basic data structures for handling renames\n (this branch is used by en/ort-directory-rename.)\n\n Rename detection is added to the \"ORT\" merge strategy.\n\n Will merge to 'master'.\n\n\n* ps/config-env-pairs (2021-01-06) 8 commits\n - config: allow specifying config entries via envvar pairs\n - environment: make `getenv_safe()` a public function\n - config: parse more robust format in GIT_CONFIG_PARAMETERS\n - config: store \"git -c\" variables using more robust format\n - config: extract function to parse config pairs\n - quote: make sq_dequote_step() a public function\n - config: add new way to pass config via `--config-env`\n - git: add `--super-prefix` to usage string\n\n Introduce two new ways to feed configuration variable-value pairs\n via environment variables, and tweak the way GIT_CONFIG_PARAMETERS\n encodes variable/value pairs to make it more robust.\n\n Ready for 'next'?\n\n\n* bc/hashed-mailmap (2020-12-12) 1 commit\n - mailmap: support hashed entries in mailmaps\n\n The mailmap database learned to take hashed value as the original\n side of mapping.\n\n Expecting a reroll.\n\n\n* so/log-diff-merge (2020-12-21) 32 commits\n - t4013: add tests for --diff-merges=first-parent\n - doc/git-show: include --diff-merges description\n - doc/rev-list-options: document --first-parent changes merges format\n - doc/diff-generate-patch: mention new --diff-merges option\n - doc/git-log: describe new --diff-merges options\n - diff-merges: add '--diff-merges=1' as synonym for 'first-parent'\n - diff-merges: add old mnemonic counterparts to --diff-merges\n - diff-merges: let new options enable diff without -p\n - diff-merges: do not imply -p for new options\n - diff-merges: implement new values for --diff-merges\n - diff-merges: make -m/-c/--cc explicitly mutually exclusive\n - diff-merges: refactor opt settings into separate functions\n - diff-merges: get rid of now empty diff_merges_init_revs()\n - diff-merges: group diff-merge flags next to each other inside 'rev_info'\n - diff-merges: split 'ignore_merges' field\n - diff-merges: fix -m to properly override -c/--cc\n - t4013: add tests for -m failing to override -c/--cc\n - t4013: support test_expect_failure through ':failure' magic\n - diff-merges: revise revs->diff flag handling\n - diff-merges: handle imply -p on -c/--cc logic for log.c\n - diff-merges: introduce revs->first_parent_merges flag\n - diff-merges: new function diff_merges_set_dense_combined_if_unset()\n - diff-merges: new function diff_merges_suppress()\n - diff-merges: re-arrange functions to match the order they are called in\n - diff-merges: rename diff_merges_default_to_enable() to match semantics\n - diff-merges: move checks for first_parent_only out of the module\n - diff-merges: rename all functions to have common prefix\n - revision: move diff merges functions to its own diff-merges.c\n - revision: provide implementation for diff merges tweaks\n - revision: factor out initialization of diff-merge related settings\n - revision: factor out setup of diff-merge related settings\n - revision: factor out parsing of diff-merge related options\n\n \"git log\" learned a new \"--diff-merges=\" option.\n\n Rerolled.\n\n\n* bc/rev-parse-path-format (2020-12-12) 2 commits\n (merged to 'next' on 2021-01-08 at 7d51587b7f)\n + rev-parse: add option for absolute or relative path formatting\n + abspath: add a function to resolve paths with missing components\n\n \"git rev-parse\" can be explicitly told to give output as absolute\n or relative path.\n\n Will merge to 'master'.\n\n\n* es/config-hooks (2020-12-21) 34 commits\n - run-command: stop thinking about hooks\n - receive-pack: convert receive hooks to hook.h\n - post-update: use hook.h library\n - proc-receive: acquire hook list from hook.h\n - receive-pack: convert 'update' hook to hook.h\n - reference-transaction: look for hooks in config\n - transport: convert pre-push hook to use config\n - hook: convert 'post-rewrite' hook to config\n - hooks: convert 'post-checkout' hook to hook library\n - git-p4: use 'git hook' to run hooks\n - receive-pack: convert push-to-checkout hook to hook.h\n - read-cache: convert post-index-change hook to use config\n - rebase: teach pre-rebase to use hook.h\n - gc: use hook library for pre-auto-gc hook\n - merge: use config-based hooks for post-merge hook\n - am: convert applypatch hooks to use config\n - commit: use config-based hooks\n - hooks: allow callers to capture output\n - run-command: allow capturing of collated output\n - hook: provide stdin by string_list or callback\n - run-command: add stdin callback for parallelization\n - hook: allow specifying working directory for hooks\n - hook: allow parallel hook execution\n - run-command: allow stdin for run_processes_parallel\n - hook: support passing stdin to hooks\n - hook: replace find_hook() with hook_exists()\n - hook: add 'run' subcommand\n - parse-options: parse into strvec\n - hook: implement hookcmd..skip\n - hook: respect hook.runHookDir\n - hook: include hookdir hook in list\n - hook: add list command\n - hook: scaffolding for git-hook subcommand\n - doc: propose hooks managed by the config\n\n The \"hooks defined in config\" topic.\n\n Expecting doc updates, but otherwise seems to be progressing nicely.\n\n\n* hn/reftable (2020-12-21) 16 commits\n - SQUASH??? allow t0031 to run with any default branch name\n - Add \"test-tool dump-reftable\" command.\n - git-prompt: prepare for reftable refs backend\n - Reftable support for git-core\n - reftable: rest of library\n - reftable: reftable file level tests\n - reftable: read reftable files\n - reftable: write reftable files\n - reftable: a generic binary tree implementation\n - reftable: reading/writing blocks\n - reftable: (de)serialization for the polymorphic record type.\n - reftable: add blocksource, an abstraction for random access reads\n - reftable: utility functions\n - reftable: add error related functionality\n - reftable: add LICENSE\n - init-db: set the_repository->hash_algo early on\n\n The \"reftable\" backend for the refs API.\n\n\n* ab/mktag (2021-01-06) 23 commits\n (merged to 'next' on 2021-01-08 at 6f9e11ad97)\n + mktag: add a --[no-]strict option\n + mktag: mark strings for translation\n + mktag: convert to parse-options\n + mktag: allow omitting the header/body \\n separator\n + mktag: allow turning off fsck.extraHeaderEntry\n + fsck: make fsck_config() re-usable\n + mktag: use fsck instead of custom verify_tag()\n + mktag: use puts(str) instead of printf(\"%s\\n\", str)\n + mktag: remove redundant braces in one-line body \"if\"\n + mktag: use default strbuf_read() hint\n + mktag tests: test verify_object() with replaced objects\n + mktag tests: improve verify_object() test coverage\n + mktag tests: test \"hash-object\" compatibility\n + mktag tests: stress test whitespace handling\n + mktag tests: run \"fsck\" after creating \"mytag\"\n + mktag tests: don't create \"mytag\" twice\n + mktag tests: don't redirect stderr to a file needlessly\n + mktag tests: remove needless SHA-1 hardcoding\n + mktag tests: use \"test_commit\" helper\n + mktag tests: don't needlessly use a subshell\n + mktag doc: update to explain why to use this\n + mktag doc: grammar fix, when exists -> when it exists\n + mktag doc: say not \n\n \"git mktag\" validates its input using its own rules before writing\n a tag object---it has been updated to share the logic with \"git\n fsck\".\n\n Will merge to 'master'.\n\n\n* en/diffcore-rename (2021-01-04) 9 commits\n - diffcore-rename: remove unnecessary duplicate entry checks\n - diffcore-rename: accelerate rename_dst setup\n - diffcore-rename: simplify and accelerate register_rename_src()\n - t4058: explore duplicate tree entry handling in a bit more detail\n - t4058: add more tests and documentation for duplicate tree entry handling\n - diffcore-rename: reduce jumpiness in progress counters\n - diffcore-rename: simplify limit check\n - diffcore-rename: avoid usage of global in too_many_rename_candidates()\n - diffcore-rename: rename num_create to num_destinations\n\n File-level rename detection updates.\n\n Will merge to 'next'.\n\n\n* en/stash-apply-sparse-checkout (2020-12-01) 3 commits\n (merged to 'next' on 2021-01-08 at cae5b73d99)\n + stash: fix stash application in sparse-checkouts\n + stash: remove unnecessary process forking\n + t7012: add a testcase demonstrating stash apply bugs in sparse checkouts\n\n \"git stash\" did not work well in a sparsely checked out working\n tree.\n\n Will merge to 'master'.\n\n\n* js/default-branch-name-tests-final-stretch (2020-11-19) 29 commits\n - tests: drop prereq `PREPARE_FOR_MAIN_BRANCH` where no longer needed\n - t99*: adjust the references to the default branch name \"main\"\n - tests(git-p4): transition to the default branch name `main`\n - t9[5-7]*: adjust the references to the default branch name \"main\"\n - t9[0-4]*: adjust the references to the default branch name \"main\"\n - t8*: adjust the references to the default branch name \"main\"\n - t7[5-9]*: adjust the references to the default branch name \"main\"\n - t7[0-4]*: adjust the references to the default branch name \"main\"\n - t6[4-9]*: adjust the references to the default branch name \"main\"\n - t64*: preemptively adjust alignment to prepare for `master` -> `main`\n - t6[0-3]*: adjust the references to the default branch name \"main\"\n - t5[6-9]*: adjust the references to the default branch name \"main\"\n - t55[4-9]*: adjust the references to the default branch name \"main\"\n - t55[23]*: adjust the references to the default branch name \"main\"\n - t551*: adjust the references to the default branch name \"main\"\n - t550*: adjust the references to the default branch name \"main\"\n - t5503: prepare aligned comment for replacing `master` with `main`\n - t5[0-4]*: adjust the references to the default branch name \"main\"\n - t5323: prepare centered comment for `master` -> `main`\n - t4*: adjust the references to the default branch name \"main\"\n - t3[5-9]*: adjust the references to the default branch name \"main\"\n - t34*: adjust the references to the default branch name \"main\"\n - t3416: preemptively adjust alignment in a comment\n - t3[0-3]*: adjust the references to the default branch name \"main\"\n - t2*: adjust the references to the default branch name \"main\"\n - t[01]*: adjust the references to the default branch name \"main\"\n - t0060: preemptively adjust alignment\n - tests: mark tests relying on the current default for `init.defaultBranch`\n - Merge 'jk/diff-release-filespec-fix' into js/default-branch-name-tests-final-stretch\n\n Prepare tests not to be affected by the name of the default branch\n \"git init\" creates.\n\n Will merge to 'next'.\n\n\n* ds/maintenance-part-4 (2021-01-05) 4 commits\n (merged to 'next' on 2021-01-08 at 1f98c859ea)\n + maintenance: use Windows scheduled tasks\n + maintenance: use launchctl on macOS\n + maintenance: include 'cron' details in docs\n + maintenance: extract platform-specific scheduling\n\n Follow-up on the \"maintenance part-3\" which introduced scheduled\n maintenance tasks to support platforms whose native scheduling\n methods are not 'cron'.\n\n Will merge to 'master'.\n\n\n* sj/untracked-files-in-submodule-directory-is-not-dirty (2020-12-08) 1 commit\n - diff: do not show submodule with untracked files as \"-dirty\"\n\n \"git diff\" showed a submodule working tree with untracked cruft as\n \"Submodule commit -dirty\", but a natural expectation is\n that the \"-dirty\" indicator would align with \"git describe --dirty\",\n which does not consider having untracked files in the working tree\n as source of dirtiness. The inconsistency has been fixed.\n\n Will merge to 'next'.\n\n--------------------------------------------------\n[Discarded]\n\n* jc/config-pretend-gitdir (2020-12-15) 1 commit\n . config: --pretend-git-dir for includeIf:gitdir\n\n It turns out that the original \"problem\" that inspired the feature\n was working as designed.\n cf. \n"},{"id":"413907","messageId":"871reu752k.fsf@evledraar.gmail.com","threadId":"54964","inReplyTo":"xmqqk0sni68g.fsf@gitster.c.googlers.com","subject":"Re: What's cooking in git.git (Jan 2021, #02; Fri, 8)","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2021-01-09T10:55:15Z","receivedAt":"2021-01-09T10:56:15Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Fri, Jan 08 2021, Junio C Hamano wrote:\n\n> \tgit://git.kernel.org/pub/scm/git/git.git/\n> \tgit://repo.or.cz/alt-git.git/\n> \thttps://kernel.googlesource.com/pub/scm/git/git/\n> \thttps://github.com/git/git/\n> \thttps://gitlab.com/git-vcs/git/\n\nAs an aside thanks for following-up on adding the git-vcs/git URL. I\ndon't think I responded to a question in that E-Mail chain about whether\nthis repo only has your branches (and not some random topic branches of\nmine or whatever). That's the case, it's a strict mirror of your\npush-outs.\n\n> * ab/trailers-extra-format (2020-12-09) 5 commits\n> (merged to 'next' on 2020-12-14 at 9fc731944e)\n> + pretty format %(trailers): add a \"key_value_separator\"\n> + pretty format %(trailers): add a \"keyonly\"\n> + pretty-format %(trailers): fix broken standalone \"valueonly\"\n> + pretty format %(trailers) doc: avoid repetition\n> + pretty format %(trailers) test: split a long line\n>\n> The \"--format=%(trailers)\" mechanism gets enhanced to make it\n> easier to design output for machine consumption.\n\nThanks! Am refactoring some out-of-tree code to take advantage of this\n:)\n\nI forgot that, oops. Is just declaring here that all of that's:\n\nSigned-off-by: Ævar Arnfjörð Bjarmason \n\nSince you have some acks etc. squashed into it at this point...\n\n> * bc/hashed-mailmap (2020-12-12) 1 commit\n> - mailmap: support hashed entries in mailmaps\n>\n> The mailmap database learned to take hashed value as the original\n> side of mapping.\n>\n> Expecting a reroll.\n\nFWIW there was since a re-roll on 2021-01-03, but the discussion is\nsort-of outstanding, so maybe that's intentional...\n\n> * ab/mktag (2021-01-06) 23 commits\n> (merged to 'next' on 2021-01-08 at 6f9e11ad97)\n> + mktag: add a --[no-]strict option\n> + mktag: mark strings for translation\n> + mktag: convert to parse-options\n> + mktag: allow omitting the header/body \\n separator\n> + mktag: allow turning off fsck.extraHeaderEntry\n> + fsck: make fsck_config() re-usable\n> + mktag: use fsck instead of custom verify_tag()\n> + mktag: use puts(str) instead of printf(\"%s\\n\", str)\n> + mktag: remove redundant braces in one-line body \"if\"\n> + mktag: use default strbuf_read() hint\n> + mktag tests: test verify_object() with replaced objects\n> + mktag tests: improve verify_object() test coverage\n> + mktag tests: test \"hash-object\" compatibility\n> + mktag tests: stress test whitespace handling\n> + mktag tests: run \"fsck\" after creating \"mytag\"\n> + mktag tests: don't create \"mytag\" twice\n> + mktag tests: don't redirect stderr to a file needlessly\n> + mktag tests: remove needless SHA-1 hardcoding\n> + mktag tests: use \"test_commit\" helper\n> + mktag tests: don't needlessly use a subshell\n> + mktag doc: update to explain why to use this\n> + mktag doc: grammar fix, when exists -> when it exists\n> + mktag doc: say not \n>\n> \"git mktag\" validates its input using its own rules before writing\n> a tag object---it has been updated to share the logic with \"git\n> fsck\".\n>\n> Will merge to 'master'.\n\nThanks. I've got some more local fsck-y fixes I'm hoping to submit soon.\n"},{"id":"413924","messageId":"xmqqk0slg5ph.fsf@gitster.c.googlers.com","threadId":"54964","inReplyTo":"871reu752k.fsf@evledraar.gmail.com","subject":"Re: What's cooking in git.git (Jan 2021, #02; Fri, 8)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-01-09T21:28:58Z","receivedAt":"2021-01-09T21:29:46Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ævar Arnfjörð Bjarmason writes:\n\n>> * ab/trailers-extra-format (2020-12-09) 5 commits\n>> ...\n>>\n>> The \"--format=%(trailers)\" mechanism gets enhanced to make it\n>> easier to design output for machine consumption.\n>\n> Thanks! Am refactoring some out-of-tree code to take advantage of this\n> :)\n\nThank you for interesting additions.\n\n> I forgot that, oops. Is just declaring here that all of that's:\n>\n> Signed-off-by: Ævar Arnfjörð Bjarmason \n>\n> Since you have some acks etc. squashed into it at this point...\n\nPuzzlled. The patches on the trailers topic were all signed-off by\nyou, unless I was careless when I checked before merging them to\n'next'.\n\nDo the above three lines refer to a different topic, on CoC 2.0?\n\n\n>> * bc/hashed-mailmap (2020-12-12) 1 commit\n>> - mailmap: support hashed entries in mailmaps\n>>\n>> The mailmap database learned to take hashed value as the original\n>> side of mapping.\n>>\n>> Expecting a reroll.\n>\n> FWIW there was since a re-roll on 2021-01-03, but the discussion is\n> sort-of outstanding, so maybe that's intentional...\n\nI had an impression that those 4 or 5 patches haven't gained\nconcensus that they are good as-is.\n\nThanks.\n"},{"id":"413925","messageId":"CAJDDKr6V+kKMs4yz+YQx1AhiY5qQwENfs_yZqxXWBqmLUk2oAw@mail.gmail.com","threadId":"54964","inReplyTo":"xmqqk0sni68g.fsf@gitster.c.googlers.com","subject":"Re: What's cooking in git.git (Jan 2021, #02; Fri, 8)","fromName":"David Aguilar","fromEmail":"davvid@gmail.com","sentAt":"2021-01-09T21:38:20Z","receivedAt":"2021-01-09T21:39:38Z","isPatch":false,"sender":{"key":"davvid@gmail.com","avatar":"https://avatars.githubusercontent.com/u/13196?v=4"},"body":"On Fri, Jan 8, 2021 at 11:28 AM Junio C Hamano wrote:\n>\n> * fc/mergetool-automerge (2021-01-06) 5 commits\n> . mergetool: add automerge_enabled tool-specific override function\n> . mergetool: break setup_tool out into separate initialization function\n> . mergetool: add per-tool support for the autoMerge flag\n> . mergetool: alphabetize the mergetool config docs\n> . mergetool: add automerge configuration\n>\n> \"git mergetool\" feeds three versions (base, local and remote) of\n> a conflicted path unmodified. The command learned to optionally\n> prepare these files with unconflicted parts already resolved.\n>\n> Breaks tests on macOS.\n> cf. https://github.com/git/git/runs/1659807735?check_suite_focus=true#step:4:1641\n\n\nThank you for seeing these changes through. It's so close now!\n\nI did some investigation into this issue and narrowed down the root cause.\n\nHere is an example input file called \"tiger\" for testing the sed\ninvocations in auto_merge():\n\n$ cat tiger\n<<<<<<< HEAD\nbranch1 both added\n=======\ntiger both added\n>>>>>>> tiger\n\nThere are two sed invocations that use \\r\\? to maybe-match \\r for crlf support.\n\\r\\? is not portable to macOS (and freebsd?) sed.\n\nFor example, auto_merge() does the equivalent of this in one of the invocations:\n\n sed -e '/^<<<<<<< /,/^=======\\r\\?$/d' -e '/^>>>>>>> /d' tiger\n\nIt prints nothing on macOS. \"gsed\" (gnu-sed) from homebrew prints\n\"tiger both added\". This may affect other unix flavors where sed is\nnot gnu as well.\n\nTo verify I changed the sed invocations in auto_merge() to use gsed\nand it's then able to pass the tests.\n\nFun times in sed portability land. After a bit of experimentation,\nthis is what I've managed to whip up:\n\ncr=$(printf '\\x0d')\nsed -e \"/^<<<<<<< /,/^=======$cr\\{0,1\\}$/d\" -e '/^>>>>>>> /d' tiger\n\n- Instead of \\r use printf to capture CR into a string so that we can\nembed the literal using $cr.\n- DQ \"...\" instead of SQ '...' to allow $cr to be substituted in the string.\n- Instead of \\? use \\{0,1\\} which seems to work on both macOS and Linux.\n\nThat seems to work and the tests now pass.\nIf not sed, is there perhaps a perl equivalent for these multi-line\ndelete-from-X-until-Y expressions that might provide better\nportability?\n\nI'll start putting together a patch shortly as this seems to work in\npractice. Let me know if y'all have any sugs or if there are any\nportability pitfalls I'm not considering.\n\ncheers,\n\n--\nDavid\n"},{"id":"413932","messageId":"X/oosXBJlyt/IrOr@camp.crustytoothpaste.net","threadId":"54964","inReplyTo":"xmqqk0slg5ph.fsf@gitster.c.googlers.com","subject":"Re: What's cooking in git.git (Jan 2021, #02; Fri, 8)","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2021-01-09T22:05:37Z","receivedAt":"2021-01-09T22:06:39Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2021-01-09 at 21:28:58, Junio C Hamano wrote:\n> Ævar Arnfjörð Bjarmason writes:\n> > FWIW there was since a re-roll on 2021-01-03, but the discussion is\n> > sort-of outstanding, so maybe that's intentional...\n> \n> I had an impression that those 4 or 5 patches haven't gained\n> concensus that they are good as-is.\n\nThere will be another reroll. I'm hoping to get to it this weekend.\n-- \nbrian m. carlson (he/him or they/them)\nHouston, Texas, US\n"},{"id":"413942","messageId":"xmqqft39emiu.fsf@gitster.c.googlers.com","threadId":"54964","inReplyTo":"CAJDDKr6V+kKMs4yz+YQx1AhiY5qQwENfs_yZqxXWBqmLUk2oAw@mail.gmail.com","subject":"Re: What's cooking in git.git (Jan 2021, #02; Fri, 8)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-01-09T23:08:41Z","receivedAt":"2021-01-09T23:09:29Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"David Aguilar writes:\n\n> Fun times in sed portability land. After a bit of experimentation,\n> this is what I've managed to whip up:\n>\n> cr=$(printf '\\x0d')\n> sed -e \"/^<<<<<<< /,/^=======$cr\\{0,1\\}$/d\" -e '/^>>>>>>> /d' tiger\n>\n> - Instead of \\r use printf to capture CR into a string so that we can\n> embed the literal using $cr.\n> - DQ \"...\" instead of SQ '...' to allow $cr to be substituted in the string.\n> - Instead of \\? use \\{0,1\\} which seems to work on both macOS and Linux.\n\nAh, all the fun with avoiding GNU-ism in scripts; thanks for\nfiguring it out.\n\nI am perfectly fine with the above, but I also am OK with Perl\nscript. We may even be able to generate three output files in a\nsingle pass by passing their filenames and open them for writing in\nthe script.\n\n> That seems to work and the tests now pass.\n> If not sed, is there perhaps a perl equivalent for these multi-line\n> delete-from-X-until-Y expressions that might provide better\n> portability?\n\n> I'll start putting together a patch shortly as this seems to work in\n> practice. Let me know if y'all have any sugs or if there are any\n> portability pitfalls I'm not considering.\n"},{"id":"413944","messageId":"xmqq4kjpelza.fsf@gitster.c.googlers.com","threadId":"54964","inReplyTo":"X/oosXBJlyt/IrOr@camp.crustytoothpaste.net","subject":"Re: What's cooking in git.git (Jan 2021, #02; Fri, 8)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-01-09T23:20:25Z","receivedAt":"2021-01-09T23:21:09Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"brian m. carlson\" writes:\n\n> On 2021-01-09 at 21:28:58, Junio C Hamano wrote:\n>> Ævar Arnfjörð Bjarmason writes:\n>> > FWIW there was since a re-roll on 2021-01-03, but the discussion is\n>> > sort-of outstanding, so maybe that's intentional...\n>> \n>> I had an impression that those 4 or 5 patches haven't gained\n>> concensus that they are good as-is.\n>\n> There will be another reroll. I'm hoping to get to it this weekend.\n\nThanks.\n"},{"id":"413980","messageId":"87v9c462ht.fsf@evledraar.gmail.com","threadId":"54964","inReplyTo":"xmqqk0slg5ph.fsf@gitster.c.googlers.com","subject":"Re: What's cooking in git.git (Jan 2021, #02; Fri, 8)","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2021-01-10T19:00:46Z","receivedAt":"2021-01-10T19:01:47Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Sat, Jan 09 2021, Junio C Hamano wrote:\n\n> Ævar Arnfjörð Bjarmason writes:\n>> I forgot that, oops. Is just declaring here that all of that's:\n>>\n>> Signed-off-by: Ævar Arnfjörð Bjarmason \n>>\n>> Since you have some acks etc. squashed into it at this point...\n>\n> Puzzlled. The patches on the trailers topic were all signed-off by\n> you, unless I was careless when I checked before merging them to\n> 'next'.\n>\n> Do the above three lines refer to a different topic, on CoC 2.0?\n\nYes, I accidentally snipped out the part I should have been quoting. I\nmeant \"please assume my signed-off-by\" to be in reply the CoC 2.0\nseries.\n"},{"id":"413992","messageId":"xmqqv9c48grm.fsf@gitster.c.googlers.com","threadId":"54964","inReplyTo":"87v9c462ht.fsf@evledraar.gmail.com","subject":"Re: What's cooking in git.git (Jan 2021, #02; Fri, 8)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-01-11T00:21:49Z","receivedAt":"2021-01-11T00:22:50Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ævar Arnfjörð Bjarmason writes:\n\n> On Sat, Jan 09 2021, Junio C Hamano wrote:\n>\n>> Ævar Arnfjörð Bjarmason writes:\n>>> I forgot that, oops. Is just declaring here that all of that's:\n>>>\n>>> Signed-off-by: Ævar Arnfjörð Bjarmason \n>>>\n>>> Since you have some acks etc. squashed into it at this point...\n>>\n>> Puzzlled. The patches on the trailers topic were all signed-off by\n>> you, unless I was careless when I checked before merging them to\n>> 'next'.\n>>\n>> Do the above three lines refer to a different topic, on CoC 2.0?\n>\n> Yes, I accidentally snipped out the part I should have been quoting. I\n> meant \"please assume my signed-off-by\" to be in reply the CoC 2.0\n> series.\n\nThanks. Will squash your sign-off in.\n"},{"id":"414003","messageId":"X/uvhc5Hpu792qA/@camp.crustytoothpaste.net","threadId":"54964","inReplyTo":"xmqq4kjpelza.fsf@gitster.c.googlers.com","subject":"Re: What's cooking in git.git (Jan 2021, #02; Fri, 8)","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2021-01-11T01:53:09Z","receivedAt":"2021-01-11T01:55:58Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2021-01-09 at 23:20:25, Junio C Hamano wrote:\n> \"brian m. carlson\" writes:\n> \n> > On 2021-01-09 at 21:28:58, Junio C Hamano wrote:\n> >> Ævar Arnfjörð Bjarmason writes:\n> >> > FWIW there was since a re-roll on 2021-01-03, but the discussion is\n> >> > sort-of outstanding, so maybe that's intentional...\n> >> \n> >> I had an impression that those 4 or 5 patches haven't gained\n> >> concensus that they are good as-is.\n> >\n> > There will be another reroll. I'm hoping to get to it this weekend.\n> \n> Thanks.\n\nHaving read Ævar's latest comment, I've decided instead to drop this, so\nfeel free to do so whenever it's convenient.\n-- \nbrian m. carlson (he/him or they/them)\nHouston, Texas, US\n"},{"id":"414067","messageId":"xmqqeeir8fdg.fsf@gitster.c.googlers.com","threadId":"54964","inReplyTo":"X/uvhc5Hpu792qA/@camp.crustytoothpaste.net","subject":"Re: What's cooking in git.git (Jan 2021, #02; Fri, 8)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-01-11T19:04:11Z","receivedAt":"2021-01-11T19:05:16Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"brian m. carlson\" writes:\n\n> On 2021-01-09 at 23:20:25, Junio C Hamano wrote:\n>> \"brian m. carlson\" writes:\n>> \n>> > On 2021-01-09 at 21:28:58, Junio C Hamano wrote:\n>> >> Ævar Arnfjörð Bjarmason writes:\n>> >> > FWIW there was since a re-roll on 2021-01-03, but the discussion is\n>> >> > sort-of outstanding, so maybe that's intentional...\n>> >> \n>> >> I had an impression that those 4 or 5 patches haven't gained\n>> >> concensus that they are good as-is.\n>> >\n>> > There will be another reroll. I'm hoping to get to it this weekend.\n>> \n>> Thanks.\n>\n> Having read Ævar's latest comment, I've decided instead to drop this, so\n> feel free to do so whenever it's convenient.\n\nThat's kind of sad.\n\nI view that this is the kind of topic where perfect easily can\nbecome an enemy of good, as there is by definition no perfection\navailable to us without breaking existing Git.\n\nI do not know about Ævar, but to me, my initial impression while\nreading the discussion from sideline was that the goal was to\nprevent a mechanical scan of a recent version of .mailmap from\nlearning that Joe used to use Jane as his/her name, and that was the\nreason why I asked to be convinced why encoding for obfuscation was\ninsufficient. In the above, I meant \"mechanical scan\" as something\nlike \"a web search engine crawls and finds a .mailmap---a query for\nJoe produces a line with some garbage on it that is not Jane.\" and a\ncasual attacker would stop there.\n\nBut of course, a casual attacker who knows urlencode or whatever\nobfuscation in use can read that \"garbage\" once he/she knows that\n\"garbage\" is worth attacking (i.e. it is known to be associated to\nJoe, the person the attacker is interested in).\n\nIf your goal is to make it harder than just urlencode, even though\nwe all have to accept that scanning \"git log --all\" for all names\nthat appear in the history and hashing them all to see what name\nhashes to the \"garbage\" in question, then @sha256: approach\ndoes make sense as a stopping point. Perhaps we need to sell this\nwith a clear definition of what kind of attackes we are protecting\nthe name data from:\n\n The attacker is required to obtain sufficient amount of history\n in the project to uncover the obfuscation; a more casual\n attackers will fail to uncover, and we declare that it is better\n than nothing and it is good enough in practice.\n\nor something like that? I am not sure if I drew the line at the\nlevel you intended to draw in the above, if I think that it is good\nenough in practice, or if I agree to a change that is better than\nnothing but not good enough in practice, but having such a statement\nwould help to see where we agree or disagree.\n\nThanks.\n"},{"id":"414151","messageId":"87k0si5k75.fsf@evledraar.gmail.com","threadId":"54964","inReplyTo":"xmqqeeir8fdg.fsf@gitster.c.googlers.com","subject":"Re: What's cooking in git.git (Jan 2021, #02; Fri, 8)","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2021-01-12T14:00:30Z","receivedAt":"2021-01-12T14:01:32Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Mon, Jan 11 2021, Junio C Hamano wrote:\n\n> \"brian m. carlson\" writes:\n>\n>> On 2021-01-09 at 23:20:25, Junio C Hamano wrote:\n>>> \"brian m. carlson\" writes:\n>>> \n>>> > On 2021-01-09 at 21:28:58, Junio C Hamano wrote:\n>>> >> Ævar Arnfjörð Bjarmason writes:\n>>> >> > FWIW there was since a re-roll on 2021-01-03, but the discussion is\n>>> >> > sort-of outstanding, so maybe that's intentional...\n>>> >> \n>>> >> I had an impression that those 4 or 5 patches haven't gained\n>>> >> concensus that they are good as-is.\n>>> >\n>>> > There will be another reroll. I'm hoping to get to it this weekend.\n>>> \n>>> Thanks.\n>>\n>> Having read Ævar's latest comment, I've decided instead to drop this, so\n>> feel free to do so whenever it's convenient.\n>\n> That's kind of sad.\n\nAgreed. I mean, I'm just one contributor with an opinion. I certainly\ndon't mean my \"meh\" on a patch to be some sort of veto.\n\nIf you follow this list you'll see that if you're going to take anyone's\nopinion on whether a thing should make it into git as a matter of\nempirical data on patches I submit that aren't changed meaningfully,\nthen, uh, maybe pick someone else :)\n\n> I view that this is the kind of topic where perfect easily can\n> become an enemy of good, as there is by definition no perfection\n> available to us without breaking existing Git.\n>\n> I do not know about Ævar, but to me, my initial impression while\n> reading the discussion from sideline was that the goal was to\n> prevent a mechanical scan of a recent version of .mailmap from\n> learning that Joe used to use Jane as his/her name, and that was the\n> reason why I asked to be convinced why encoding for obfuscation was\n> insufficient. In the above, I meant \"mechanical scan\" as something\n> like \"a web search engine crawls and finds a .mailmap---a query for\n> Joe produces a line with some garbage on it that is not Jane.\" and a\n> casual attacker would stop there.\n>\n> But of course, a casual attacker who knows urlencode or whatever\n> obfuscation in use can read that \"garbage\" once he/she knows that\n> \"garbage\" is worth attacking (i.e. it is known to be associated to\n> Joe, the person the attacker is interested in).\n>\n> If your goal is to make it harder than just urlencode, even though\n> we all have to accept that scanning \"git log --all\" for all names\n> that appear in the history and hashing them all to see what name\n> hashes to the \"garbage\" in question, then @sha256: approach\n> does make sense as a stopping point. Perhaps we need to sell this\n> with a clear definition of what kind of attackes we are protecting\n> the name data from:\n>\n> The attacker is required to obtain sufficient amount of history\n> in the project to uncover the obfuscation; a more casual\n> attackers will fail to uncover, and we declare that it is better\n> than nothing and it is good enough in practice.\n>\n> or something like that? I am not sure if I drew the line at the\n> level you intended to draw in the above, if I think that it is good\n> enough in practice, or if I agree to a change that is better than\n> nothing but not good enough in practice, but having such a statement\n> would help to see where we agree or disagree.\n\nMy reading of the general thread & brian's reply at [1] is that the\ndifference in the minds of the users who want the feature (who're not\non-list, and we're getting brian's's summary of their views) is closer\nto:\n\n We want the X-Y problem of \"hide this data\" solved with solution \"Y\"\n because git's current tooling to retrieve the data is currently\n rather tedious & obscure.\n\nSo when I asked whether those users would feel the same if the tooling\nwas less tedious and suggested that I might patch it to be so brian\nreplied with \"[yes,] we do rely on this being inconvenient\".\n\nI do have a 20-something series patch to the mailmap code in my local\nqueue that in the light of this series's status I think I'll submit\nsoon.\n\nIt doesn't have anything to do with adding a \"spew out a materialized\nmap\" feature currently, nor do I really plan to do that any time soon. I\ndo genuinely think it would be a good addition to git for reasons that\nhave nothing to do with trying to make a point about this\nseries. E.g. you'd be able to more easily validate/check/fsck a mailmap\nthat way. Or e.g. use a git repository's .mailmap as a source to export\nto your MTA rules or whatever.\n\nThe external tools I referred to which consume the exported .mailmap\ndata are something I worked on at a previous job, but I no longer have\nthat immediate itch to scratch personally.\n\nThe \"march of history\" point was rather that if the difference between\nURI encoding and this solution is current tooling, it seems all but\ninevitable that we'll bridge that gap sooner than later in a way that\nmakes that difference useless to some of the users that want this now.\n\nAnd not even because some people don't like this feature in particular\nand wish to submit patches to make it less useful. But just because we\ncontinue implementing stuff that's been talked about for years & is\nbeing generally slowly worked towards. E.g. more client<->server\ncooperation for expensive queries over protocol v2, or a filter clone\nmode where you get only commit objects.\n\nIt even seems like something brian's series itself could benefit\nfrom. I.e. having the hashed values in the history is a performance hit\nin some cases. The patch caches the computation.\n\nAnother way to do it would be to just save a\n\".git/objects/info/mailmap.{hash-of-original-file}\". Either on the fly\nor generated by \"maintenance\" or whatever. It would guarantee a 0%\nperformance hit. At that point we'd already have the plumbing to\nmaterialize the file & would need to go out of our way to make it\ninaccessible in porcelain.\n\n1. https://lore.kernel.org/git/X%2FtxB8b3%2FqqbwbmC@camp.crustytoothpaste.net/\n"},{"id":"414397","messageId":"YADOf41CcaRuToD7@google.com","threadId":"54964","inReplyTo":"xmqqk0sni68g.fsf@gitster.c.googlers.com","subject":"Re: What's cooking in git.git (Jan 2021, #02; Fri, 8)","fromName":"Emily Shaffer","fromEmail":"emilyshaffer@google.com","sentAt":"2021-01-14T23:06:39Z","receivedAt":"2021-01-14T23:07:27Z","isPatch":false,"sender":{"key":"nasamuffin@google.com","avatar":"https://avatars.githubusercontent.com/u/1606826?v=4"},"body":"On Fri, Jan 08, 2021 at 11:22:23AM -0800, Junio C Hamano wrote:\n> * ds/maintenance-part-4 (2021-01-05) 4 commits\n> (merged to 'next' on 2021-01-08 at 1f98c859ea)\n> + maintenance: use Windows scheduled tasks\n> + maintenance: use launchctl on macOS\n> + maintenance: include 'cron' details in docs\n> + maintenance: extract platform-specific scheduling\n> \n> Follow-up on the \"maintenance part-3\" which introduced scheduled\n> maintenance tasks to support platforms whose native scheduling\n> methods are not 'cron'.\n> \n> Will merge to 'master'.\n\nThis series again has troubles running inside a directory with regex\nmetachars in the path. Courtesy of Jonathan Nieder, I think this fix\nmatches the intent a little better; but if we don't like this, the same\nlines could be diffed just to add --fixed-value instead.\n\nBefore this patch, the test said \"Is there something configured in\nmaintenance.repo that looks like $PWD?\" and after this patch, the test\nsays, \"Does the config in maintenance.repo look like $PWD?\" - so it is\nnot quite semantically identical but I think may be clearer.\n\n - Emily\n\n-- >8 --\nSubject: [PATCH] maintenace: explicitly test value of maintenance.repo\n\nMake t7900-maintenance.sh easier to debug by printing and checking the\nvalue of maintenance.repo rather than using a search string. Since only\none maintenance.repo is configured, this is fine; in the event that\nmultiple maintenance.repo are configured during the test, instead the\ndirectory under test should be provided along with '--fixed-value'.\n\nSigned-off-by: Emily Shaffer \n---\n t/t7900-maintenance.sh | 16 ++++++++++++----\n 1 file changed, 12 insertions(+), 4 deletions(-)\n\ndiff --git a/t/t7900-maintenance.sh b/t/t7900-maintenance.sh\nindex 2e0c8a4c31..0edad63227 100755\n--- a/t/t7900-maintenance.sh\n+++ b/t/t7900-maintenance.sh\n@@ -487,7 +487,9 @@ test_expect_success 'start and stop macOS maintenance' '\n \tGIT_TEST_MAINT_SCHEDULER=launchctl:./print-args git maintenance start &&\n \n \t# start registers the repo\n-\tgit config --get --global maintenance.repo \"$(pwd)\" &&\n+\tpwd >expect &&\n+\tgit config --get --global maintenance.repo >actual &&\n+\ttest_cmp expect actual &&\n \n \tls \"$HOME/Library/LaunchAgents\" >actual &&\n \tcat >expect <<-\\EOF &&\n@@ -512,7 +514,9 @@ test_expect_success 'start and stop macOS maintenance' '\n \tGIT_TEST_MAINT_SCHEDULER=launchctl:./print-args git maintenance stop &&\n \n \t# stop does not unregister the repo\n-\tgit config --get --global maintenance.repo \"$(pwd)\" &&\n+\tpwd >expect &&\n+\tgit config --get --global maintenance.repo >actual &&\n+\ttest_cmp expect actual &&\n \n \tprintf \"bootout gui/[UID] $pfx/Library/LaunchAgents/org.git-scm.git.%s.plist\\n\" \\\n \t\thourly daily weekly >expect &&\n@@ -538,7 +542,9 @@ test_expect_success 'start and stop Windows maintenance' '\n \tGIT_TEST_MAINT_SCHEDULER=\"schtasks:./print-args\" git maintenance start &&\n \n \t# start registers the repo\n-\tgit config --get --global maintenance.repo \"$(pwd)\" &&\n+\tpwd >expect &&\n+\tgit config --get --global maintenance.repo >actual &&\n+\ttest_cmp expect actual &&\n \n \tfor frequency in hourly daily weekly\n \tdo\n@@ -551,7 +557,9 @@ test_expect_success 'start and stop Windows maintenance' '\n \tGIT_TEST_MAINT_SCHEDULER=\"schtasks:./print-args\" git maintenance stop &&\n \n \t# stop does not unregister the repo\n-\tgit config --get --global maintenance.repo \"$(pwd)\" &&\n+\tpwd >expect &&\n+\tgit config --get --global maintenance.repo >actual &&\n+\ttest_cmp expect actual &&\n \n \tprintf \"/delete /tn Git Maintenance (%s) /f\\n\" \\\n \t\thourly daily weekly >expect &&\n-- \n2.29.2.490.gc7ae633391\n"},{"id":"414406","messageId":"YADZSsVqyGnArF0n@google.com","threadId":"54964","inReplyTo":"87k0si5k75.fsf@evledraar.gmail.com","subject":"Re: What's cooking in git.git (Jan 2021, #02; Fri, 8)","fromName":"Emily Shaffer","fromEmail":"emilyshaffer@google.com","sentAt":"2021-01-14T23:52:42Z","receivedAt":"2021-01-14T23:53:32Z","isPatch":false,"sender":{"key":"nasamuffin@google.com","avatar":"https://avatars.githubusercontent.com/u/1606826?v=4"},"body":"On Tue, Jan 12, 2021 at 03:00:30PM +0100, Ævar Arnfjörð Bjarmason wrote:\n> \n> \n> On Mon, Jan 11 2021, Junio C Hamano wrote:\n> \n> > \"brian m. carlson\" writes:\n> >\n> >> On 2021-01-09 at 23:20:25, Junio C Hamano wrote:\n> >>> \"brian m. carlson\" writes:\n> >>> \n> >>> > On 2021-01-09 at 21:28:58, Junio C Hamano wrote:\n> >>> >> Ævar Arnfjörð Bjarmason writes:\n> >>> >> > FWIW there was since a re-roll on 2021-01-03, but the discussion is\n> >>> >> > sort-of outstanding, so maybe that's intentional...\n> >>> >> \n> >>> >> I had an impression that those 4 or 5 patches haven't gained\n> >>> >> concensus that they are good as-is.\n> >>> >\n> >>> > There will be another reroll. I'm hoping to get to it this weekend.\n> >>> \n> >>> Thanks.\n> >>\n> >> Having read Ævar's latest comment, I've decided instead to drop this, so\n> >> feel free to do so whenever it's convenient.\n> >\n> > That's kind of sad.\n> \n> Agreed. I mean, I'm just one contributor with an opinion. I certainly\n> don't mean my \"meh\" on a patch to be some sort of veto.\n> \n> If you follow this list you'll see that if you're going to take anyone's\n> opinion on whether a thing should make it into git as a matter of\n> empirical data on patches I submit that aren't changed meaningfully,\n> then, uh, maybe pick someone else :)\n> \n> > I view that this is the kind of topic where perfect easily can\n> > become an enemy of good, as there is by definition no perfection\n> > available to us without breaking existing Git.\n> >\n> > I do not know about Ævar, but to me, my initial impression while\n> > reading the discussion from sideline was that the goal was to\n> > prevent a mechanical scan of a recent version of .mailmap from\n> > learning that Joe used to use Jane as his/her name, and that was the\n> > reason why I asked to be convinced why encoding for obfuscation was\n> > insufficient. In the above, I meant \"mechanical scan\" as something\n> > like \"a web search engine crawls and finds a .mailmap---a query for\n> > Joe produces a line with some garbage on it that is not Jane.\" and a\n> > casual attacker would stop there.\n> >\n> > But of course, a casual attacker who knows urlencode or whatever\n> > obfuscation in use can read that \"garbage\" once he/she knows that\n> > \"garbage\" is worth attacking (i.e. it is known to be associated to\n> > Joe, the person the attacker is interested in).\n> >\n> > If your goal is to make it harder than just urlencode, even though\n> > we all have to accept that scanning \"git log --all\" for all names\n> > that appear in the history and hashing them all to see what name\n> > hashes to the \"garbage\" in question, then @sha256: approach\n> > does make sense as a stopping point. Perhaps we need to sell this\n> > with a clear definition of what kind of attackes we are protecting\n> > the name data from:\n> >\n> > The attacker is required to obtain sufficient amount of history\n> > in the project to uncover the obfuscation; a more casual\n> > attackers will fail to uncover, and we declare that it is better\n> > than nothing and it is good enough in practice.\n> >\n> > or something like that? I am not sure if I drew the line at the\n> > level you intended to draw in the above, if I think that it is good\n> > enough in practice, or if I agree to a change that is better than\n> > nothing but not good enough in practice, but having such a statement\n> > would help to see where we agree or disagree.\n> \n> My reading of the general thread & brian's reply at [1] is that the\n> difference in the minds of the users who want the feature (who're not\n> on-list, and we're getting brian's's summary of their views) is closer\n> to:\n> \n> We want the X-Y problem of \"hide this data\" solved with solution \"Y\"\n> because git's current tooling to retrieve the data is currently\n> rather tedious & obscure.\n> \n> So when I asked whether those users would feel the same if the tooling\n> was less tedious and suggested that I might patch it to be so brian\n> replied with \"[yes,] we do rely on this being inconvenient\".\n> \n> I do have a 20-something series patch to the mailmap code in my local\n> queue that in the light of this series's status I think I'll submit\n> soon.\n> \n> It doesn't have anything to do with adding a \"spew out a materialized\n> map\" feature currently, nor do I really plan to do that any time soon. I\n> do genuinely think it would be a good addition to git for reasons that\n> have nothing to do with trying to make a point about this\n> series. E.g. you'd be able to more easily validate/check/fsck a mailmap\n> that way. Or e.g. use a git repository's .mailmap as a source to export\n> to your MTA rules or whatever.\n> \n> The external tools I referred to which consume the exported .mailmap\n> data are something I worked on at a previous job, but I no longer have\n> that immediate itch to scratch personally.\n> \n> The \"march of history\" point was rather that if the difference between\n> URI encoding and this solution is current tooling, it seems all but\n> inevitable that we'll bridge that gap sooner than later in a way that\n> makes that difference useless to some of the users that want this now.\n> \n> And not even because some people don't like this feature in particular\n> and wish to submit patches to make it less useful. But just because we\n> continue implementing stuff that's been talked about for years & is\n> being generally slowly worked towards. E.g. more client<->server\n> cooperation for expensive queries over protocol v2, or a filter clone\n> mode where you get only commit objects.\n> \n> It even seems like something brian's series itself could benefit\n> from. I.e. having the hashed values in the history is a performance hit\n> in some cases. The patch caches the computation.\n> \n> Another way to do it would be to just save a\n> \".git/objects/info/mailmap.{hash-of-original-file}\". Either on the fly\n> or generated by \"maintenance\" or whatever. It would guarantee a 0%\n> performance hit. At that point we'd already have the plumbing to\n> materialize the file & would need to go out of our way to make it\n> inaccessible in porcelain.\n\nI've got quite a few sporadic thoughts about this series and this\ndiscussion, so I'll braindump and hopefully it turns into something\nuseful.\n\nFirstly: this design comes from a conversation amongst a pretty small (4\npeople? 6 people?) group at the virtual inclusion summit some months\nago. At that time, we discussed the ease of brute-force decoding the\none-way-hashed mailmap and decided that, as long as Git didn't ship a\ntool to do this for you for free, it was better than the current\nsolution for avoiding deadnames (i.e. \"sorry\"). I'm disappointed to see\nthe larger list feel otherwise, but not terribly surprised, since the\nlist contains more people than the group who came up with the design.\n\nSecondly: it seems like a restatement of the goals of this patch would\nhelp guide a discussion of designs; I would be so pleased to see a\ncleaner solution than any that's been proposed so far, because I agree\nthat this feature is not perfect. So please append what I have missed:\n\nAxiom: The current Git solution for avoiding deadnaming is insufficient.\nAxiom: We want to improve Git's solution for avoiding deadnaming.\n(That is, I don't think either of these statements are or should be up\nfor discussion.)\n\nGoal: Projects which are contributed to by trans individuals who\ntransition during their contribution period should provide a good,\nsupportive experience, which does not deadname the individual.\nGoal: Git's performance should not suffer unduly from any change unless\nnecessary.\nGoal: Project maintainers should have an understanding of the threat\nmodel (e.g. automated tools scraping for names, malicious individuals\nwith time on their hands and experience with the project, etc)\nGoal: Audit trails required by e.g. SOB lines should exist for the\nproject maintainer, if necessary\nGoal: Mailmap, in general, should work better than it does now\nGoal: An imperfect solution should not disallow a more perfect solution\nlater down the road\nBonus goal: For the sake of Git project contributors, it would be nice\nto avoid a troll storm on list.\n\nThirdly: As is stated elsewhere, I think this topic is falling victim to\nperfect vs. good. Git is gaining increasing notoriety in circles I can\nsee about the ultimately crappy experience for people who change their\nnames and don't want to hear the old names (and don't want to know the\nold names). In my opinion, literally anything we could do to improve\nthis experience would be better than doing nothing. So I feel sad to see\nthe topic dropped because of pushback, especially when that pushback is\n\"I'd like to write a tool to reverse this thing, because \n- and I don't mean that tool maliciously so that should be OK.\"\n\nFourthly: The perfect solution, as has been mentioned, is to stop using\nuser.name/user.email in commits and start using some generic ID instead.\nI think I mentioned this during the summit as well, but one meh idea -\nwhich maybe someone else can be inspired by and come up with something\nbetter - may be to just start wedging genericness into those fields\nanyways. That is, generating commits with user.name like \"abc123def\" and\nuser.email like \"\". I\ndon't like the idea of carrying that technical debt around forever, but\nthe experience it provides on older Git versions isn't terrible,\nespecially if you pair it with a mailmap entry from \"abc123def\" to\n\"Emily Shaffer \", for example.\n\nFood for thought.\n - Emily\n\n> \n> 1. https://lore.kernel.org/git/X%2FtxB8b3%2FqqbwbmC@camp.crustytoothpaste.net/\n"},{"id":"414407","messageId":"YADaJ1gfbxQaLGXf@google.com","threadId":"54964","inReplyTo":"YADZSsVqyGnArF0n@google.com","subject":"Re: What's cooking in git.git (Jan 2021, #02; Fri, 8)","fromName":"Emily Shaffer","fromEmail":"emilyshaffer@google.com","sentAt":"2021-01-14T23:56:23Z","receivedAt":"2021-01-14T23:57:11Z","isPatch":false,"sender":{"key":"nasamuffin@google.com","avatar":"https://avatars.githubusercontent.com/u/1606826?v=4"},"body":"On Thu, Jan 14, 2021 at 03:52:42PM -0800, Emily Shaffer wrote:\n> Fourthly: The perfect solution, as has been mentioned, is to stop using\n> user.name/user.email in commits and start using some generic ID instead.\n\nAnother throwaway thought:\n\nTaking the time to redesign commit format (e.g. use user.id instead of\nuser.name/user.email) also gives us room to improve other things we\ndon't like about the commit format (e.g. limited to single author). How\nmany things-we-don't-like do we need to collect before we have enough\ninertia to go through the long/painful process of starting to use a new\ncommit format?\n"},{"id":"414410","messageId":"YADh2DHDrdAs6Jbj@camp.crustytoothpaste.net","threadId":"54964","inReplyTo":"YADZSsVqyGnArF0n@google.com","subject":"Re: What's cooking in git.git (Jan 2021, #02; Fri, 8)","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2021-01-15T00:29:12Z","receivedAt":"2021-01-15T00:30:32Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2021-01-14 at 23:52:42, Emily Shaffer wrote:\n> Firstly: this design comes from a conversation amongst a pretty small (4\n> people? 6 people?) group at the virtual inclusion summit some months\n> ago. At that time, we discussed the ease of brute-force decoding the\n> one-way-hashed mailmap and decided that, as long as Git didn't ship a\n> tool to do this for you for free, it was better than the current\n> solution for avoiding deadnames (i.e. \"sorry\"). I'm disappointed to see\n> the larger list feel otherwise, but not terribly surprised, since the\n> list contains more people than the group who came up with the design.\n\nYes, thank you for sharing this helpful context. I will add that there\nwere a couple folks in that conversation who had mentioned that the\nhashed mailmap was an idea they'd thought of (of which I was one) and I\ndid commit to bringing it to the list.\n\n> Secondly: it seems like a restatement of the goals of this patch would\n> help guide a discussion of designs; I would be so pleased to see a\n> cleaner solution than any that's been proposed so far, because I agree\n> that this feature is not perfect. So please append what I have missed:\n\nI completely agree. If there are better ideas, I'd be delighted to hear\nthem, even if the proposer isn't interested in implementing them.\n\n> Axiom: The current Git solution for avoiding deadnaming is insufficient.\n> Axiom: We want to improve Git's solution for avoiding deadnaming.\n> (That is, I don't think either of these statements are or should be up\n> for discussion.)\n> \n> Goal: Projects which are contributed to by trans individuals who\n> transition during their contribution period should provide a good,\n> supportive experience, which does not deadname the individual.\n> Goal: Git's performance should not suffer unduly from any change unless\n> necessary.\n> Goal: Project maintainers should have an understanding of the threat\n> model (e.g. automated tools scraping for names, malicious individuals\n> with time on their hands and experience with the project, etc)\n> Goal: Audit trails required by e.g. SOB lines should exist for the\n> project maintainer, if necessary\n> Goal: Mailmap, in general, should work better than it does now\n> Goal: An imperfect solution should not disallow a more perfect solution\n> later down the road\n> Bonus goal: For the sake of Git project contributors, it would be nice\n> to avoid a troll storm on list.\n\nI agree with all of these.\n\nConsidering the last point, part of the reason I volunteered to present\nthis idea to the list was that I expected some trolling and general poor\nbehavior (hence my reminder about the CoC) and I'm comfortable with\ntaking the flak here. I am (and I'm sure everyone else on the list is)\ndelighted that we didn't see that.\n\n> Thirdly: As is stated elsewhere, I think this topic is falling victim to\n> perfect vs. good. Git is gaining increasing notoriety in circles I can\n> see about the ultimately crappy experience for people who change their\n> names and don't want to hear the old names (and don't want to know the\n> old names). In my opinion, literally anything we could do to improve\n> this experience would be better than doing nothing. So I feel sad to see\n> the topic dropped because of pushback, especially when that pushback is\n> \"I'd like to write a tool to reverse this thing, because \n> - and I don't mean that tool maliciously so that should be OK.\"\n\nIf folks feel that my series is at least better than the status quo and\ndo want it to be picked up, I can do the reroll I was planning on doing.\nIt sounds like there may be some support for that.\n\nI think that does implicitly mean, though, that we're agreeing that\nmaybe adding a tool to reverse hashes isn't something we want to adopt\nin Git, at least until we have a better or different solution in place.\nWhile I agree there could be some legitimate uses for it, we do have to\nbe cognizant of the potential for misuse and abuse (as when writing any\nsoftware).\n-- \nbrian m. carlson (he/him or they/them)\nHouston, Texas, US\n"},{"id":"414413","messageId":"xmqq4kjjvuqz.fsf@gitster.c.googlers.com","threadId":"54964","inReplyTo":"YADZSsVqyGnArF0n@google.com","subject":"Re: What's cooking in git.git (Jan 2021, #02; Fri, 8)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-01-15T01:44:52Z","receivedAt":"2021-01-15T01:45:40Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Emily Shaffer writes:\n\n> Secondly: it seems like a restatement of the goals of this patch would\n> help guide a discussion of designs; I would be so pleased to see a\n> cleaner solution than any that's been proposed so far, because I agree\n> that this feature is not perfect. So please append what I have missed:\n>\n> Axiom: The current Git solution for avoiding deadnaming is insufficient.\n> Axiom: We want to improve Git's solution for avoiding deadnaming.\n> (That is, I don't think either of these statements are or should be up\n> for discussion.)\n\nAnother one [*1*]:\n\nAxiom: It is, by nature of how Git works, impossible to come up with\na solution that avoids deadnaming perfectly. The best we can do is\nto aim for \"good enough\".\n\n> Goal: Projects which are contributed to by trans individuals who\n> transition during their contribution period should provide a good,\n> supportive experience, which does not deadname the individual.\n> Goal: Git's performance should not suffer unduly from any change unless\n> necessary.\n> Goal: Project maintainers should have an understanding of the threat\n> model (e.g. automated tools scraping for names, malicious individuals\n> with time on their hands and experience with the project, etc)\n\nGoal: the design should clearly describe the thread model it\nsupports, so that \"good enough\" can be judged against it.\n\n\n\n[Footnote]\n\n*1* This may be clear from what both you and I said about perfection\nand being good enough. I usually do not like to see people punt for\nan imperfect solution too early without even trying, but in a case\nlike this where we know perfection is theoretically impossible, it\nis a totally different story.\n"},{"id":"414415","messageId":"xmqqsg73ufxr.fsf@gitster.c.googlers.com","threadId":"54964","inReplyTo":"YADOf41CcaRuToD7@google.com","subject":"Re: What's cooking in git.git (Jan 2021, #02; Fri, 8)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-01-15T01:50:08Z","receivedAt":"2021-01-15T01:50:56Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Emily Shaffer writes:\n\n> On Fri, Jan 08, 2021 at 11:22:23AM -0800, Junio C Hamano wrote:\n>> * ds/maintenance-part-4 (2021-01-05) 4 commits\n>> (merged to 'next' on 2021-01-08 at 1f98c859ea)\n>> + maintenance: use Windows scheduled tasks\n>> + maintenance: use launchctl on macOS\n>> + maintenance: include 'cron' details in docs\n>> + maintenance: extract platform-specific scheduling\n>> \n>> Follow-up on the \"maintenance part-3\" which introduced scheduled\n>> maintenance tasks to support platforms whose native scheduling\n>> methods are not 'cron'.\n>> \n>> Will merge to 'master'.\n>\n> This series again has troubles running inside a directory with regex\n> metachars in the path. Courtesy of Jonathan Nieder, I think this fix\n> matches the intent a little better; but if we don't like this, the same\n> lines could be diffed just to add --fixed-value instead.\n\nThanks.\n\n> \t# start registers the repo\n> -\tgit config --get --global maintenance.repo \"$(pwd)\" &&\n> +\tpwd >expect &&\n> +\tgit config --get --global maintenance.repo >actual &&\n> +\ttest_cmp expect actual &&\n\n> Before this patch, the test said \"Is there something configured in\n> maintenance.repo that looks like $PWD?\" and after this patch, the test\n> says, \"Does the config in maintenance.repo look like $PWD?\" - so it is\n> not quite semantically identical but I think may be clearer.\n\nSounds sensible. Derrick (CC'ed), thoughts?\n"},{"id":"414417","messageId":"YAD80TFOn0EX24wb@nand.local","threadId":"54964","inReplyTo":"xmqqsg73ufxr.fsf@gitster.c.googlers.com","subject":"Re: What's cooking in git.git (Jan 2021, #02; Fri, 8)","fromName":"Taylor Blau","fromEmail":"me@ttaylorr.com","sentAt":"2021-01-15T02:24:17Z","receivedAt":"2021-01-15T02:25:19Z","isPatch":false,"sender":{"key":"me@ttaylorr.com","avatar":"https://avatars.githubusercontent.com/u/301000140?v=4"},"body":"On Thu, Jan 14, 2021 at 05:50:08PM -0800, Junio C Hamano wrote:\n> Emily Shaffer writes:\n> > \t# start registers the repo\n> > -\tgit config --get --global maintenance.repo \"$(pwd)\" &&\n> > +\tpwd >expect &&\n> > +\tgit config --get --global maintenance.repo >actual &&\n> > +\ttest_cmp expect actual &&\n>\n> > Before this patch, the test said \"Is there something configured in\n> > maintenance.repo that looks like $PWD?\" and after this patch, the test\n> > says, \"Does the config in maintenance.repo look like $PWD?\" - so it is\n> > not quite semantically identical but I think may be clearer.\n>\n> Sounds sensible. Derrick (CC'ed), thoughts?\n\nI'm not Stolee, but isn't this what 'git config --fixed-value' is for?\nISTM that what is written here (writing the cwd into 'expect', and then\ncomparing it to the value of maintenance.repo) is correct, but I think\nit may be unnecessarily verbose.\n\nI.e., wouldn't the following do the trick?\n\n-\tgit config --get --global maintenance.repo \"$(pwd)\" &&\n+\tgit config --get --fixed-value --global maintenance.repo \"$(pwd)\" &&\n\nThanks,\nTaylor\n"},{"id":"414420","messageId":"15237c6c-98eb-0d1f-e6d5-2dda91c0ce09@gmail.com","threadId":"54964","inReplyTo":"YADOf41CcaRuToD7@google.com","subject":"Re: What's cooking in git.git (Jan 2021, #02; Fri, 8)","fromName":"Derrick Stolee","fromEmail":"stolee@gmail.com","sentAt":"2021-01-15T02:36:44Z","receivedAt":"2021-01-15T02:37:39Z","isPatch":false,"sender":{"key":"stolee@gmail.com","avatar":"https://avatars.githubusercontent.com/u/570044?v=4"},"body":"On 1/14/2021 6:06 PM, Emily Shaffer wrote:\n> On Fri, Jan 08, 2021 at 11:22:23AM -0800, Junio C Hamano wrote:\n>> * ds/maintenance-part-4 (2021-01-05) 4 commits\n>> (merged to 'next' on 2021-01-08 at 1f98c859ea)\n>> + maintenance: use Windows scheduled tasks\n>> + maintenance: use launchctl on macOS\n>> + maintenance: include 'cron' details in docs\n>> + maintenance: extract platform-specific scheduling\n>>\n>> Follow-up on the \"maintenance part-3\" which introduced scheduled\n>> maintenance tasks to support platforms whose native scheduling\n>> methods are not 'cron'.\n>>\n>> Will merge to 'master'.\n> \n> This series again has troubles running inside a directory with regex\n> metachars in the path. Courtesy of Jonathan Nieder, I think this fix\n> matches the intent a little better; but if we don't like this, the same\n> lines could be diffed just to add --fixed-value instead.\n> \n> Before this patch, the test said \"Is there something configured in\n> maintenance.repo that looks like $PWD?\" and after this patch, the test\n> says, \"Does the config in maintenance.repo look like $PWD?\" - so it is\n> not quite semantically identical but I think may be clearer.\n\nThis appears to be a case of mixing up the order in which these\nsubmissions came into place. js/t7900-protect-pwd-in-config-get added\n--fixed-value, but that was simultaneous with ds/maintenance-part-4\nwhich added more tests in this vein without including --fixed-value.\n\nLooking at the history, ds/maintenance-part-4 doesn't have\njs/t7900-protect-pwd-in-config-get in its history, which is probably\nwhy you don't include --fixed-value in your patch.\n\nPerhaps it would be better to have a --fixed-value patch on top\nof the merge that combines the two topics?\n\n> -- >8 --\n> Subject: [PATCH] maintenace: explicitly test value of maintenance.repo\n\ns/maintenace/maintenance/\n\n> Make t7900-maintenance.sh easier to debug by printing and checking the\n> value of maintenance.repo rather than using a search string. Since only\n> one maintenance.repo is configured, this is fine; in the event that\n> multiple maintenance.repo are configured during the test, instead the\n> directory under test should be provided along with '--fixed-value'.\n\nHere you mention --fixed-value as if you plan to use it. I'm all for\nthat plan.\n\n> Signed-off-by: Emily Shaffer \n> ---\n> t/t7900-maintenance.sh | 16 ++++++++++++----\n> 1 file changed, 12 insertions(+), 4 deletions(-)\n> \n> diff --git a/t/t7900-maintenance.sh b/t/t7900-maintenance.sh\n> index 2e0c8a4c31..0edad63227 100755\n> --- a/t/t7900-maintenance.sh\n> +++ b/t/t7900-maintenance.sh\n> @@ -487,7 +487,9 @@ test_expect_success 'start and stop macOS maintenance' '\n> \tGIT_TEST_MAINT_SCHEDULER=launchctl:./print-args git maintenance start &&\n> \n> \t# start registers the repo\n> -\tgit config --get --global maintenance.repo \"$(pwd)\" &&\n> +\tpwd >expect &&\n> +\tgit config --get --global maintenance.repo >actual &&\n> +\ttest_cmp expect actual &&\n\nSorry again, but this (and others) would probably be better as\n\n+\tgit config --get --global --fixed-value maintenance.repo \"$(pwd)\" &&\n\nThanks,\n-Stolee\n"},{"id":"414422","messageId":"YAEBkLihh1cb2NJB@nand.local","threadId":"54964","inReplyTo":"YAD80TFOn0EX24wb@nand.local","subject":"Re: What's cooking in git.git (Jan 2021, #02; Fri, 8)","fromName":"Taylor Blau","fromEmail":"me@ttaylorr.com","sentAt":"2021-01-15T02:44:32Z","receivedAt":"2021-01-15T02:45:17Z","isPatch":false,"sender":{"key":"me@ttaylorr.com","avatar":"https://avatars.githubusercontent.com/u/301000140?v=4"},"body":"On Thu, Jan 14, 2021 at 09:24:17PM -0500, Taylor Blau wrote:\n> I'm not Stolee, but isn't this what 'git config --fixed-value' is for?\n\nMy apologies: Emily suggested this in her original patch and I\ncompletely read past it. I do think that this is better than repeating\npwd >expect, git config >actual, test_cmp expect actual over and over,\nbut credit where it's due.\n\nThanks,\nTaylor\n"},{"id":"414423","messageId":"47b76019-6e58-3f79-e927-c5c6b6e28075@gmail.com","threadId":"54964","inReplyTo":"15237c6c-98eb-0d1f-e6d5-2dda91c0ce09@gmail.com","subject":"Re: What's cooking in git.git (Jan 2021, #02; Fri, 8)","fromName":"Derrick Stolee","fromEmail":"stolee@gmail.com","sentAt":"2021-01-15T02:54:44Z","receivedAt":"2021-01-15T02:55:28Z","isPatch":false,"sender":{"key":"stolee@gmail.com","avatar":"https://avatars.githubusercontent.com/u/570044?v=4"},"body":"On 1/14/2021 9:36 PM, Derrick Stolee wrote:\n> On 1/14/2021 6:06 PM, Emily Shaffer wrote:\n>> On Fri, Jan 08, 2021 at 11:22:23AM -0800, Junio C Hamano wrote:\n>>> * ds/maintenance-part-4 (2021-01-05) 4 commits\n>>> (merged to 'next' on 2021-01-08 at 1f98c859ea)\n>>> + maintenance: use Windows scheduled tasks\n>>> + maintenance: use launchctl on macOS\n>>> + maintenance: include 'cron' details in docs\n>>> + maintenance: extract platform-specific scheduling\n>>>\n>>> Follow-up on the \"maintenance part-3\" which introduced scheduled\n>>> maintenance tasks to support platforms whose native scheduling\n>>> methods are not 'cron'.\n>>>\n>>> Will merge to 'master'.\n>>\n>> This series again has troubles running inside a directory with regex\n>> metachars in the path. Courtesy of Jonathan Nieder, I think this fix\n>> matches the intent a little better; but if we don't like this, the same\n>> lines could be diffed just to add --fixed-value instead.\n...\n>>\n>> diff --git a/t/t7900-maintenance.sh b/t/t7900-maintenance.sh\n>> index 2e0c8a4c31..0edad63227 100755\n>> --- a/t/t7900-maintenance.sh\n>> +++ b/t/t7900-maintenance.sh\n>> @@ -487,7 +487,9 @@ test_expect_success 'start and stop macOS maintenance' '\n>> \tGIT_TEST_MAINT_SCHEDULER=launchctl:./print-args git maintenance start &&\n>> \n>> \t# start registers the repo\n>> -\tgit config --get --global maintenance.repo \"$(pwd)\" &&\n>> +\tpwd >expect &&\n>> +\tgit config --get --global maintenance.repo >actual &&\n>> +\ttest_cmp expect actual &&\n> \n> Sorry again, but this (and others) would probably be better as\n> \n> +\tgit config --get --global --fixed-value maintenance.repo \"$(pwd)\" &&\n\nAlternatively, the additional cases of \"git config --get --global\" in\nds/maintenance-part-4 could actually be simply _removed_ because we\nare running all tests on all platforms. We already verify this behavior\nin the cron tests, such as 'start from empty cron table'.\n\nThanks,\n-Stolee\n"},{"id":"414431","messageId":"xmqqr1mmu2nx.fsf@gitster.c.googlers.com","threadId":"54964","inReplyTo":"15237c6c-98eb-0d1f-e6d5-2dda91c0ce09@gmail.com","subject":"Re: What's cooking in git.git (Jan 2021, #02; Fri, 8)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-01-15T06:36:50Z","receivedAt":"2021-01-15T06:37:39Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Derrick Stolee writes:\n\n> Perhaps it would be better to have a --fixed-value patch on top\n> of the merge that combines the two topics?\n\nThanks. That is how we usually handle this kind of fallouts from\nmultiple topics.\n\nIn fact, there already are conflicting hunks in t/t7900 when the\ntopic is merged into the current 'master', and rerere database knows\nabout them; I'll need to teach \"--fixed-value\" to these places.\n\nHere is how eventual merge of the topic into 'master' would resolve\nconflicts. The straight merge chain from master..seen would have\nsuch a merge with the resolution shown below, but 'next' already has\na mismerge, so I'll be applying a single-parent commit to fix the\nmismerge directly on 'next' (which I'll send in a separate message).\n\nThanks, all, for all the help.\n\n\n\ndiff --cc t/t7900-maintenance.sh\nindex 99bf0c7582,135505f619..0000000000\n--- i/t/t7900-maintenance.sh\n+++ w/t/t7900-maintenance.sh\n@@@ -406,23 -380,11 +419,23 @@@ test_expect_success 'register and unreg\n \ttest_cmp before actual\n '\n \n +test_expect_success !MINGW 'register and unregister with regex metacharacters' '\n +\tMETA=\"a+b*c\" &&\n +\tgit init \"$META\" &&\n +\tgit -C \"$META\" maintenance register &&\n +\tgit config --get-all --show-origin maintenance.repo &&\n +\tgit config --get-all --global --fixed-value \\\n +\t\tmaintenance.repo \"$(pwd)/$META\" &&\n +\tgit -C \"$META\" maintenance unregister &&\n +\ttest_must_fail git config --get-all --global --fixed-value \\\n +\t\tmaintenance.repo \"$(pwd)/$META\"\n +'\n +\n test_expect_success 'start from empty cron table' '\n- \tGIT_TEST_CRONTAB=\"test-tool crontab cron.txt\" git maintenance start &&\n+ \tGIT_TEST_MAINT_SCHEDULER=\"crontab:test-tool crontab cron.txt\" git maintenance start &&\n \n \t# start registers the repo\n -\tgit config --get --global maintenance.repo \"$(pwd)\" &&\n +\tgit config --get --global --fixed-value maintenance.repo \"$(pwd)\" &&\n \n \tgrep \"for-each-repo --config=maintenance.repo maintenance run --schedule=daily\" cron.txt &&\n \tgrep \"for-each-repo --config=maintenance.repo maintenance run --schedule=hourly\" cron.txt &&\n@@@ -430,13 -392,13 +443,13 @@@\n '\n \n test_expect_success 'stop from existing schedule' '\n- \tGIT_TEST_CRONTAB=\"test-tool crontab cron.txt\" git maintenance stop &&\n+ \tGIT_TEST_MAINT_SCHEDULER=\"crontab:test-tool crontab cron.txt\" git maintenance stop &&\n \n \t# stop does not unregister the repo\n -\tgit config --get --global maintenance.repo \"$(pwd)\" &&\n +\tgit config --get --global --fixed-value maintenance.repo \"$(pwd)\" &&\n \n \t# Operation is idempotent\n- \tGIT_TEST_CRONTAB=\"test-tool crontab cron.txt\" git maintenance stop &&\n+ \tGIT_TEST_MAINT_SCHEDULER=\"crontab:test-tool crontab cron.txt\" git maintenance stop &&\n \ttest_must_be_empty cron.txt\n '\n \n@@@ -446,22 -408,89 +459,105 @@@ test_expect_success 'start preserves ex\n \tgrep \"Important information!\" cron.txt\n '\n \n +test_expect_success 'magic markers are correct' '\n +\tgrep \"GIT MAINTENANCE SCHEDULE\" cron.txt >actual &&\n +\tcat >expect <<-\\EOF &&\n +\t# BEGIN GIT MAINTENANCE SCHEDULE\n +\t# END GIT MAINTENANCE SCHEDULE\n +\tEOF\n +\ttest_cmp actual expect\n +'\n +\n +test_expect_success 'stop preserves surrounding schedule' '\n +\techo \"Crucial information!\" >>cron.txt &&\n- \tGIT_TEST_CRONTAB=\"test-tool crontab cron.txt\" git maintenance stop &&\n++\tGIT_TEST_MAINT_SCHEDULER=\"crontab:test-tool crontab cron.txt\" git maintenance stop &&\n +\tgrep \"Important information!\" cron.txt &&\n +\tgrep \"Crucial information!\" cron.txt\n +'\n +\n+ test_expect_success 'start and stop macOS maintenance' '\n+ \t# ensure $HOME can be compared against hook arguments on all platforms\n+ \tpfx=$(cd \"$HOME\" && pwd) &&\n+ \n+ \twrite_script print-args <<-\\EOF &&\n+ \techo $* | sed \"s:gui/[0-9][0-9]*:gui/[UID]:\" >>args\n+ \tEOF\n+ \n+ \trm -f args &&\n+ \tGIT_TEST_MAINT_SCHEDULER=launchctl:./print-args git maintenance start &&\n+ \n+ \t# start registers the repo\n -\tgit config --get --global maintenance.repo \"$(pwd)\" &&\n++\tgit config --get --global --fixed-value maintenance.repo \"$(pwd)\" &&\n+ \n+ \tls \"$HOME/Library/LaunchAgents\" >actual &&\n+ \tcat >expect <<-\\EOF &&\n+ \torg.git-scm.git.daily.plist\n+ \torg.git-scm.git.hourly.plist\n+ \torg.git-scm.git.weekly.plist\n+ \tEOF\n+ \ttest_cmp expect actual &&\n+ \n+ \trm -f expect &&\n+ \tfor frequency in hourly daily weekly\n+ \tdo\n+ \t\tPLIST=\"$pfx/Library/LaunchAgents/org.git-scm.git.$frequency.plist\" &&\n+ \t\ttest_xmllint \"$PLIST\" &&\n+ \t\tgrep schedule=$frequency \"$PLIST\" &&\n+ \t\techo \"bootout gui/[UID] $PLIST\" >>expect &&\n+ \t\techo \"bootstrap gui/[UID] $PLIST\" >>expect || return 1\n+ \tdone &&\n+ \ttest_cmp expect args &&\n+ \n+ \trm -f args &&\n+ \tGIT_TEST_MAINT_SCHEDULER=launchctl:./print-args git maintenance stop &&\n+ \n+ \t# stop does not unregister the repo\n -\tgit config --get --global maintenance.repo \"$(pwd)\" &&\n++\tgit config --get --global --fixed-value maintenance.repo \"$(pwd)\" &&\n+ \n+ \tprintf \"bootout gui/[UID] $pfx/Library/LaunchAgents/org.git-scm.git.%s.plist\\n\" \\\n+ \t\thourly daily weekly >expect &&\n+ \ttest_cmp expect args &&\n+ \tls \"$HOME/Library/LaunchAgents\" >actual &&\n+ \ttest_line_count = 0 actual\n+ '\n+ \n+ test_expect_success 'start and stop Windows maintenance' '\n+ \twrite_script print-args <<-\\EOF &&\n+ \techo $* >>args\n+ \twhile test $# -gt 0\n+ \tdo\n+ \t\tcase \"$1\" in\n+ \t\t/xml) shift; xmlfile=$1; break ;;\n+ \t\t*) shift ;;\n+ \t\tesac\n+ \tdone\n+ \ttest -z \"$xmlfile\" || cp \"$xmlfile\" \"$xmlfile.xml\"\n+ \tEOF\n+ \n+ \trm -f args &&\n+ \tGIT_TEST_MAINT_SCHEDULER=\"schtasks:./print-args\" git maintenance start &&\n+ \n+ \t# start registers the repo\n -\tgit config --get --global maintenance.repo \"$(pwd)\" &&\n++\tgit config --get --global --fixed-value maintenance.repo \"$(pwd)\" &&\n+ \n+ \tfor frequency in hourly daily weekly\n+ \tdo\n+ \t\tgrep \"/create /tn Git Maintenance ($frequency) /f /xml\" args &&\n+ \t\tfile=$(ls .git/schedule_${frequency}*.xml) &&\n+ \t\ttest_xmllint \"$file\" || return 1\n+ \tdone &&\n+ \n+ \trm -f args &&\n+ \tGIT_TEST_MAINT_SCHEDULER=\"schtasks:./print-args\" git maintenance stop &&\n+ \n+ \t# stop does not unregister the repo\n -\tgit config --get --global maintenance.repo \"$(pwd)\" &&\n++\tgit config --get --global --fixed-value maintenance.repo \"$(pwd)\" &&\n+ \n+ \tprintf \"/delete /tn Git Maintenance (%s) /f\\n\" \\\n+ \t\thourly daily weekly >expect &&\n+ \ttest_cmp expect args\n+ '\n+ \n test_expect_success 'register preserves existing strategy' '\n \tgit config maintenance.strategy none &&\n \tgit maintenance register &&\n\n"},{"id":"414432","messageId":"xmqqmtxau2kj.fsf@gitster.c.googlers.com","threadId":"54964","inReplyTo":"xmqqr1mmu2nx.fsf@gitster.c.googlers.com","subject":"Re: What's cooking in git.git (Jan 2021, #02; Fri, 8)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-01-15T06:38:52Z","receivedAt":"2021-01-15T06:39:37Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> Here is how eventual merge of the topic into 'master' would resolve\n> conflicts. The straight merge chain from master..seen would have\n> such a merge with the resolution shown below, but 'next' already has\n> a mismerge, so I'll be applying a single-parent commit to fix the\n> mismerge directly on 'next' (which I'll send in a separate message).\n\nAnd this is the 'next' mismerge fix.\n\n----- >8 ----- >8 ----- >8 ----- >8 ----- >8 -----\nSubject: [PATCH] Fix mismerge of ds/maintenance-part-4 topic\n\nAt 1f98c859 (Merge branch 'ds/maintenance-part-4' into next, 2021-01-08)\nthe ds/maintenance-part-4 topic, which had an incorrect invocation\nof internal \"git config\" when $(pwd) had ERE special characters, was\nmerged into the mainline that added \"--fixed-value\" feature to the\n\"git config\" command to address this exact issue, and also changed\nhow test-tool stubbed out crontab calls.\n\nThe semantic conflicts for the latter have been fully resolved at\nthat commit, but four places that \"git config\" was invoked to look\nfor entries with the same value as \"$(pwd)\" were not adjusted to use\nthe \"--fixed-value\". They should have been.\n\nHelped-by: Emily Shaffer \nHelped-by: Taylor Blau \nHelped-by: Derrick Stolee \nSigned-off-by: Junio C Hamano \n---\n t/t7900-maintenance.sh | 8 ++++----\n 1 file changed, 4 insertions(+), 4 deletions(-)\n\ndiff --git a/t/t7900-maintenance.sh b/t/t7900-maintenance.sh\nindex 2e0c8a4c31..1074009cc0 100755\n--- a/t/t7900-maintenance.sh\n+++ b/t/t7900-maintenance.sh\n@@ -487,7 +487,7 @@ test_expect_success 'start and stop macOS maintenance' '\n \tGIT_TEST_MAINT_SCHEDULER=launchctl:./print-args git maintenance start &&\n \n \t# start registers the repo\n-\tgit config --get --global maintenance.repo \"$(pwd)\" &&\n+\tgit config --get --global --fixed-value maintenance.repo \"$(pwd)\" &&\n \n \tls \"$HOME/Library/LaunchAgents\" >actual &&\n \tcat >expect <<-\\EOF &&\n@@ -512,7 +512,7 @@ test_expect_success 'start and stop macOS maintenance' '\n \tGIT_TEST_MAINT_SCHEDULER=launchctl:./print-args git maintenance stop &&\n \n \t# stop does not unregister the repo\n-\tgit config --get --global maintenance.repo \"$(pwd)\" &&\n+\tgit config --get --global --fixed-value maintenance.repo \"$(pwd)\" &&\n \n \tprintf \"bootout gui/[UID] $pfx/Library/LaunchAgents/org.git-scm.git.%s.plist\\n\" \\\n \t\thourly daily weekly >expect &&\n@@ -538,7 +538,7 @@ test_expect_success 'start and stop Windows maintenance' '\n \tGIT_TEST_MAINT_SCHEDULER=\"schtasks:./print-args\" git maintenance start &&\n \n \t# start registers the repo\n-\tgit config --get --global maintenance.repo \"$(pwd)\" &&\n+\tgit config --get --global --fixed-value maintenance.repo \"$(pwd)\" &&\n \n \tfor frequency in hourly daily weekly\n \tdo\n@@ -551,7 +551,7 @@ test_expect_success 'start and stop Windows maintenance' '\n \tGIT_TEST_MAINT_SCHEDULER=\"schtasks:./print-args\" git maintenance stop &&\n \n \t# stop does not unregister the repo\n-\tgit config --get --global maintenance.repo \"$(pwd)\" &&\n+\tgit config --get --global --fixed-value maintenance.repo \"$(pwd)\" &&\n \n \tprintf \"/delete /tn Git Maintenance (%s) /f\\n\" \\\n \t\thourly daily weekly >expect &&\n-- \n2.30.0-386-gfb533afdb4\n\n"},{"id":"414433","messageId":"xmqqft32u0jp.fsf@gitster.c.googlers.com","threadId":"54964","inReplyTo":"YADaJ1gfbxQaLGXf@google.com","subject":"Re: What's cooking in git.git (Jan 2021, #02; Fri, 8)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-01-15T07:22:34Z","receivedAt":"2021-01-15T07:23:23Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Emily Shaffer writes:\n\n> Taking the time to redesign commit format (e.g. use user.id instead of\n> user.name/user.email) ...\n\nI have seen that \"ID\", which doesn't have permanent association to\n, has been raised as a solution from time to time, but\nI am not quite sure what problem is being solved. At some point,\nyou'd need to translate the \"ID\" to a way humans use to refer to\neach other---you cannot forever be saying \"Ah, commits by this\ncontributor #70763 is consistently good and seems to know the\nhistory traversal quite well. We wish who it is so that we can ask\nto review what we have been working on.\"\n\nSo we must have a mapping from ID to or something.\nHow is that mapping maintained? Even though Git is a version\ntracking system and the mapping will change over time, we'll only\nkeep the \"latest\"? That may not work very well, as a work for hire\ncontract a company made with one of the project participants would\nhave been made with a real person with a name, not just an anonymous\ncontributor #70763---the work done under the contract would not\nbecome invalid merely because mapping from ID to \nchanges, and those who made contract with a person with a certain\nname would want to make sure the contributor #70763 who made the\nwork is actually who they thought they had contract with.\n\nIf we do not keep track of the change of the mapping ourselves, the\necosystem around us will start doing so to fill the gap, so I do not\nthink use of \"ID\" would help you dissociate from your past self,\nwhile keeping the credit for your past commits.\n\nAnd if the mapping is version controlled in such a way that an \"ID\"\ncan be used to look up its name at any given time in the past, it\nwould not be so different from what we already have.\n\nOne advantage I could imagine that \"ID\" based system may have is\nthat one who wants to completely dissociate from an older name\nand/or email can just start using a totally different \"ID\" with\ntotally different name, and pretend that s/he has no relationship\nwith the old person associated with the old \"ID\", and nobody would\nbe able to tell. But again, I suspect that it can also be done\nwithout \"ID\". So...\n\n> ... also gives us room to improve other things we\n> don't like about the commit format (e.g. limited to single author).\n\nI personally think having \"author\" is a mistake, iff some people do\nnot like \"limited to a single author\". You can write everybody's\nname in the trailer as \"Co-Authored-by:\" and at that point you do\nnot need any author in the commit object header.\n\nBut that is so miniscule a feature that I do not think it is worth\nmaking a backward incompatible change to change the number of the\ncommit object header for the author from 1 to either 0 or many.\n\nAnyway, thanks for an opportunity for a (somewhat) fun thought\nexperiment.\n\nGoodnight.\n"},{"id":"414451","messageId":"49a151f1-a04c-703b-cf18-90cc503b0c80@gmail.com","threadId":"54964","inReplyTo":"xmqqmtxau2kj.fsf@gitster.c.googlers.com","subject":"Re: What's cooking in git.git (Jan 2021, #02; Fri, 8)","fromName":"Derrick Stolee","fromEmail":"stolee@gmail.com","sentAt":"2021-01-15T11:36:33Z","receivedAt":"2021-01-15T11:37:17Z","isPatch":false,"sender":{"key":"stolee@gmail.com","avatar":"https://avatars.githubusercontent.com/u/570044?v=4"},"body":"On 1/15/2021 1:38 AM, Junio C Hamano wrote:\n> Junio C Hamano writes:\n> \n>> Here is how eventual merge of the topic into 'master' would resolve\n>> conflicts. The straight merge chain from master..seen would have\n>> such a merge with the resolution shown below, but 'next' already has\n>> a mismerge, so I'll be applying a single-parent commit to fix the\n>> mismerge directly on 'next' (which I'll send in a separate message).\n> \n> And this is the 'next' mismerge fix.\n> \n> ----- >8 ----- >8 ----- >8 ----- >8 ----- >8 -----\n> Subject: [PATCH] Fix mismerge of ds/maintenance-part-4 topic\n> \n> At 1f98c859 (Merge branch 'ds/maintenance-part-4' into next, 2021-01-08)\n> the ds/maintenance-part-4 topic, which had an incorrect invocation\n> of internal \"git config\" when $(pwd) had ERE special characters, was\n> merged into the mainline that added \"--fixed-value\" feature to the\n> \"git config\" command to address this exact issue, and also changed\n> how test-tool stubbed out crontab calls.\n> \n> The semantic conflicts for the latter have been fully resolved at\n> that commit, but four places that \"git config\" was invoked to look\n> for entries with the same value as \"$(pwd)\" were not adjusted to use\n> the \"--fixed-value\". They should have been.\n\nThanks for dealing with this fallout. Sorry for the mixup.\n\n> Helped-by: Emily Shaffer \n\nWould it be appropriate to convert this to a Co-authored-by?\n\nThanks,\n-Stolee\n"},{"id":"414465","messageId":"xmqqturirnm5.fsf@gitster.c.googlers.com","threadId":"54964","inReplyTo":"49a151f1-a04c-703b-cf18-90cc503b0c80@gmail.com","subject":"Re: What's cooking in git.git (Jan 2021, #02; Fri, 8)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-01-15T19:44:50Z","receivedAt":"2021-01-15T19:45:45Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Derrick Stolee writes:\n\n> Thanks for dealing with this fallout. Sorry for the mixup.\n>\n>> Helped-by: Emily Shaffer \n>\n> Would it be appropriate to convert this to a Co-authored-by?\n\nOr more like \"Inspired-by-a-patch-by\". Also you three have about\nthe same amount of input and deserve credit.\n\nSorry, but it already is on 'next', which will be discarded in a few\nmonths when the new cycle begins, so I am not sure if it is worth\nreverting and reapplying with updated credit trailers.\n\nFWIW, I ended up redoing the merge and did \"checkout -m\" to recreate\nconflicts, and then looked for \"config.*pwd\" in the block of text\nthat came from the \"part-4\" topic and fixed them up manually. I\nthen compared the result of this new merge with the earlier merge\nthat had the issue. The resulting diff is what went into the patch\nyou are responding to. It is good that we had Emily's input as a\ncomparison material to see that both of us independently touched the\nsame places to fix.\n\nBy the way, the merge into 'master' will directly reuse the conflict\nresolution of e47c3632 (Merge branch 'ds/maintenance-part-4' into\njch, 2021-01-14) from the rerere database, without any separate\n\"merge fix\" commit.\n\nThanks.\n"},{"id":"414466","messageId":"YAHyZbJNhvZUowIq@coredump.intra.peff.net","threadId":"54964","inReplyTo":"xmqqk0sni68g.fsf@gitster.c.googlers.com","subject":"Re: What's cooking in git.git (Jan 2021, #02; Fri, 8)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2021-01-15T19:52:05Z","receivedAt":"2021-01-15T19:52:48Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Jan 08, 2021 at 11:22:23AM -0800, Junio C Hamano wrote:\n\n> * ps/config-env-pairs (2021-01-06) 8 commits\n> - config: allow specifying config entries via envvar pairs\n> - environment: make `getenv_safe()` a public function\n> - config: parse more robust format in GIT_CONFIG_PARAMETERS\n> - config: store \"git -c\" variables using more robust format\n> - config: extract function to parse config pairs\n> - quote: make sq_dequote_step() a public function\n> - config: add new way to pass config via `--config-env`\n> - git: add `--super-prefix` to usage string\n> \n> Introduce two new ways to feed configuration variable-value pairs\n> via environment variables, and tweak the way GIT_CONFIG_PARAMETERS\n> encodes variable/value pairs to make it more robust.\n> \n> Ready for 'next'?\n\nI looked over the first 7, and noticed two of the patches are flipped in\nroder (I sent a separate reply in the thread, but I wanted to catch your\nattention, since I guess this may be on the list for integrating today).\n\nI didn't see any problems in the code of the 8th one, but I didn't spend\na lot of brain power thinking about the overall design. I feel like that\nwas hashed out pretty well in the early discussions, though.\n\n-Peff\n"},{"id":"414472","messageId":"YAH2Qc/ad+P9Pf26@google.com","threadId":"54964","inReplyTo":"xmqqturirnm5.fsf@gitster.c.googlers.com","subject":"Re: What's cooking in git.git (Jan 2021, #02; Fri, 8)","fromName":"Emily Shaffer","fromEmail":"emilyshaffer@google.com","sentAt":"2021-01-15T20:08:33Z","receivedAt":"2021-01-15T20:09:22Z","isPatch":false,"sender":{"key":"nasamuffin@google.com","avatar":"https://avatars.githubusercontent.com/u/1606826?v=4"},"body":"On Fri, Jan 15, 2021 at 11:44:50AM -0800, Junio C Hamano wrote:\n> \n> Derrick Stolee writes:\n> \n> > Thanks for dealing with this fallout. Sorry for the mixup.\n> >\n> >> Helped-by: Emily Shaffer \n> >\n> > Would it be appropriate to convert this to a Co-authored-by?\n> \n> Or more like \"Inspired-by-a-patch-by\". Also you three have about\n> the same amount of input and deserve credit.\n> \n> Sorry, but it already is on 'next', which will be discarded in a few\n> months when the new cycle begins, so I am not sure if it is worth\n> reverting and reapplying with updated credit trailers.\n> \n> FWIW, I ended up redoing the merge and did \"checkout -m\" to recreate\n> conflicts, and then looked for \"config.*pwd\" in the block of text\n> that came from the \"part-4\" topic and fixed them up manually. I\n> then compared the result of this new merge with the earlier merge\n> that had the issue. The resulting diff is what went into the patch\n> you are responding to. It is good that we had Emily's input as a\n> comparison material to see that both of us independently touched the\n> same places to fix.\n\nThanks for the action on this, glad to see it resolved in 'next' when I\npull today.\n\n - Emily\n"},{"id":"414474","messageId":"xmqqczy5syqt.fsf@gitster.c.googlers.com","threadId":"54964","inReplyTo":"YAH2Qc/ad+P9Pf26@google.com","subject":"Re: What's cooking in git.git (Jan 2021, #02; Fri, 8)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-01-15T20:59:06Z","receivedAt":"2021-01-15T20:59:53Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Emily Shaffer writes:\n\n> Thanks for the action on this, glad to see it resolved in 'next' when I\n> pull today.\n\nThanks for double checking.\n"},{"id":"414475","messageId":"xmqqv9bxri9n.fsf@gitster.c.googlers.com","threadId":"54964","inReplyTo":"YAHyZbJNhvZUowIq@coredump.intra.peff.net","subject":"Re: What's cooking in git.git (Jan 2021, #02; Fri, 8)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-01-15T21:40:20Z","receivedAt":"2021-01-15T21:41:20Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> I looked over the first 7, and noticed two of the patches are flipped in\n> roder (I sent a separate reply in the thread, but I wanted to catch your\n> attention, since I guess this may be on the list for integrating today).\n\nThanks. Let's \"rebase -i\" the kinks out before merging it.\n\n> I didn't see any problems in the code of the 8th one, but I didn't spend\n> a lot of brain power thinking about the overall design. I feel like that\n> was hashed out pretty well in the early discussions, though.\n\nThe same here. I do not have a need for the KEY/VALUE pairs myself,\nbut I think the design is sound and I didn't see anything wrong in\nthe implementation.\n"},{"id":"414499","messageId":"87im7w4zqt.fsf@evledraar.gmail.com","threadId":"54964","inReplyTo":"YADZSsVqyGnArF0n@google.com","subject":"Re: What's cooking in git.git (Jan 2021, #02; Fri, 8)","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2021-01-16T16:23:38Z","receivedAt":"2021-01-16T17:09:57Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Fri, Jan 15 2021, Emily Shaffer wrote:\n\n> On Tue, Jan 12, 2021 at 03:00:30PM +0100, Ævar Arnfjörð Bjarmason wrote:\n>> \n>> \n>> On Mon, Jan 11 2021, Junio C Hamano wrote:\n>> \n>> > \"brian m. carlson\" writes:\n>> >\n>> >> On 2021-01-09 at 23:20:25, Junio C Hamano wrote:\n>> >>> \"brian m. carlson\" writes:\n>> >>> \n>> >>> > On 2021-01-09 at 21:28:58, Junio C Hamano wrote:\n>> >>> >> Ævar Arnfjörð Bjarmason writes:\n>> >>> >> > FWIW there was since a re-roll on 2021-01-03, but the discussion is\n>> >>> >> > sort-of outstanding, so maybe that's intentional...\n>> >>> >> \n>> >>> >> I had an impression that those 4 or 5 patches haven't gained\n>> >>> >> concensus that they are good as-is.\n>> >>> >\n>> >>> > There will be another reroll. I'm hoping to get to it this weekend.\n>> >>> \n>> >>> Thanks.\n>> >>\n>> >> Having read Ævar's latest comment, I've decided instead to drop this, so\n>> >> feel free to do so whenever it's convenient.\n>> >\n>> > That's kind of sad.\n>> \n>> Agreed. I mean, I'm just one contributor with an opinion. I certainly\n>> don't mean my \"meh\" on a patch to be some sort of veto.\n>> \n>> If you follow this list you'll see that if you're going to take anyone's\n>> opinion on whether a thing should make it into git as a matter of\n>> empirical data on patches I submit that aren't changed meaningfully,\n>> then, uh, maybe pick someone else :)\n>> \n>> > I view that this is the kind of topic where perfect easily can\n>> > become an enemy of good, as there is by definition no perfection\n>> > available to us without breaking existing Git.\n>> >\n>> > I do not know about Ævar, but to me, my initial impression while\n>> > reading the discussion from sideline was that the goal was to\n>> > prevent a mechanical scan of a recent version of .mailmap from\n>> > learning that Joe used to use Jane as his/her name, and that was the\n>> > reason why I asked to be convinced why encoding for obfuscation was\n>> > insufficient. In the above, I meant \"mechanical scan\" as something\n>> > like \"a web search engine crawls and finds a .mailmap---a query for\n>> > Joe produces a line with some garbage on it that is not Jane.\" and a\n>> > casual attacker would stop there.\n>> >\n>> > But of course, a casual attacker who knows urlencode or whatever\n>> > obfuscation in use can read that \"garbage\" once he/she knows that\n>> > \"garbage\" is worth attacking (i.e. it is known to be associated to\n>> > Joe, the person the attacker is interested in).\n>> >\n>> > If your goal is to make it harder than just urlencode, even though\n>> > we all have to accept that scanning \"git log --all\" for all names\n>> > that appear in the history and hashing them all to see what name\n>> > hashes to the \"garbage\" in question, then @sha256: approach\n>> > does make sense as a stopping point. Perhaps we need to sell this\n>> > with a clear definition of what kind of attackes we are protecting\n>> > the name data from:\n>> >\n>> > The attacker is required to obtain sufficient amount of history\n>> > in the project to uncover the obfuscation; a more casual\n>> > attackers will fail to uncover, and we declare that it is better\n>> > than nothing and it is good enough in practice.\n>> >\n>> > or something like that? I am not sure if I drew the line at the\n>> > level you intended to draw in the above, if I think that it is good\n>> > enough in practice, or if I agree to a change that is better than\n>> > nothing but not good enough in practice, but having such a statement\n>> > would help to see where we agree or disagree.\n>> \n>> My reading of the general thread & brian's reply at [1] is that the\n>> difference in the minds of the users who want the feature (who're not\n>> on-list, and we're getting brian's's summary of their views) is closer\n>> to:\n>> \n>> We want the X-Y problem of \"hide this data\" solved with solution \"Y\"\n>> because git's current tooling to retrieve the data is currently\n>> rather tedious & obscure.\n>> \n>> So when I asked whether those users would feel the same if the tooling\n>> was less tedious and suggested that I might patch it to be so brian\n>> replied with \"[yes,] we do rely on this being inconvenient\".\n>> \n>> I do have a 20-something series patch to the mailmap code in my local\n>> queue that in the light of this series's status I think I'll submit\n>> soon.\n>> \n>> It doesn't have anything to do with adding a \"spew out a materialized\n>> map\" feature currently, nor do I really plan to do that any time soon. I\n>> do genuinely think it would be a good addition to git for reasons that\n>> have nothing to do with trying to make a point about this\n>> series. E.g. you'd be able to more easily validate/check/fsck a mailmap\n>> that way. Or e.g. use a git repository's .mailmap as a source to export\n>> to your MTA rules or whatever.\n>> \n>> The external tools I referred to which consume the exported .mailmap\n>> data are something I worked on at a previous job, but I no longer have\n>> that immediate itch to scratch personally.\n>> \n>> The \"march of history\" point was rather that if the difference between\n>> URI encoding and this solution is current tooling, it seems all but\n>> inevitable that we'll bridge that gap sooner than later in a way that\n>> makes that difference useless to some of the users that want this now.\n>> \n>> And not even because some people don't like this feature in particular\n>> and wish to submit patches to make it less useful. But just because we\n>> continue implementing stuff that's been talked about for years & is\n>> being generally slowly worked towards. E.g. more client<->server\n>> cooperation for expensive queries over protocol v2, or a filter clone\n>> mode where you get only commit objects.\n>> \n>> It even seems like something brian's series itself could benefit\n>> from. I.e. having the hashed values in the history is a performance hit\n>> in some cases. The patch caches the computation.\n>> \n>> Another way to do it would be to just save a\n>> \".git/objects/info/mailmap.{hash-of-original-file}\". Either on the fly\n>> or generated by \"maintenance\" or whatever. It would guarantee a 0%\n>> performance hit. At that point we'd already have the plumbing to\n>> materialize the file & would need to go out of our way to make it\n>> inaccessible in porcelain.\n>\n> I've got quite a few sporadic thoughts about this series and this\n> discussion, so I'll braindump and hopefully it turns into something\n> useful.\n>\n> Firstly: this design comes from a conversation amongst a pretty small (4\n> people? 6 people?) group at the virtual inclusion summit some months\n> ago.\n\nAs a brief aside I did attend that virtual inclusion summit, but had to\nmostly not attend it in practice for timezone reasons. So this was one\nof the discussions/groups I managed to miss entirely.\n\nThere's some small joke in there somewhere about the inclusivity of the\ninclusion summit being a function of how close you are to California :)\n\n> At that time, we discussed the ease of brute-force decoding the\n> one-way-hashed mailmap and decided that, as long as Git didn't ship a\n> tool to do this for you for free, it was better than the current\n> solution for avoiding deadnames (i.e. \"sorry\"). I'm disappointed to see\n> the larger list feel otherwise, but not terribly surprised, since the\n> list contains more people than the group who came up with the design.\n\nI think it has less to do with the list containing more people, and more\nto do with no versions of the patch making any mention of this idea or\napproach implicitly relying on a forward promise that there never be\nsuch a tool shipped with git.\n\nHaving found that out in trying to help this topic along I still think\nthat's very questionable approach in the terms of helping the users\nyou're concerned about.\n\nFor one what most people think about as \"I'm looking at the thing in\nGit\" isn't UI controlled by us, but probably some website or Git GUI. So\nany commitment we make about not implementing something in git.git is at\nbest going to be rather ineffective in the grand scheme of things.\n\nBut at least stating that upfront doesn't require the rest of us to read\nminds.\n\nAnd let's be clear, I'm not putting any blame on anyone's shoulders\n(least of all brian's) for that. Just pointing out that our patch review\nprocess works best when stated aims, caveats, implicit assumptions\netc. with a given technical are all clearly stated.\n\n> [...]\n> Thirdly: As is stated elsewhere, I think this topic is falling victim to\n> perfect vs. good. Git is gaining increasing notoriety in circles I can\n> see about the ultimately crappy experience for people who change their\n> names and don't want to hear the old names (and don't want to know the\n> old names). [...]\n\n> So I feel sad to see the topic dropped because of pushback[...]\n\nThe topic is currently dropped because the submitted requested it to be\ndropped (see upthread,\nhttps://lore.kernel.org/git/X%2Fuvhc5Hpu792qA%2F@camp.crustytoothpaste.net/). When\na submitter asks Junio to drop a topic he'll usually just do it. So it's\nconvenient because of any pushback from me or anyone else.\n\nI'm only replying to this part because...\n\n> [...] especially when that pushback is \"I'd like to write a tool to\n> reverse this thing, because - and I don't mean that\n> tool maliciously so that should be OK.\"\n\n... this point in particular seems to be an attempt to summarize my\nviews or motivations.\n\nI don't see how you could read my E-Mails on the subject (especially\nwhat you're replying to,\nhttps://lore.kernel.org/git/87k0si5k75.fsf@evledraar.gmail.com/) and\nthink that in any way reflects my views on the matter.\n\nIn lieu of repeating much/any of that I'll just say that that doesn't in\nany way reflect my views, and from having read all the rest of the\nmessage traffic associated with this topic I don't see who else you\ncould be referring to with those comments.\n"},{"id":"414555","messageId":"YARwrtU9u51s13S0@coredump.intra.peff.net","threadId":"54964","inReplyTo":"87im7w4zqt.fsf@evledraar.gmail.com","subject":"Re: What's cooking in git.git (Jan 2021, #02; Fri, 8)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2021-01-17T17:15:26Z","receivedAt":"2021-01-17T17:16:25Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Jan 16, 2021 at 05:23:38PM +0100, Ævar Arnfjörð Bjarmason wrote:\n\n> > [...] especially when that pushback is \"I'd like to write a tool to\n> > reverse this thing, because - and I don't mean that\n> > tool maliciously so that should be OK.\"\n> \n> ... this point in particular seems to be an attempt to summarize my\n> views or motivations.\n> \n> I don't see how you could read my E-Mails on the subject (especially\n> what you're replying to,\n> https://lore.kernel.org/git/87k0si5k75.fsf@evledraar.gmail.com/) and\n> think that in any way reflects my views on the matter.\n> \n> In lieu of repeating much/any of that I'll just say that that doesn't in\n> any way reflect my views, and from having read all the rest of the\n> message traffic associated with this topic I don't see who else you\n> could be referring to with those comments.\n\nThis is sort orthogonal to what you're saying here, and possibly I\nmissed this part of the discussion, but...I'm confused about this\ntalk of a tool for unblinding the mailmap. Isn't:\n\n git log --all --format='%aE %ae'\n\nbasically that tool already?\n\n-Peff\n"},{"id":"414557","messageId":"87wnwb8ga8.fsf@evledraar.gmail.com","threadId":"54964","inReplyTo":"YARwrtU9u51s13S0@coredump.intra.peff.net","subject":"Re: What's cooking in git.git (Jan 2021, #02; Fri, 8)","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2021-01-17T20:22:39Z","receivedAt":"2021-01-17T20:23:43Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Sun, Jan 17 2021, Jeff King wrote:\n\n> On Sat, Jan 16, 2021 at 05:23:38PM +0100, Ævar Arnfjörð Bjarmason wrote:\n>\n>> > [...] especially when that pushback is \"I'd like to write a tool to\n>> > reverse this thing, because - and I don't mean that\n>> > tool maliciously so that should be OK.\"\n>> \n>> ... this point in particular seems to be an attempt to summarize my\n>> views or motivations.\n>> \n>> I don't see how you could read my E-Mails on the subject (especially\n>> what you're replying to,\n>> https://lore.kernel.org/git/87k0si5k75.fsf@evledraar.gmail.com/) and\n>> think that in any way reflects my views on the matter.\n>> \n>> In lieu of repeating much/any of that I'll just say that that doesn't in\n>> any way reflect my views, and from having read all the rest of the\n>> message traffic associated with this topic I don't see who else you\n>> could be referring to with those comments.\n>\n> This is sort orthogonal to what you're saying here, and possibly I\n> missed this part of the discussion, but...I'm confused about this\n> talk of a tool for unblinding the mailmap. Isn't:\n>\n> git log --all --format='%aE %ae'\n>\n> basically that tool already?\n\nYes, but I belive from brian's mails on the topic[1][2][3] that the\nissue at hand is that doing that is just the right level of\ninconvienience in the minds of the users who want this feature, and that\ne.g. having some/any of:\n\n git check-mailmap --porcelain --materialize-hashed\n git for-each-mailmap --format=\"%(authornamefrom:unhashed) %(authoremailfrom:unhashed) %(authornameto)\"\n git ask-remote https://github.com/chromium/chromium -- # (or whatever..)\n \n\nWould tip it over the edge into the territory of this\nsocially-signalled-to-be-private information being too convenient to\nextract from the DAG.\n\n1. https://lore.kernel.org/git/X%2FtxB8b3%2FqqbwbmC@camp.crustytoothpaste.net/\n2. https://lore.kernel.org/git/YADh2DHDrdAs6Jbj@camp.crustytoothpaste.net/\n3. https://lore.kernel.org/git/X9xEnpLeZ4mCjwWF@coredump.intra.peff.net/\n"}]}