{"thread":{"id":"51527","subject":"What's cooking in git.git (Jul 2019, #06; Thu, 25)","startedAt":"2019-07-26T00:19:44Z","lastAt":"2019-08-12T13:40:04Z","messageCount":27,"participants":["Junio C Hamano","Johannes Schindelin","Rohit Ashiwal","Elijah Newren","Carlo Arenas","Taylor Blau","Ariadne Conill","Phil Hord","Jeff King","Randall S. Becker"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"379322","messageId":"xmqq36itprzo.fsf@gitster-ct.c.googlers.com","threadId":"51527","inReplyTo":null,"subject":"What's cooking in git.git (Jul 2019, #06; Thu, 25)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2019-07-26T00:19:23Z","receivedAt":"2019-07-26T00:19:44Z","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\n'-' are only in 'pu' (proposed updates) while commits prefixed with\n'+' are in 'next'. The ones marked with '.' do not appear in any of\nthe integration branches, but I am still holding onto them.\n\nThe seventh batch is in; I've merged fix-up topics that has been in\n'master' for some time (i.e. up to the third batch of this cycle)\ndown to 'maint'.\n\nYou can find the changes described here in the integration branches\nof the repositories listed at\n\n http://git-blame.blogspot.com/p/git-public-repositories.html\n\n--------------------------------------------------\n[Graduated to \"master\"]\n\n* ab/test-env (2019-07-11) 9 commits\n (merged to 'next' on 2019-07-15 at 42e86beb20)\n + env--helper: mark a file-local symbol as static\n (merged to 'next' on 2019-07-09 at 096658f382)\n + tests: make GIT_TEST_FAIL_PREREQS a boolean\n + tests: replace test_tristate with \"git env--helper\"\n + tests README: re-flow a previously changed paragraph\n + tests: make GIT_TEST_GETTEXT_POISON a boolean\n + t6040 test: stop using global \"script\" variable\n + config.c: refactor die_bad_number() to not call gettext() early\n + env--helper: new undocumented builtin wrapping git_env_*()\n + config tests: simplify include cycle test\n\n Many GIT_TEST_* environment variables control various aspects of\n how our tests are run, but a few followed \"non-empty is true, empty\n or unset is false\" while others followed the usual \"there are a few\n ways to spell true, like yes, on, etc., and also ways to spell\n false, like no, off, etc.\" convention.\n\n\n* ac/log-use-mailmap-by-default-transition (2019-07-15) 3 commits\n (merged to 'next' on 2019-07-19 at e5669de950)\n + tests: defang pager tests by explicitly disabling the log.mailmap warning\n + documentation: mention --no-use-mailmap and log.mailmap false setting\n + log: add warning for unspecified log.mailmap setting\n\n The \"git log\" command learns to issue a warning when log.mailmap\n configuration is not set and --[no-]mailmap option is not used, to\n prepare users for future versions of Git that uses the mailmap by\n default.\n\n\n* di/readme-markup-fix (2019-07-18) 1 commit\n (merged to 'next' on 2019-07-19 at 339470d824)\n + README: fix rendering of text in angle brackets\n\n Docfix.\n\n\n* es/local-atomic-push-failure-with-http (2019-07-16) 2 commits\n (merged to 'next' on 2019-07-19 at 8d5b776a96)\n + transport-helper: avoid var decl in for () loop control\n (merged to 'next' on 2019-07-15 at 960e92d24f)\n + transport-helper: enforce atomic in push_refs_with_push\n\n \"git push --atomic\" that goes over the transport-helper (namely,\n the smart http transport) failed to prevent refs to be pushed when\n it can locally tell that one of the ref update will fail without\n having to consult the other end, which has been corrected.\n\n\n* jc/denoise-rm-to-resolve (2019-07-18) 1 commit\n (merged to 'next' on 2019-07-19 at 12f7e5d413)\n + rm: resolving by removal is not a warning-worthy event\n\n \"git rm\" to resolve a conflicted path leaked an internal message\n \"needs merge\" before actually removing the path, which was\n confusing. This has been corrected.\n\n\n* jc/post-c89-rules-doc (2019-07-18) 1 commit\n (merged to 'next' on 2019-07-19 at 8acd58e189)\n + CodingGuidelines: spell out post-C89 rules\n\n We have been trying out a few language features outside c89; the\n coding guidelines document did not talk about them and instead had\n a blanket ban against them.\n\n\n* jk/test-commit-bulk (2019-07-23) 6 commits\n (merged to 'next' on 2019-07-23 at edc849c7dd)\n + t6200: use test_commit_bulk\n + t5703: use test_commit_bulk\n + t5702: use test_commit_bulk\n + t3311: use test_commit_bulk\n + t5310: increase the number of bitmapped commits\n + test-lib: introduce test_commit_bulk\n\n A test helper has been introduced to optimize preparation of test\n repositories with many simple commits, and a handful of test\n scripts have been updated to use it.\n\n\n* js/clean-report-too-long-a-path (2019-07-19) 1 commit\n (merged to 'next' on 2019-07-19 at b7da0a821c)\n + clean: show an error message when the path is too long\n\n \"git clean\" silently skipped a path when it cannot lstat() it; now\n it gives a warning.\n\n\n* js/mingw-spawn-with-spaces-in-path (2019-07-16) 1 commit\n (merged to 'next' on 2019-07-19 at 33dd6d0401)\n + mingw: support spawning programs containing spaces in their names\n\n Window 7 update ;-)\n\n\n* js/unmap-before-ext-diff (2019-07-11) 1 commit\n (merged to 'next' on 2019-07-15 at 7aa292c66c)\n + diff: munmap() file contents before running external diff\n\n Windows update.\n\n\n* mt/dir-iterator-updates (2019-07-11) 10 commits\n (merged to 'next' on 2019-07-19 at 2ebb586ce6)\n + clone: replace strcmp by fspathcmp\n + clone: use dir-iterator to avoid explicit dir traversal\n + clone: extract function from copy_or_link_directory\n + clone: copy hidden paths at local clone\n + dir-iterator: add flags parameter to dir_iterator_begin\n + dir-iterator: refactor state machine model\n + dir-iterator: use warning_errno when possible\n + dir-iterator: add tests for dir-iterator API\n + clone: better handle symlinked files at .git/objects/\n + clone: test for our behavior on odd objects/* content\n\n Adjust the dir-iterator API and apply it to the local clone\n optimization codepath.\n\n\n* rm/gpg-program-doc-fix (2019-07-12) 1 commit\n (merged to 'next' on 2019-07-15 at ef358ec2e9)\n + gpg(docs): use correct --verify syntax\n\n Docfix.\n\n\n* sr/gpg-interface-stop-at-the-end (2019-07-16) 1 commit\n (merged to 'next' on 2019-07-19 at 5d38aa1236)\n + gpg-interface: do not scan past the end of buffer\n\n A codepath that reads from GPG for signed object verification read\n past the end of allocated buffer, which has been fixed.\n\n\n* tg/range-diff-output-update (2019-07-11) 14 commits\n (merged to 'next' on 2019-07-15 at b847d206ed)\n + range-diff: add headers to the outer hunk header\n + range-diff: add filename to inner diff\n + range-diff: add section header instead of diff header\n + range-diff: suppress line count in outer diff\n + range-diff: don't remove funcname from inner diff\n + range-diff: split lines manually\n + range-diff: fix function parameter indentation\n + apply: make parse_git_diff_header public\n + apply: only pass required data to gitdiff_* functions\n + apply: only pass required data to find_name_*\n + apply: only pass required data to check_header_line\n + apply: only pass required data to git_header_name\n + apply: only pass required data to skip_tree_prefix\n + apply: replace marc.info link with public-inbox\n\n \"git range-diff\" output has been tweaked for easier identification\n of which part of what file the patch shown is about.\n\n\n* tg/stash-keep-index-with-removed-paths (2019-07-16) 1 commit\n (merged to 'next' on 2019-07-19 at d4ae24a939)\n + stash: fix handling removed files with --keep-index\n\n \"git stash --keep-index\" did not work correctly on paths that have\n been removed, which has been fixed.\n\n\n* vn/xmmap-gently (2019-07-14) 1 commit\n (merged to 'next' on 2019-07-19 at d95c1d2be3)\n + read-cache.c: do not die if mmap fails\n\n Clean-up an error codepath.\n\n--------------------------------------------------\n[New Topics]\n\n* bb/grep-pcre2-bug-message-fix (2019-07-23) 1 commit\n (merged to 'next' on 2019-07-23 at 8bd5a68618)\n + grep: print the pcre2_jit_on value\n\n BUG() message fix.\n\n The codepath may want to just simply be removed, though.\n\n\n* ra/rebase-i-more-options (2019-07-23) 4 commits\n - SQUASH???\n - rebase -i: support --committer-date-is-author-date\n - sequencer: add NULL checks under read_author_script\n - rebase -i: add --ignore-whitespace flag\n\n \"git rebase -i\" learned a few options that are known by \"git\n rebase\" proper.\n\n Needs a bit of fixups, at least.\n\n\n* sg/travis-gcc-4.8 (2019-07-19) 1 commit\n (merged to 'next' on 2019-07-25 at e3d546eb15)\n + travis-ci: build with GCC 4.8 as well\n\n Add a job to build with a tad older GCC to make sure we are still\n buildable.\n\n Will merge to 'master'.\n\n\n* ab/pcre-jit-fixes (2019-07-24) 3 commits\n - grep: stop using a custom JIT stack with PCRE v1\n - grep: stop \"using\" a custom JIT stack with PCRE v2\n - grep: remove overly paranoid BUG(...) code\n\n A few simplification and bugfixes to PCRE interface.\n\n Will merge to 'next'.\n\n\n* jk/xdiff-clamp-funcname-context-index (2019-07-23) 1 commit\n (merged to 'next' on 2019-07-25 at b2944a0ba6)\n + xdiff: clamp function context indices in post-image\n\n The internal diff machinery can be made to read out of bounds while\n looking for --funcion-context line in a corner case, which has been\n corrected.\n\n Will merge to 'master'.\n\n\n* js/rebase-cleanup (2019-07-25) 2 commits\n (merged to 'next' on 2019-07-25 at 3d9cedf470)\n + git: mark cmd_rebase as requiring a worktree\n + rebase: fix white-space\n\n A few leftover cleanup to \"git rebase\" in C.\n\n Will merge to 'master'.\n\n\n* js/rebase-r-strategy (2019-07-25) 12 commits\n - rebase -r: do not (re-)generate root commits with `--root` *and* `--onto`\n - t3418: test `rebase -r` with merge strategies\n - t/lib-rebase: prepare for testing `git rebase --rebase-merges`\n - rebase -r: support merge strategies other than `recursive`\n - t3427: mark two test cases as requiring support for `git rebase -p`\n - t3427: fix another incorrect assumption\n - t3427: accommodate for the `rebase --merge` backend having been replaced\n - t3427: fix erroneous assumption\n - t3427: condense the unnecessarily repetitive test cases into three\n - t3427: move the `filter-branch` invocation into the `setup` case\n - t3427: simplify the `setup` test case significantly\n - t3427: add a clarifying comment\n\n \"git rebase --rebase-merges\" learned to drive different merge\n strategies and pass strategy specific options to them.\n\n\n* js/trace2-json-schema (2019-07-25) 3 commits\n - ci: run trace2 schema validation in the CI suite\n - trace2: add a schema validator for trace2 events\n - trace2: add a JSON schema for trace2 events\n\n The JSON output produced by \"trace2\" subsystem now has JSON schema\n defined on it, to allow us validate the output and catch deviation.\n\n The CI integration may be a bit too heavy-handed.\n\n--------------------------------------------------\n[Stalled]\n\n* cb/xdiff-no-system-includes-in-dot-c (2019-06-19) 1 commit\n - xdiff: avoid accidental redefinition of LFS feature in OpenIndiana\n\n Compilation fix.\n\n Will be rerolled together with patches from the\n jk/no-system-includes-in-dot-c topic.\n\n\n* jk/no-system-includes-in-dot-c (2019-06-19) 2 commits\n - wt-status.h: drop stdio.h include\n - verify-tag: drop signal.h include\n\n Compilation fix.\n\n Will be rerolled with the above.\n\n\n* nd/index-dump-in-json (2019-06-26) 11 commits\n - SQUASH???\n - t3008: use the new SINGLE_CPU prereq\n - read-cache.c: dump \"IEOT\" extension as json\n - read-cache.c: dump \"EOIE\" extension as json\n - resolve-undo.c: dump \"REUC\" extension as json\n - fsmonitor.c: dump \"FSMN\" extension as json\n - split-index.c: dump \"link\" extension as json\n - dir.c: dump \"UNTR\" extension as json\n - cache-tree.c: dump \"TREE\" extension as json\n - read-cache.c: dump common extension info in json\n - ls-files: add --json to dump the index\n\n \"ls-files\" learned \"--debug-json\" option to dump the contents and\n the extensions of the index file.\n\n At least the fixup at the tip needs to be squashed into the right\n commit. Also the new test seems flaky.\n\n\n* jn/unknown-index-extensions (2018-11-21) 2 commits\n - index: offer advice for unknown index extensions\n - index: do not warn about unrecognized extensions\n\n A bit too alarming warning given when unknown index extensions\n exist is getting revamped.\n\n Expecting a reroll.\n\n\n* jc/format-patch-delay-message-id (2019-04-05) 1 commit\n - format-patch: move message-id and related headers to the end\n\n The location \"git format-patch --thread\" adds the Message-Id:\n header in the series of header fields has been moved down, which\n may help working around a suspected bug in GMail MSA, reported at\n \n\n Waiting for feedback to see if it truly helps.\n Needs tests.\n\n\n* jt/fetch-cdn-offload (2019-03-12) 9 commits\n - SQUASH???\n - upload-pack: send part of packfile response as uri\n - fetch-pack: support more than one pack lockfile\n - upload-pack: refactor reading of pack-objects out\n - Documentation: add Packfile URIs design doc\n - Documentation: order protocol v2 sections\n - http-fetch: support fetching packfiles by URL\n - http: improve documentation of http_pack_request\n - http: use --stdin when getting dumb HTTP pack\n\n WIP for allowing a response to \"git fetch\" to instruct the bulk of\n the pack contents to be instead taken from elsewhere (aka CDN).\n\n\n* js/protocol-advertise-multi (2018-12-28) 1 commit\n - protocol: advertise multiple supported versions\n\n The transport layer has been updated so that the protocol version\n used can be negotiated between the parties, by the initiator\n listing the protocol versions it is willing to talk, and the other\n side choosing from one of them.\n\n Expecting a reroll.\n cf. \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* dl/remote-save-to-push (2018-12-11) 1 commit\n - remote: add --save-to-push option to git remote set-url\n\n \"git remote set-url\" learned a new option that moves existing value\n of the URL field to pushURL field of the remote before replacing\n the URL field with a new value.\n\n Anybody who wants to champion this topic?\n I am personally not yet quite convinced if this is worth pursuing.\n\n--------------------------------------------------\n[Cooking]\n\n* js/builtin-add-i (2019-07-18) 11 commits\n - built-in add -i: implement the `help` command\n - built-in add -i: use color in the main loop\n - built-in add -i: support `?` (prompt help)\n - built-in add -i: show unique prefixes of the commands\n - Add a function to determine unique prefixes for a list of strings\n - built-in add -i: implement the main loop\n - built-in add -i: color the header in the `status` command\n - built-in add -i: refresh the index before running `status`\n - built-in add -i: implement the `status` command\n - diff: export diffstat interface\n - Start to implement a built-in version of `git add --interactive`\n\n The beginning of rewriting \"git add -i\" in C.\n\n\n* js/visual-studio (2019-07-18) 24 commits\n - git: avoid calling aliased builtins via their dashed form\n - t5505,t5516: create .git/branches/ when needed\n - bin-wrappers: append `.exe` to target paths if necessary\n - .gitignore: ignore Visual Studio's temporary/generated files\n - .gitignore: touch up the entries regarding Visual Studio\n - vcxproj: also link-or-copy builtins\n - msvc: add a Makefile target to pre-generate the Visual Studio solution\n - contrib/buildsystems: add a backend for modern Visual Studio versions\n - contrib/buildsystems: handle options starting with a slash\n - contrib/buildsystems: also handle -lexpat\n - contrib/buildsystems: handle libiconv, too\n - contrib/buildsystems: handle the curl library option\n - contrib/buildsystems: error out on unknown option\n - contrib/buildsystems: optionally capture the dry-run in a file\n - contrib/buildsystems: redirect errors of the dry run into a log file\n - contrib/buildsystems: ignore gettext stuff\n - contrib/buildsystems: handle quoted spaces in filenames\n - contrib/buildsystems: fix misleading error message\n - contrib/buildsystems: ignore irrelevant files in Generators/\n - contrib/buildsystems: ignore invalidcontinue.obj\n - Vcproj.pm: urlencode '<' and '>' when generating VC projects\n - Vcproj.pm: do not configure VCWebServiceProxyGeneratorTool\n - Vcproj.pm: list git.exe first to be startup project\n - Vcproj.pm: auto-generate GUIDs\n\n Support building Git with Visual Studio\n\n The \".git/branches\" bit needs to be ejected and treated separately,\n but other than that, the topic looked reasonable.\n\n\n* bc/hash-independent-tests-part-4 (2019-07-01) 10 commits\n - t2203: avoid hard-coded object ID values\n - t1710: make hash independent\n - t1007: remove SHA1 prerequisites\n - t0090: make test pass with SHA-256\n - t0027: make hash size independent\n - t6030: make test work with SHA-256\n - t5000: make hash independent\n - t1450: make hash size independent\n - t1410: make hash size independent\n - t: add helper to convert object IDs to paths\n\n Update to the tests to help SHA-256 transition continues.\n\n Will merge to 'next'.\n\n\n* es/walken-tutorial (2019-07-02) 1 commit\n - documentation: add tutorial for revision walking\n\n Yet another revision walker tutorial.\n\n\n* ds/early-access (2019-07-01) 3 commits\n - repo-settings: pack.useSparse=true\n - repo-settings: use index.version=4 by default\n - repo-settings: create core.featureAdoptionRate setting\n\n A mechanism to enable newish configuration settings in bulk has\n been invented.\n\n Will replace with a redesigned variant which is being discussed\n when the dust settles.\n cf. (v2)\n\n\n* ab/no-kwset (2019-07-01) 10 commits\n (merged to 'next' on 2019-07-15 at ed0479ce3d)\n + grep: use PCRE v2 for optimized fixed-string search\n + grep: remove the kwset optimization\n + grep: drop support for \\0 in --fixed-strings \n + grep: make the behavior for NUL-byte in patterns sane\n + grep tests: move binary pattern tests into their own file\n + grep tests: move \"grep binary\" alongside the rest\n + grep: inline the return value of a function call used only once\n + t4210: skip more command-line encoding tests on MinGW\n + grep: don't use PCRE2?_UTF8 with \"log --encoding=\"\n + log tests: test regex backends in \"--encode=\" tests\n\n Retire use of kwset library, which is an optimization for looking\n for fixed strings, with use of pcre2 JIT.\n\n Needs to wait for a few pcre JIT related fixups, including the\n handling of non-UTF8 haystack.\n\n\n* md/list-objects-filter-combo (2019-06-28) 10 commits\n - list-objects-filter-options: make parser void\n - list-objects-filter-options: clean up use of ALLOC_GROW\n - list-objects-filter-options: allow mult. --filter\n - strbuf: give URL-encoding API a char predicate fn\n - list-objects-filter-options: make filter_spec a string_list\n - list-objects-filter-options: move error check up\n - list-objects-filter: implement composite filters\n - list-objects-filter-options: always supply *errbuf\n - list-objects-filter: put omits set in filter struct\n - list-objects-filter: encapsulate filter components\n\n The list-objects-filter API (used to create a sparse/lazy clone)\n learned to take a combined filter specification.\n\n Will merge to 'next'.\n\n\n* cc/multi-promisor (2019-06-25) 15 commits\n - Move core_partial_clone_filter_default to promisor-remote.c\n - Move repository_format_partial_clone to promisor-remote.c\n - Remove fetch-object.{c,h} in favor of promisor-remote.{c,h}\n - remote: add promisor and partial clone config to the doc\n - partial-clone: add multiple remotes in the doc\n - t0410: test fetching from many promisor remotes\n - builtin/fetch: remove unique promisor remote limitation\n - promisor-remote: parse remote.*.partialclonefilter\n - Use promisor_remote_get_direct() and has_promisor_remote()\n - promisor-remote: use repository_format_partial_clone\n - promisor-remote: add promisor_remote_reinit()\n - promisor-remote: implement promisor_remote_get_direct()\n - Add initial support for many promisor remotes\n - fetch-object: make functions return an error code\n - t0410: remove pipes after git commands\n\n Teach the lazy clone machinery that there can be more than one\n promisor remote and consult them in order when downloading missing\n objects on demand.\n\n Will merge to 'next'.\n\n\n* jc/format-patch-noclobber (2019-02-22) 1 commit\n - format-patch: --no-clobber refrains from overwriting output files\n\n \"git format-patch\" used to overwrite an existing patch/cover-letter\n file. A new \"--no-clobber\" option stops it.\n\n Will discard.\n\n\n* dl/rebase-i-keep-base (2019-04-25) 6 commits\n - rebase: teach rebase --keep-base\n - rebase: fast-forward --fork-point in more cases\n - rebase: fast-forward --onto in more cases\n - rebase: refactor can_fast_forward into goto tower\n - t3432: test rebase fast-forward behavior\n - t3431: add rebase --fork-point tests\n\n \"git rebase --keep-base \" tries to find the original base\n of the topic being rebased and rebase on top of that same base,\n which is useful when running the \"git rebase -i\" (and its limited\n variant \"git rebase -x\").\n\n The command also has learned to fast-forward in more cases where it\n can instead of replaying to recreate identical commits.\n\n On hold.\n cf. <20190508001252.15752-1-avarab@gmail.com>\n cf. <20190719210156.GA9688@archbookpro.localdomain>\n"},{"id":"379342","messageId":"nycvar.QRO.7.76.6.1907261624130.21907@tvgsbejvaqbjf.bet","threadId":"51527","inReplyTo":"xmqq36itprzo.fsf@gitster-ct.c.googlers.com","subject":"Re: What's cooking in git.git (Jul 2019, #06; Thu, 25)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2019-07-26T14:33:00Z","receivedAt":"2019-07-26T14:33:08Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Junio,\n\nOn Thu, 25 Jul 2019, Junio C Hamano wrote:\n\n> The seventh batch is in; I've merged fix-up topics that has been in\n> 'master' for some time (i.e. up to the third batch of this cycle)\n> down to 'maint'.\n\nWould you terribly mind also merging `js/gcc-8-and-9` into `maint`?\nOtherwise, the CI build is broken after my upgrade of the Git for\nWindows SDk to GCC v9.x.\n\nThanks,\nDscho\n"},{"id":"379392","messageId":"xmqqtvb8mto7.fsf@gitster-ct.c.googlers.com","threadId":"51527","inReplyTo":"nycvar.QRO.7.76.6.1907261624130.21907@tvgsbejvaqbjf.bet","subject":"Re: What's cooking in git.git (Jul 2019, #06; Thu, 25)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2019-07-26T20:23:36Z","receivedAt":"2019-07-26T20:23:45Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> Hi Junio,\n>\n> On Thu, 25 Jul 2019, Junio C Hamano wrote:\n>\n>> The seventh batch is in; I've merged fix-up topics that has been in\n>> 'master' for some time (i.e. up to the third batch of this cycle)\n>> down to 'maint'.\n>\n> Would you terribly mind also merging `js/gcc-8-and-9` into `maint`?\n> Otherwise, the CI build is broken after my upgrade of the Git for\n> Windows SDk to GCC v9.x.\n\nI do not mind. I am just taking things in smaller batches than just\nthe whole ball of wax.\n"},{"id":"379423","messageId":"20190727193814.7400-1-rohit.ashiwal265@gmail.com","threadId":"51527","inReplyTo":"xmqq36itprzo.fsf@gitster-ct.c.googlers.com","subject":"Re: What's cooking in git.git (Jul 2019, #06; Thu, 25)","fromName":"Rohit Ashiwal","fromEmail":"rohit.ashiwal265@gmail.com","sentAt":"2019-07-27T19:38:13Z","receivedAt":"2019-07-27T19:41:10Z","isPatch":false,"sender":{"key":"rohit.ashiwal265@gmail.com","avatar":"https://avatars.githubusercontent.com/u/31043830?v=4"},"body":"Hi Junio\n\nOn Thu, 25 Jul 2019 17:19:23 -0700 Junio C Hamano wrote:\n> \n> [...]\n> [New Topics]\n> \n> * bb/grep-pcre2-bug-message-fix (2019-07-23) 1 commit\n> (merged to 'next' on 2019-07-23 at 8bd5a68618)\n> + grep: print the pcre2_jit_on value\n> \n> BUG() message fix.\n> \n> The codepath may want to just simply be removed, though.\n> \n> \n> * ra/rebase-i-more-options (2019-07-23) 4 commits\n> - SQUASH???\n\nThere are only 3 commits in this \"series\".\n\n> - rebase -i: support --committer-date-is-author-date\n> - sequencer: add NULL checks under read_author_script\n> - rebase -i: add --ignore-whitespace flag\n\nThe correct order should be:\n - rebase -i: add --ignore-whitespace flag\n - sequencer: add NULL checks under read_author_script\n - rebase -i: support --committer-date-is-author-date\n\nI'll soon send another revision and while on it, let's merge\nthese topics into one. Should I also rebase them on the tip\nof git/git's master?\n\n> [...]\n\nBest\nRohit\n\n"},{"id":"379428","messageId":"CABPp-BEq+d=9G+U4im4fSEL2jGhggBwpoa+X7ZUjEGMPOPuFTw@mail.gmail.com","threadId":"51527","inReplyTo":"20190727193814.7400-1-rohit.ashiwal265@gmail.com","subject":"Re: What's cooking in git.git (Jul 2019, #06; Thu, 25)","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2019-07-27T20:40:13Z","receivedAt":"2019-07-27T20:40:38Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"Hi Rohit,\n\nLet me attempt to answer on Junio's behalf...\n\nOn Sat, Jul 27, 2019 at 12:48 PM Rohit Ashiwal\n wrote:\n>\n> Hi Junio\n>\n> On Thu, 25 Jul 2019 17:19:23 -0700 Junio C Hamano wrote:\n> >\n> > * ra/rebase-i-more-options (2019-07-23) 4 commits\n> > - SQUASH???\n>\n> There are only 3 commits in this \"series\".\n\nThere are four, including Junio's commit he had to add in order to\nmake the series merge with pu (a rename of your t3431 to the\nunoccupied t3433 slot). He labelled that commit \"SQUASH???\" and it's\nstill quoted above. However, in general, when you submit the next\nround of your series, you should certainly include his fixups from his\nsquash (or alternative fixes) inside your commits in order to get rid\nof the need for the squash commit.\n\n> > - rebase -i: support --committer-date-is-author-date\n> > - sequencer: add NULL checks under read_author_script\n> > - rebase -i: add --ignore-whitespace flag\n>\n> The correct order should be:\n> - rebase -i: add --ignore-whitespace flag\n> - sequencer: add NULL checks under read_author_script\n> - rebase -i: support --committer-date-is-author-date\n\nAre you thinking in order of application, or order that would be shown\nby `git log --oneline`? Junio includes the latter in his report.\n\n> I'll soon send another revision and while on it, let's merge\n> these topics into one. Should I also rebase them on the tip\n> of git/git's master?\n\nWhat do you mean by merge these topics into one? Do you mean merge\nall the commits into a single commit (which would be bad), or that\nyour two original topics should be one, much like Junio already did?\n\nIn general, once submitted, avoid rebasing unless needed to integrate\nwith someone else's work and clean up conflicts.\n\n\nHope that helps,\nElijah\n"},{"id":"379430","messageId":"20190727205732.16361-1-rohit.ashiwal265@gmail.com","threadId":"51527","inReplyTo":"CABPp-BEq+d=9G+U4im4fSEL2jGhggBwpoa+X7ZUjEGMPOPuFTw@mail.gmail.com","subject":"Re: What's cooking in git.git (Jul 2019, #06; Thu, 25)","fromName":"Rohit Ashiwal","fromEmail":"rohit.ashiwal265@gmail.com","sentAt":"2019-07-27T20:57:32Z","receivedAt":"2019-07-27T21:00:27Z","isPatch":false,"sender":{"key":"rohit.ashiwal265@gmail.com","avatar":"https://avatars.githubusercontent.com/u/31043830?v=4"},"body":"Hi Elijah\n\nOn Sat, 27 Jul 2019 13:40:13 -0700 Elijah Newren wrote:\n> \n> Let me attempt to answer on Junio's behalf...\n\n:)\n\n> [...]\n> There are four, including Junio's commit he had to add in order to\n> make the series merge with pu (a rename of your t3431 to the\n> unoccupied t3433 slot). He labelled that commit \"SQUASH???\" and it's\n> still quoted above. However, in general, when you submit the next\n> round of your series, you should certainly include his fixups from his\n> squash (or alternative fixes) inside your commits in order to get rid\n> of the need for the squash commit.\n\nUnderstood!\n\n> > > - rebase -i: support --committer-date-is-author-date\n> > > - sequencer: add NULL checks under read_author_script\n> > > - rebase -i: add --ignore-whitespace flag\n> >\n> > The correct order should be:\n> > - rebase -i: add --ignore-whitespace flag\n> > - sequencer: add NULL checks under read_author_script\n> > - rebase -i: support --committer-date-is-author-date\n> \n> Are you thinking in order of application, or order that would be shown\n> by `git log --oneline`? Junio includes the latter in his report.\n\nIf applied in this order, I think, there is no need of fixups.\nBut renaming t3431 to t3433 is still required.\n\n> > I'll soon send another revision and while on it, let's merge\n> > these topics into one. Should I also rebase them on the tip\n> > of git/git's master?\n> \n> What do you mean by merge these topics into one? Do you mean merge\n> all the commits into a single commit (which would be bad), or that\n> your two original topics should be one, much like Junio already did?\n\nI am thinking of mergin the original topics, yes, just like Junio did.\n\n> In general, once submitted, avoid rebasing unless needed to integrate\n> with someone else's work and clean up conflicts.\n\nI have not checked but git/git:master is like 569 commits ahead of\nr1walz/git:master, there _might_ be conflicts. Should I rebase if\nneed be?\n\nThanks\nRohit\n\n"},{"id":"379432","messageId":"CABPp-BHrfKsKu+=9+TEGmg8SZ6+nZdRNmSitxdwRucKGHvL9CQ@mail.gmail.com","threadId":"51527","inReplyTo":"20190727205732.16361-1-rohit.ashiwal265@gmail.com","subject":"Re: What's cooking in git.git (Jul 2019, #06; Thu, 25)","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2019-07-27T21:42:20Z","receivedAt":"2019-07-27T21:42:35Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Sat, Jul 27, 2019 at 2:00 PM Rohit Ashiwal\n wrote:\n> > In general, once submitted, avoid rebasing unless needed to integrate\n> > with someone else's work and clean up conflicts.\n>\n> I have not checked but git/git:master is like 569 commits ahead of\n> r1walz/git:master, there _might_ be conflicts. Should I rebase if\n> need be?\n\nFirst get your topic ready using the same base as you did for your\nearlier submission(s) of your series. Then when your changes are\nready:\n\n* Try to merge with origin/master. If there are no conflicts, undo the merge.\n* Try to merge with origin/next. If there are no conflicts, undo the merge.\n* Try to merge with origin/pu. If there are no conflicts, undo the merge.\n\nIf there are no conflicts in any of these steps, submit the next round\nof your series. If there are conflicts in any step, there's more work\nto do. If it conflicts with master, then yeah, just rebase on master.\nIf it conflicts with next or pu, there are a few different steps you\ncould take: (1) rebase on the topic that yours conflicts with\n(assuming it's just one), (2) rebase on next (if next conflicts,\nthough this means your topic can't advance until everything else in\nnext does first so is strongly discouraged), (3) if the conflicts are\nsmall/trivial you could just submit anyway and prominently call it out\nin your cover letter.\n\nIf there were any conflicts or you rebased at all, make sure to call\nit out in your cover letter, especially if your series depends on\nanything not in master. And if you did anything other than rebasing\non master, then expect a discussion to start around who should rebase\non whom and what order we want to apply topics in, and maybe other\nsteps to take.\n\nElijah\n"},{"id":"379448","messageId":"CAPUEspj0fNkRJLRhLkA1arOq58QpZZG_29=sAu1eNe9aHrAtfA@mail.gmail.com","threadId":"51527","inReplyTo":"xmqq36itprzo.fsf@gitster-ct.c.googlers.com","subject":"Re: What's cooking in git.git (Jul 2019, #06; Thu, 25)","fromName":"Carlo Arenas","fromEmail":"carenas@gmail.com","sentAt":"2019-07-28T20:34:32Z","receivedAt":"2019-07-28T20:34:46Z","isPatch":false,"sender":{"key":"carenas@gmail.com","avatar":"https://avatars.githubusercontent.com/u/76036?v=4"},"body":"On Thu, Jul 25, 2019 at 5:19 PM Junio C Hamano wrote:\n> [Stalled]\n>\n> * cb/xdiff-no-system-includes-in-dot-c (2019-06-19) 1 commit\n> - xdiff: avoid accidental redefinition of LFS feature in OpenIndiana\n>\n> Compilation fix.\n>\n> Will be rerolled together with patches from the\n> jk/no-system-includes-in-dot-c topic.\n>\n> * jk/no-system-includes-in-dot-c (2019-06-19) 2 commits\n> - wt-status.h: drop stdio.h include\n> - verify-tag: drop signal.h include\n>\n> Compilation fix.\n>\n> Will be rerolled with the above.\n\na merged reroll of both topics was published in:\nhttps://public-inbox.org/git/20190728200724.35630-1-carenas@gmail.com/\n\napologies for keeping Peff's patches hostage otherwise\n\nCarlo\n"},{"id":"380185","messageId":"20190809001315.GA87896@syl.lan","threadId":"51527","inReplyTo":"xmqq36itprzo.fsf@gitster-ct.c.googlers.com","subject":"Re: What's cooking in git.git (Jul 2019, #06; Thu, 25)","fromName":"Taylor Blau","fromEmail":"me@ttaylorr.com","sentAt":"2019-08-09T00:13:15Z","receivedAt":"2019-08-09T00:13:19Z","isPatch":false,"sender":{"key":"me@ttaylorr.com","avatar":"https://avatars.githubusercontent.com/u/301000140?v=4"},"body":"Hi Junio,\n\nOn Thu, Jul 25, 2019 at 05:19:23PM -0700, Junio C Hamano wrote:\n> Here are the topics that have been cooking. Commits prefixed with\n> '-' are only in 'pu' (proposed updates) while commits prefixed with\n> '+' are in 'next'. The ones marked with '.' do not appear in any of\n> the integration branches, but I am still holding onto them.\n>\n> The seventh batch is in; I've merged fix-up topics that has been in\n> 'master' for some time (i.e. up to the third batch of this cycle)\n> down to 'maint'.\n>\n> You can find the changes described here in the integration branches\n> of the repositories listed at\n>\n> http://git-blame.blogspot.com/p/git-public-repositories.html\n>\n> --------------------------------------------------\n> [Graduated to \"master\"]\n>\n> *snip*\n>\n> * ac/log-use-mailmap-by-default-transition (2019-07-15) 3 commits\n> (merged to 'next' on 2019-07-19 at e5669de950)\n> + tests: defang pager tests by explicitly disabling the log.mailmap warning\n> + documentation: mention --no-use-mailmap and log.mailmap false setting\n> + log: add warning for unspecified log.mailmap setting\n>\n> The \"git log\" command learns to issue a warning when log.mailmap\n> configuration is not set and --[no-]mailmap option is not used, to\n> prepare users for future versions of Git that uses the mailmap by\n> default.\n\nSorry for jumping into this discussion quite late. I was discussing this\nchange with a colleague of mine who pointed out an issue with the\neventual new defaults. I'd like to re-raise the issues they shared with\nme on the list for discussion, and if agreement is reached, I will send\na series that reverts these changes.\n\nIf a transgender person uses '.mailmap' to rewrite their deadname to\ntheir legal name (as was the original motivation in [1]), there are two\npotential issues:\n\n - The '.mailmap' provides a list of transgender individuals, along\n with their deadname, which can be used to harass them.\n\n - If they are not in control of the '.mailmap', and 'log.mailmap' is\n not specifiable (and instead defaults to 'true'), then a malicious\n maintainer or contributor can submit a change that rewrites their\n real name to their deadname, and harasses them further.\n\nThis issue was not raised in the original discussion, but it's clear\nthat this has the potential be used for bad, not good.\n\nGiven that the release is so close, I propose we revert this change\nbefore v2.23.0 is tagged. After that, we ought to discuss ways for folks\nto change how their name is displayed in porcelain commands, and\nthoroughly consider whether or not a new plan is exploitable.\n\nIf you think this is a good course of action, I will send a series to\nrevert the changes that were queued here.\n\nThanks,\nTaylor\n\n[1]: https://public-inbox.org/git/CABURp0poUjSBTTFUXP8dAmJ=37qvpe64=o+t_+mHOiK9Cv+=kg@mail.gmail.com/\n"},{"id":"380187","messageId":"3C7105E5-5DE1-42DC-A9A4-65C061FD6139@dereferenced.org","threadId":"51527","inReplyTo":"20190809001315.GA87896@syl.lan","subject":"Re: What's cooking in git.git (Jul 2019, #06; Thu, 25)","fromName":"Ariadne Conill","fromEmail":"ariadne@dereferenced.org","sentAt":"2019-08-09T01:34:15Z","receivedAt":"2019-08-09T01:34:21Z","isPatch":false,"sender":{"key":"ariadne@dereferenced.org","avatar":"https://avatars.githubusercontent.com/u/1522444?v=4"},"body":"Hello,\n\nOn August 8, 2019 8:13:15 PM EDT, Taylor Blau wrote:\n>Hi Junio,\n>\n>On Thu, Jul 25, 2019 at 05:19:23PM -0700, Junio C Hamano wrote:\n>> Here are the topics that have been cooking. Commits prefixed with\n>> '-' are only in 'pu' (proposed updates) while commits prefixed with\n>> '+' are in 'next'. The ones marked with '.' do not appear in any of\n>> the integration branches, but I am still holding onto them.\n>>\n>> The seventh batch is in; I've merged fix-up topics that has been in\n>> 'master' for some time (i.e. up to the third batch of this cycle)\n>> down to 'maint'.\n>>\n>> You can find the changes described here in the integration branches\n>> of the repositories listed at\n>>\n>> http://git-blame.blogspot.com/p/git-public-repositories.html\n>>\n>> --------------------------------------------------\n>> [Graduated to \"master\"]\n>>\n>> *snip*\n>>\n>> * ac/log-use-mailmap-by-default-transition (2019-07-15) 3 commits\n>> (merged to 'next' on 2019-07-19 at e5669de950)\n>> + tests: defang pager tests by explicitly disabling the log.mailmap\n>warning\n>> + documentation: mention --no-use-mailmap and log.mailmap false\n>setting\n>> + log: add warning for unspecified log.mailmap setting\n>>\n>> The \"git log\" command learns to issue a warning when log.mailmap\n>> configuration is not set and --[no-]mailmap option is not used, to\n>> prepare users for future versions of Git that uses the mailmap by\n>> default.\n>\n>Sorry for jumping into this discussion quite late. I was discussing\n>this\n>change with a colleague of mine who pointed out an issue with the\n>eventual new defaults. I'd like to re-raise the issues they shared with\n>me on the list for discussion, and if agreement is reached, I will send\n>a series that reverts these changes.\n>\n>If a transgender person uses '.mailmap' to rewrite their deadname to\n>their legal name (as was the original motivation in [1]), there are two\n>potential issues:\n\nWhat does myself being transgender have to do with anything? Please explain.\n\nMy motivation was to allow anyone to document their name change. People other than transgender individuals do change their names.\n\nPerhaps the fact that I am transgender means I am more attuned to the risks involved in using .mailmap in this way.\n\n> - The '.mailmap' provides a list of transgender individuals, along\n> with their deadname, which can be used to harass them.\n\nThis is potentially a problem but it's not as bad as you depict. A mailmap rule can match against e-mail only, which is precisely what I have done in my projects.\n\nAnd to be clear, anybody who is out there doxing transgender people are going to be using sources that are more reliable than a mailmap file.\n\n> - If they are not in control of the '.mailmap', and 'log.mailmap' is\n> not specifiable (and instead defaults to 'true'), then a malicious\n> maintainer or contributor can submit a change that rewrites their\n> real name to their deadname, and harasses them further.\n\nThe log.mailmap setting remains specifiable in these changes. Sure, a maintainer can abuse mailmap, but they could already do so. This commit changes absolutely nothing in that regard.\n\nThe commit does make `git shortlog` and `git log` consistent which is what most people expect.\n\n>This issue was not raised in the original discussion, but it's clear\n>that this has the potential be used for bad, not good.\n\nEvery tool has the potential to be abused. I would not have submitted this merge request if I thought that the benefits outweighed the trolling possibilities.\n\n>Given that the release is so close, I propose we revert this change\n>before v2.23.0 is tagged. After that, we ought to discuss ways for\n>folks\n>to change how their name is displayed in porcelain commands, and\n>thoroughly consider whether or not a new plan is exploitable.\n>\n>If you think this is a good course of action, I will send a series to\n>revert the changes that were queued here.\n\nI do not think this is a good course of action and I think your justification is extremely flimsy.\n\nWhile I would like to see the ability to commit a special commit that documents a name change, this does not change the fact that such commits will be mined in the same way.\n\nWhile I am glad that you are concerned about this from a trolling and harassment issue, I propose that you should allow individuals to make their own assessments on what they should do regarding documenting their changes using the mailmap file.\n\n>Thanks,\n>Taylor\n>\n>[1]:\n>https://public-inbox.org/git/CABURp0poUjSBTTFUXP8dAmJ=37qvpe64=o+t_+mHOiK9Cv+=kg@mail.gmail.com/\n\nAriadne\n"},{"id":"380188","messageId":"20190809020732.GA89008@syl.lan","threadId":"51527","inReplyTo":"3C7105E5-5DE1-42DC-A9A4-65C061FD6139@dereferenced.org","subject":"Re: What's cooking in git.git (Jul 2019, #06; Thu, 25)","fromName":"Taylor Blau","fromEmail":"me@ttaylorr.com","sentAt":"2019-08-09T02:07:32Z","receivedAt":"2019-08-09T02:07:37Z","isPatch":false,"sender":{"key":"me@ttaylorr.com","avatar":"https://avatars.githubusercontent.com/u/301000140?v=4"},"body":"Hi Ariadne,\n\nThank you for replying. I'm replying myself to the quoted hunks below,\nand I very much appreciate your input. I would like to note that I\nmyself did not come up with these concerns alone, they were merely\nsuggested to me by a coworker, and I found them concerning.\n\nI am not myself transgender, instead I am simply raising an issue that I\nfound myself concerning.\n\nOn Thu, Aug 08, 2019 at 09:34:15PM -0400, Ariadne Conill wrote:\n> Hello,\n>\n> On August 8, 2019 8:13:15 PM EDT, Taylor Blau wrote:\n> >Hi Junio,\n> >\n> >On Thu, Jul 25, 2019 at 05:19:23PM -0700, Junio C Hamano wrote:\n> >> Here are the topics that have been cooking. Commits prefixed with\n> >> '-' are only in 'pu' (proposed updates) while commits prefixed with\n> >> '+' are in 'next'. The ones marked with '.' do not appear in any of\n> >> the integration branches, but I am still holding onto them.\n> >>\n> >> The seventh batch is in; I've merged fix-up topics that has been in\n> >> 'master' for some time (i.e. up to the third batch of this cycle)\n> >> down to 'maint'.\n> >>\n> >> You can find the changes described here in the integration branches\n> >> of the repositories listed at\n> >>\n> >> http://git-blame.blogspot.com/p/git-public-repositories.html\n> >>\n> >> --------------------------------------------------\n> >> [Graduated to \"master\"]\n> >>\n> >> *snip*\n> >>\n> >> * ac/log-use-mailmap-by-default-transition (2019-07-15) 3 commits\n> >> (merged to 'next' on 2019-07-19 at e5669de950)\n> >> + tests: defang pager tests by explicitly disabling the log.mailmap\n> >warning\n> >> + documentation: mention --no-use-mailmap and log.mailmap false\n> >setting\n> >> + log: add warning for unspecified log.mailmap setting\n> >>\n> >> The \"git log\" command learns to issue a warning when log.mailmap\n> >> configuration is not set and --[no-]mailmap option is not used, to\n> >> prepare users for future versions of Git that uses the mailmap by\n> >> default.\n> >\n> >Sorry for jumping into this discussion quite late. I was discussing\n> >this\n> >change with a colleague of mine who pointed out an issue with the\n> >eventual new defaults. I'd like to re-raise the issues they shared with\n> >me on the list for discussion, and if agreement is reached, I will send\n> >a series that reverts these changes.\n> >\n> >If a transgender person uses '.mailmap' to rewrite their deadname to\n> >their legal name (as was the original motivation in [1]), there are two\n> >potential issues:\n>\n> What does myself being transgender have to do with anything? Please\n> explain.\n>\n> My motivation was to allow anyone to document their name change.\n> People other than transgender individuals do change their names.\n\nI think that the '.mailmap' is a good solution for other identity\nchanges, like when someone leaves a company, acquires an email address,\nand wishes to take their contributions with them.\n\nI don't think that being transgender changes one's usage of '.mailmap'.\nI do, however, share the concern with my coworker that these patches are\nbeing used to assist in deadname rewriting. It was my impression that\nthese patches are a response to the thread [1] that I linked in my last\nemail, and thus that eventually turning on '.mailmap'-rewriting by\ndefault was the solution given to Phil Hord.\n\n> Perhaps the fact that I am transgender means I am more attuned to the\n> risks involved in using .mailmap in this way.\n\nI'll certainly defer to your opinion on how this feature affects\ntransgender users over mine, and very much appreciate your perspective\nand insight.\n\n> > - The '.mailmap' provides a list of transgender individuals, along\n> > with their deadname, which can be used to harass them.\n>\n> This is potentially a problem but it's not as bad as you depict. A\n> mailmap rule can match against e-mail only, which is precisely what I\n> have done in my projects.\n\nAh, I may be severely mistaken -- my memory was that '.mailmap'\nrewriting could be used to rewrite both name and email, not merely\nemail. I thought that records could take:\n\n A U Thor -> B C Xyzz \n\ninstead of canonicalizing by email alone. If this is the case, then I\ncompletely agree and share the opinion that this is not as bad as I\noriginally depicted.\n\n> And to be clear, anybody who is out there doxing transgender people\n> are going to be using sources that are more reliable than a mailmap\n> file.\n\nIndeed. I think the '.mailmap' file doesn't contain much information if\nit doesn't remap author names, and certainly individuals can choose not\nto use it.\n\n> > - If they are not in control of the '.mailmap', and 'log.mailmap' is\n> > not specifiable (and instead defaults to 'true'), then a malicious\n> > maintainer or contributor can submit a change that rewrites their\n> > real name to their deadname, and harasses them further.\n>\n> The log.mailmap setting remains specifiable in these changes. Sure, a\n> maintainer can abuse mailmap, but they could already do so. This\n> commit changes absolutely nothing in that regard.\n\nI think that I might be mistaken about the intentions of your patch\nseries. Do you hope to eventually remove 'log.mailmap', instead having\nall clients automatically obey the '.mailmap'? If so, I think that this\ndoes change the behavior, at least down the road. If a maintainer wishes\nto abuse mailmap, today no one has to see it, because they have the\noption to turn off mailmap rewriting. If this setting doesn't exist, it\ngives more power to maintainers and contributors with write-level\naccess to force mailmap rewriting to take place.\n\n> The commit does make `git shortlog` and `git log` consistent which is what most people expect.\n>\n> >This issue was not raised in the original discussion, but it's clear\n> >that this has the potential be used for bad, not good.\n>\n> Every tool has the potential to be abused. I would not have submitted\n> this merge request if I thought that the benefits outweighed the\n> trolling possibilities.\n\nYes, I agree that tools can be abused, and I do not question your\njudgement in submitting this patch whatsoever. Again, I was merely\npointing out that there does seem to be a greater potential for this\ntool to be misused, but only if I am understanding it correctly.\n\n> >Given that the release is so close, I propose we revert this change\n> >before v2.23.0 is tagged. After that, we ought to discuss ways for\n> >folks\n> >to change how their name is displayed in porcelain commands, and\n> >thoroughly consider whether or not a new plan is exploitable.\n> >\n> >If you think this is a good course of action, I will send a series to\n> >revert the changes that were queued here.\n>\n> I do not think this is a good course of action and I think your\n> justification is extremely flimsy.\n>\n> While I would like to see the ability to commit a special commit that\n> documents a name change, this does not change the fact that such\n> commits will be mined in the same way.\n>\n> While I am glad that you are concerned about this from a trolling and\n> harassment issue, I propose that you should allow individuals to make\n> their own assessments on what they should do regarding documenting\n> their changes using the mailmap file.\n\nI'm happy to defer to the judgement of others, here; again I merely\nwanted to raise a concern and share a proposed course of action in\nresponse to it. If others do not buy into the justification, or if I\nhave misunderstood the feature, then we ought to let the release proceed\nas normal.\n\n> >Thanks,\n> >Taylor\n> >\n> >[1]:\n> >https://public-inbox.org/git/CABURp0poUjSBTTFUXP8dAmJ=37qvpe64=o+t_+mHOiK9Cv+=kg@mail.gmail.com/\n>\n> Ariadne\n\nThanks,\nTaylor\n"},{"id":"380193","messageId":"CAAOiGNyW9EpPgaMH1wEFG8gNNtypo2FaqOoOCe55i1TyT4L36A@mail.gmail.com","threadId":"51527","inReplyTo":"20190809020732.GA89008@syl.lan","subject":"Re: What's cooking in git.git (Jul 2019, #06; Thu, 25)","fromName":"Ariadne Conill","fromEmail":"ariadne@dereferenced.org","sentAt":"2019-08-09T03:04:18Z","receivedAt":"2019-08-09T03:04:32Z","isPatch":false,"sender":{"key":"ariadne@dereferenced.org","avatar":"https://avatars.githubusercontent.com/u/1522444?v=4"},"body":"Hello,\n\nOn Thu, Aug 8, 2019 at 9:07 PM Taylor Blau wrote:\n>\n> Hi Ariadne,\n>\n> Thank you for replying. I'm replying myself to the quoted hunks below,\n> and I very much appreciate your input. I would like to note that I\n> myself did not come up with these concerns alone, they were merely\n> suggested to me by a coworker, and I found them concerning.\n>\n> I am not myself transgender, instead I am simply raising an issue that I\n> found myself concerning.\n\nSure, there are concerns with the use of .mailmap being the primary\nsource of truth for identities in a git repository. However, this is\nthe present design. I'm not against improving the design, but see no\nreason to block changes that *improve quality of life* for people who\nare both transgender (or simply have changed their name for whatever\nreason) and those who collaborate with said people. I also believe\nthat this is an *intended* use of the design, since mailmap allows\nrewriting names. If it is not intended, then why does mailmap support\nrewriting names?\n\nThis isn't an either/or thing. This is more along the lines of --\nlets improve what we have now -- and deal with making a more robust\nmailmap replacement down the line, because that is going to require\nmore careful consideration.\n\n> On Thu, Aug 08, 2019 at 09:34:15PM -0400, Ariadne Conill wrote:\n> > Hello,\n> >\n> > On August 8, 2019 8:13:15 PM EDT, Taylor Blau wrote:\n> > >Hi Junio,\n> > >\n> > >On Thu, Jul 25, 2019 at 05:19:23PM -0700, Junio C Hamano wrote:\n> > >> Here are the topics that have been cooking. Commits prefixed with\n> > >> '-' are only in 'pu' (proposed updates) while commits prefixed with\n> > >> '+' are in 'next'. The ones marked with '.' do not appear in any of\n> > >> the integration branches, but I am still holding onto them.\n> > >>\n> > >> The seventh batch is in; I've merged fix-up topics that has been in\n> > >> 'master' for some time (i.e. up to the third batch of this cycle)\n> > >> down to 'maint'.\n> > >>\n> > >> You can find the changes described here in the integration branches\n> > >> of the repositories listed at\n> > >>\n> > >> http://git-blame.blogspot.com/p/git-public-repositories.html\n> > >>\n> > >> --------------------------------------------------\n> > >> [Graduated to \"master\"]\n> > >>\n> > >> *snip*\n> > >>\n> > >> * ac/log-use-mailmap-by-default-transition (2019-07-15) 3 commits\n> > >> (merged to 'next' on 2019-07-19 at e5669de950)\n> > >> + tests: defang pager tests by explicitly disabling the log.mailmap\n> > >warning\n> > >> + documentation: mention --no-use-mailmap and log.mailmap false\n> > >setting\n> > >> + log: add warning for unspecified log.mailmap setting\n> > >>\n> > >> The \"git log\" command learns to issue a warning when log.mailmap\n> > >> configuration is not set and --[no-]mailmap option is not used, to\n> > >> prepare users for future versions of Git that uses the mailmap by\n> > >> default.\n> > >\n> > >Sorry for jumping into this discussion quite late. I was discussing\n> > >this\n> > >change with a colleague of mine who pointed out an issue with the\n> > >eventual new defaults. I'd like to re-raise the issues they shared with\n> > >me on the list for discussion, and if agreement is reached, I will send\n> > >a series that reverts these changes.\n> > >\n> > >If a transgender person uses '.mailmap' to rewrite their deadname to\n> > >their legal name (as was the original motivation in [1]), there are two\n> > >potential issues:\n> >\n> > What does myself being transgender have to do with anything? Please\n> > explain.\n> >\n> > My motivation was to allow anyone to document their name change.\n> > People other than transgender individuals do change their names.\n>\n> I think that the '.mailmap' is a good solution for other identity\n> changes, like when someone leaves a company, acquires an email address,\n> and wishes to take their contributions with them.\n\nThen maybe .mailmap should be scoped to rewriting e-mail addresses only.\n\n> I don't think that being transgender changes one's usage of '.mailmap'.\n> I do, however, share the concern with my coworker that these patches are\n> being used to assist in deadname rewriting. It was my impression that\n> these patches are a response to the thread [1] that I linked in my last\n> email, and thus that eventually turning on '.mailmap'-rewriting by\n> default was the solution given to Phil Hord.\n\nYes, they *are* being used to assist in deadname rewriting, because\nthat is the mechanism that already exists in the code to facilitate\nit.\n\nIn what case would you *not* want to know the current name of the\nperson who authored a contribution? There are legal situations\ninvolving auditing the copyright status of contributions where\n*current* identity information for the author is desirable over what\nwas there historically, because you need to contact the author and\nfind out his or her wishes involving the code. Situations like\nrelicensing, for example.\n\n> > Perhaps the fact that I am transgender means I am more attuned to the\n> > risks involved in using .mailmap in this way.\n>\n> I'll certainly defer to your opinion on how this feature affects\n> transgender users over mine, and very much appreciate your perspective\n> and insight.\n>\n> > > - The '.mailmap' provides a list of transgender individuals, along\n> > > with their deadname, which can be used to harass them.\n> >\n> > This is potentially a problem but it's not as bad as you depict. A\n> > mailmap rule can match against e-mail only, which is precisely what I\n> > have done in my projects.\n>\n> Ah, I may be severely mistaken -- my memory was that '.mailmap'\n> rewriting could be used to rewrite both name and email, not merely\n> email. I thought that records could take:\n>\n> A U Thor -> B C Xyzz \n>\n> instead of canonicalizing by email alone. If this is the case, then I\n> completely agree and share the opinion that this is not as bad as I\n> originally depicted.\n\nYes, you can write mailmap entries with just the email like I have\ndone in pkgconf for example[1].\n\n> > And to be clear, anybody who is out there doxing transgender people\n> > are going to be using sources that are more reliable than a mailmap\n> > file.\n>\n> Indeed. I think the '.mailmap' file doesn't contain much information if\n> it doesn't remap author names, and certainly individuals can choose not\n> to use it.\n>\n> > > - If they are not in control of the '.mailmap', and 'log.mailmap' is\n> > > not specifiable (and instead defaults to 'true'), then a malicious\n> > > maintainer or contributor can submit a change that rewrites their\n> > > real name to their deadname, and harasses them further.\n> >\n> > The log.mailmap setting remains specifiable in these changes. Sure, a\n> > maintainer can abuse mailmap, but they could already do so. This\n> > commit changes absolutely nothing in that regard.\n>\n> I think that I might be mistaken about the intentions of your patch\n> series. Do you hope to eventually remove 'log.mailmap', instead having\n> all clients automatically obey the '.mailmap'? If so, I think that this\n> does change the behavior, at least down the road. If a maintainer wishes\n> to abuse mailmap, today no one has to see it, because they have the\n> option to turn off mailmap rewriting. If this setting doesn't exist, it\n> gives more power to maintainers and contributors with write-level\n> access to force mailmap rewriting to take place.\n\nI have no interest in removing the log.mailmap setting, but I would\nlike to see the setting behave consistently across all applets. In\nother words, \"git shortlog\", \"git log\" and \"git blame\" should have the\nsame behaviour given log.mailmap being set a certain way. They\npresently don't have consistent behaviour (shortlog and blame always\nuse mailmap), and I found that surprising. This allows people to look\nat the raw data if they have explicit interest in it, by setting\nlog.mailmap to false, and ensuring that people get reasonable\nbehaviour by default (log.mailmap is default to true).\n\nI also want to explicitly state that I believe wholeheartedly that\npeople will fork projects with a hostile maintainer who renames people\nin the mailmap file to derogatory names, so I think that is a\nnon-issue. Somebody who is trolling by using mailmap files to rewrite\ncontributor names is indicative that a project shouldn't be taken\nseriously.\n\n> > The commit does make `git shortlog` and `git log` consistent which is what most people expect.\n> >\n> > >This issue was not raised in the original discussion, but it's clear\n> > >that this has the potential be used for bad, not good.\n> >\n> > Every tool has the potential to be abused. I would not have submitted\n> > this merge request if I thought that the benefits outweighed the\n> > trolling possibilities.\n>\n> Yes, I agree that tools can be abused, and I do not question your\n> judgement in submitting this patch whatsoever. Again, I was merely\n> pointing out that there does seem to be a greater potential for this\n> tool to be misused, but only if I am understanding it correctly.\n\nBased on your misunderstanding of the mailmap feature, I believe\nyou're not understanding the patches correctly.\n\n> > >Given that the release is so close, I propose we revert this change\n> > >before v2.23.0 is tagged. After that, we ought to discuss ways for\n> > >folks\n> > >to change how their name is displayed in porcelain commands, and\n> > >thoroughly consider whether or not a new plan is exploitable.\n> > >\n> > >If you think this is a good course of action, I will send a series to\n> > >revert the changes that were queued here.\n> >\n> > I do not think this is a good course of action and I think your\n> > justification is extremely flimsy.\n> >\n> > While I would like to see the ability to commit a special commit that\n> > documents a name change, this does not change the fact that such\n> > commits will be mined in the same way.\n> >\n> > While I am glad that you are concerned about this from a trolling and\n> > harassment issue, I propose that you should allow individuals to make\n> > their own assessments on what they should do regarding documenting\n> > their changes using the mailmap file.\n>\n> I'm happy to defer to the judgement of others, here; again I merely\n> wanted to raise a concern and share a proposed course of action in\n> response to it. If others do not buy into the justification, or if I\n> have misunderstood the feature, then we ought to let the release proceed\n> as normal.\n\nAs previously stated, I think that your justification is flimsy, but I\nthink that's simply due to a misunderstanding of how mailmap works,\nand to what level of consistency mailmap is respected. Hopefully this\nexplanation is useful.\n\n[1]: https://git.sr.ht/~kaniini/pkgconf/tree/master/.mailmap\n\nAriadne\n"},{"id":"380195","messageId":"CABURp0oFNWfWEwnkjV1+Tag91HTRBCaJjyvc8CXtPGu78DhtSw@mail.gmail.com","threadId":"51527","inReplyTo":"20190809020732.GA89008@syl.lan","subject":"Re: What's cooking in git.git (Jul 2019, #06; Thu, 25)","fromName":"Phil Hord","fromEmail":"phil.hord@gmail.com","sentAt":"2019-08-09T03:07:36Z","receivedAt":"2019-08-09T03:07:53Z","isPatch":false,"sender":{"key":"phil.hord@gmail.com","avatar":"https://avatars.githubusercontent.com/u/123908?v=4"},"body":"The issue of deadnaming aside, turning on log.mailmap by default is\nthe sensible thing to do given that other Git features already honor\nit that way. Having it ignored-by-default (but only sometimes) just\nadds confusion when a mailmap is available.\n\n> > > - The '.mailmap' provides a list of transgender individuals, along\n> > > with their deadname, which can be used to harass them.\n> >\n> > This is potentially a problem but it's not as bad as you depict. A\n> > mailmap rule can match against e-mail only, which is precisely what I\n> > have done in my projects.\n>\n> Ah, I may be severely mistaken -- my memory was that '.mailmap'\n> rewriting could be used to rewrite both name and email, not merely\n> email. I thought that records could take:\n>\n> A U Thor -> B C Xyzz \n>\n> instead of canonicalizing by email alone. If this is the case, then I\n> completely agree and share the opinion that this is not as bad as I\n> originally depicted.\n\nThe long form you give there is to be used in case the old email\naddress is not a unique key. See 'git help shortlog'.\n\nThe problem we have at work is that one woman's old email address\nincludes her deadname, like . I will\nleave it up to her whether she chooses to be listed explicitly in the\nmailmap. I have wondered if we should permit hashed email addresses\nto be used for this specific case, but this also has its drawbacks.\n\nPhil\n"},{"id":"380196","messageId":"CAAOiGNzuLu26H56RvNCT=1iPQWOtGQJACO-pS8azerUio--=tw@mail.gmail.com","threadId":"51527","inReplyTo":"CABURp0oFNWfWEwnkjV1+Tag91HTRBCaJjyvc8CXtPGu78DhtSw@mail.gmail.com","subject":"Re: What's cooking in git.git (Jul 2019, #06; Thu, 25)","fromName":"Ariadne Conill","fromEmail":"ariadne@dereferenced.org","sentAt":"2019-08-09T03:21:02Z","receivedAt":"2019-08-09T03:21:16Z","isPatch":false,"sender":{"key":"ariadne@dereferenced.org","avatar":"https://avatars.githubusercontent.com/u/1522444?v=4"},"body":"Hello,\n\nOn Thu, Aug 8, 2019 at 10:07 PM Phil Hord wrote:\n>\n> The issue of deadnaming aside, turning on log.mailmap by default is\n> the sensible thing to do given that other Git features already honor\n> it that way. Having it ignored-by-default (but only sometimes) just\n> adds confusion when a mailmap is available.\n\nThis is my point exactly! My motive for improving this behaviour is\nentirely irrelevant, honestly. I regret ever bringing it up elsewhere\nin the discussions, as it's completely irrelevant.\n\n> > > > - The '.mailmap' provides a list of transgender individuals, along\n> > > > with their deadname, which can be used to harass them.\n> > >\n> > > This is potentially a problem but it's not as bad as you depict. A\n> > > mailmap rule can match against e-mail only, which is precisely what I\n> > > have done in my projects.\n> >\n> > Ah, I may be severely mistaken -- my memory was that '.mailmap'\n> > rewriting could be used to rewrite both name and email, not merely\n> > email. I thought that records could take:\n> >\n> > A U Thor -> B C Xyzz \n> >\n> > instead of canonicalizing by email alone. If this is the case, then I\n> > completely agree and share the opinion that this is not as bad as I\n> > originally depicted.\n>\n> The long form you give there is to be used in case the old email\n> address is not a unique key. See 'git help shortlog'.\n>\n> The problem we have at work is that one woman's old email address\n> includes her deadname, like . I will\n> leave it up to her whether she chooses to be listed explicitly in the\n> mailmap. I have wondered if we should permit hashed email addresses\n> to be used for this specific case, but this also has its drawbacks.\n\nI'd be open to looking into adding support for hashing the e-mail for\ncases like this if people are interested. The\nfirstname.lastname@company.com case is certainly a tough one to crack\notherwise, but I think that a solution that works for most cases still\nis useful. In the meantime, I think it makes sense to let people\ndecide whether they wish to use mailmap for this purpose, based on\ntheir own understanding of the risks involved.\n\nAriadne\n"},{"id":"380203","messageId":"20190809112128.GC93559@syl.local","threadId":"51527","inReplyTo":"CAAOiGNzuLu26H56RvNCT=1iPQWOtGQJACO-pS8azerUio--=tw@mail.gmail.com","subject":"Re: What's cooking in git.git (Jul 2019, #06; Thu, 25)","fromName":"Taylor Blau","fromEmail":"me@ttaylorr.com","sentAt":"2019-08-09T11:21:28Z","receivedAt":"2019-08-09T11:21:32Z","isPatch":false,"sender":{"key":"me@ttaylorr.com","avatar":"https://avatars.githubusercontent.com/u/301000140?v=4"},"body":"Hi Ariadne,\n\nOn Thu, Aug 08, 2019 at 10:21:02PM -0500, Ariadne Conill wrote:\n> Hello,\n>\n> On Thu, Aug 8, 2019 at 10:07 PM Phil Hord wrote:\n> >\n> > The issue of deadnaming aside, turning on log.mailmap by default is\n> > the sensible thing to do given that other Git features already honor\n> > it that way. Having it ignored-by-default (but only sometimes) just\n> > adds confusion when a mailmap is available.\n>\n> This is my point exactly! My motive for improving this behaviour is\n> entirely irrelevant, honestly. I regret ever bringing it up elsewhere\n> in the discussions, as it's completely irrelevant.\n\nYeah, I think that this makes much more sense (at least to me) as an\nissue separate from the deadname rewriting topic. If nothing else, this\nmakes 'git log' act like 'git shortlog', which only makes sense.\n\n> > > > > - The '.mailmap' provides a list of transgender individuals, along\n> > > > > with their deadname, which can be used to harass them.\n> > > >\n> > > > This is potentially a problem but it's not as bad as you depict. A\n> > > > mailmap rule can match against e-mail only, which is precisely what I\n> > > > have done in my projects.\n> > >\n> > > Ah, I may be severely mistaken -- my memory was that '.mailmap'\n> > > rewriting could be used to rewrite both name and email, not merely\n> > > email. I thought that records could take:\n> > >\n> > > A U Thor -> B C Xyzz \n> > >\n> > > instead of canonicalizing by email alone. If this is the case, then I\n> > > completely agree and share the opinion that this is not as bad as I\n> > > originally depicted.\n> >\n> > The long form you give there is to be used in case the old email\n> > address is not a unique key. See 'git help shortlog'.\n> >\n> > The problem we have at work is that one woman's old email address\n> > includes her deadname, like . I will\n> > leave it up to her whether she chooses to be listed explicitly in the\n> > mailmap. I have wondered if we should permit hashed email addresses\n> > to be used for this specific case, but this also has its drawbacks.\n>\n> I'd be open to looking into adding support for hashing the e-mail for\n> cases like this if people are interested. The\n> firstname.lastname@company.com case is certainly a tough one to crack\n> otherwise, but I think that a solution that works for most cases still\n> is useful. In the meantime, I think it makes sense to let people\n> decide whether they wish to use mailmap for this purpose, based on\n> their own understanding of the risks involved.\n\nYep. Totally agreed, and thank you for these patches.\n\n> Ariadne\n\nThanks,\nTaylor\n"},{"id":"380207","messageId":"20190809114148.GB3957@sigill.intra.peff.net","threadId":"51527","inReplyTo":"CABURp0oFNWfWEwnkjV1+Tag91HTRBCaJjyvc8CXtPGu78DhtSw@mail.gmail.com","subject":"Re: What's cooking in git.git (Jul 2019, #06; Thu, 25)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2019-08-09T11:41:48Z","receivedAt":"2019-08-09T11:41:51Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Aug 08, 2019 at 08:07:36PM -0700, Phil Hord wrote:\n\n> The long form you give there is to be used in case the old email\n> address is not a unique key. See 'git help shortlog'.\n> \n> The problem we have at work is that one woman's old email address\n> includes her deadname, like . I will\n> leave it up to her whether she chooses to be listed explicitly in the\n> mailmap. I have wondered if we should permit hashed email addresses\n> to be used for this specific case, but this also has its drawbacks.\n\nSince the set of hash inputs is finite and small (i.e., the set of all\nemails in the repository), it would be trivial to generate the plaintext\nmapping from even a cryptographically strong hashed mapping.\n\nWhich isn't to say it's _totally_ worthless, since that adds an extra\nstep, but it really is just obfuscating the data.\n\n-Peff\n"},{"id":"380211","messageId":"001e01d54ebb$9a1ab4b0$ce501e10$@nexbridge.com","threadId":"51527","inReplyTo":"3C7105E5-5DE1-42DC-A9A4-65C061FD6139@dereferenced.org","subject":"RE: What's cooking in git.git (Jul 2019, #06; Thu, 25)","fromName":"Randall S. Becker","fromEmail":"rsbecker@nexbridge.com","sentAt":"2019-08-09T14:06:06Z","receivedAt":"2019-08-09T14:06:23Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On 01 Aug 2019 13:05:12, Junio wrote:\n> >> *snip*\n\nI think this got missed in the shuffle, but I am getting questions about the topic from my own team that I cannot answer.\n\nI noticed that the switch and restore commands are now available in 2.23.0 but are not discussed in recent What's Cooking or Git Rev (or I blithely missed them). The question from my team is what are the plans for deprecating checkout. They have loads of scripts and want to plan for moving over.\n\nRegards and Thanks,\nRandall\n\n"},{"id":"380222","messageId":"20190809162900.GA9094@sigill.intra.peff.net","threadId":"51527","inReplyTo":"001e01d54ebb$9a1ab4b0$ce501e10$@nexbridge.com","subject":"Re: What's cooking in git.git (Jul 2019, #06; Thu, 25)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2019-08-09T16:29:01Z","receivedAt":"2019-08-09T16:29:03Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Aug 09, 2019 at 10:06:06AM -0400, Randall S. Becker wrote:\n\n> On 01 Aug 2019 13:05:12, Junio wrote:\n> > >> *snip*\n> \n> I think this got missed in the shuffle, but I am getting questions about the topic from my own team that I cannot answer.\n> \n> I noticed that the switch and restore commands are now available in\n> 2.23.0 but are not discussed in recent What's Cooking or Git Rev (or I\n> blithely missed them). The question from my team is what are the plans\n> for deprecating checkout. They have loads of scripts and want to plan\n> for moving over.\n\nI don't know of any plans for checkout in particular, but I think the\ndocs for restore/switch make it clear that it's way too early to start\nscripting around them:\n\n $ git grep EXPERIMENTAL Documentation/\n Documentation/git-restore.txt:THIS COMMAND IS EXPERIMENTAL. THE BEHAVIOR MAY CHANGE.\n Documentation/git-switch.txt:THIS COMMAND IS EXPERIMENTAL. THE BEHAVIOR MAY CHANGE.\n\n-Peff\n"},{"id":"380223","messageId":"002f01d54ed0$0e297620$2a7c6260$@nexbridge.com","threadId":"51527","inReplyTo":"20190809162900.GA9094@sigill.intra.peff.net","subject":"RE: What's cooking in git.git (Jul 2019, #06; Thu, 25)","fromName":"Randall S. Becker","fromEmail":"rsbecker@nexbridge.com","sentAt":"2019-08-09T16:32:31Z","receivedAt":"2019-08-09T16:32:47Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On August 9, 2019 12:29 PM, Jeff King wrote:\n> On Fri, Aug 09, 2019 at 10:06:06AM -0400, Randall S. Becker wrote:\n> \n> > On 01 Aug 2019 13:05:12, Junio wrote:\n> > > >> *snip*\n> >\n> > I think this got missed in the shuffle, but I am getting questions about the\n> topic from my own team that I cannot answer.\n> >\n> > I noticed that the switch and restore commands are now available in\n> > 2.23.0 but are not discussed in recent What's Cooking or Git Rev (or I\n> > blithely missed them). The question from my team is what are the plans\n> > for deprecating checkout. They have loads of scripts and want to plan\n> > for moving over.\n> \n> I don't know of any plans for checkout in particular, but I think the docs for\n> restore/switch make it clear that it's way too early to start scripting around\n> them:\n> \n> $ git grep EXPERIMENTAL Documentation/\n> Documentation/git-restore.txt:THIS COMMAND IS EXPERIMENTAL. THE\n> BEHAVIOR MAY CHANGE.\n> Documentation/git-switch.txt:THIS COMMAND IS EXPERIMENTAL. THE\n> BEHAVIOR MAY CHANGE.\n\nThanks Peff. Good guidance. I did not notice that part.\n\nAppreciations,\nRandall\n\n"},{"id":"380227","messageId":"CABURp0q-gfXWiembsHYZb9bxhKrd6=zJA2bfQek0JDxeEP1HGA@mail.gmail.com","threadId":"51527","inReplyTo":"20190809114148.GB3957@sigill.intra.peff.net","subject":"Re: What's cooking in git.git (Jul 2019, #06; Thu, 25)","fromName":"Phil Hord","fromEmail":"phil.hord@gmail.com","sentAt":"2019-08-09T17:39:10Z","receivedAt":"2019-08-09T17:39:35Z","isPatch":false,"sender":{"key":"phil.hord@gmail.com","avatar":"https://avatars.githubusercontent.com/u/123908?v=4"},"body":"On Fri, Aug 9, 2019 at 4:41 AM Jeff King wrote:\n>\n> On Thu, Aug 08, 2019 at 08:07:36PM -0700, Phil Hord wrote:\n>\n> > The long form you give there is to be used in case the old email\n> > address is not a unique key. See 'git help shortlog'.\n> >\n> > The problem we have at work is that one woman's old email address\n> > includes her deadname, like . I will\n> > leave it up to her whether she chooses to be listed explicitly in the\n> > mailmap. I have wondered if we should permit hashed email addresses\n> > to be used for this specific case, but this also has its drawbacks.\n>\n> Since the set of hash inputs is finite and small (i.e., the set of all\n> emails in the repository), it would be trivial to generate the plaintext\n> mapping from even a cryptographically strong hashed mapping.\n>\n> Which isn't to say it's _totally_ worthless, since that adds an extra\n> step, but it really is just obfuscating the data.\n\nYes, obfuscation is all I expect. Someone who needs deeper scrubbing\nwill need to rewrite their history instead.\n"},{"id":"380228","messageId":"xmqq7e7mdyig.fsf@gitster-ct.c.googlers.com","threadId":"51527","inReplyTo":"001e01d54ebb$9a1ab4b0$ce501e10$@nexbridge.com","subject":"Re: What's cooking in git.git (Jul 2019, #06; Thu, 25)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2019-08-09T17:44:39Z","receivedAt":"2019-08-09T17:44:44Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Randall S. Becker\" writes:\n\n> On 01 Aug 2019 13:05:12, Junio wrote:\n>> >> *snip*\n>\n> I think this got missed in the shuffle, but I am getting questions\n> about the topic from my own team that I cannot answer.\n>\n> I noticed that the switch and restore commands are now available\n> in 2.23.0 but are not discussed in recent What's Cooking or Git\n> Rev (or I blithely missed them). The question from my team is what\n> are the plans for deprecating checkout. They have loads of scripts\n> and want to plan for moving over.\n\nThe two new commands were done in response to a common \"checkout\ndoes two different things, either checkout a branch in order to\nstart working on it, or checkout paths into the current workspace to\nwork on them\" complaint. Those who are used to and are OK with the\n\"git\" command that changes behaviour based on the rest of args (i.e.\n\"checkout \" and \"checkout [] \" are\nthe ways to obtain these two behaviours) can safely keep using the\ncommand they are familiar with.\n\nI do not think there currently is any plan to deprecate checkout.\n"},{"id":"380229","messageId":"xmqq36iadygk.fsf@gitster-ct.c.googlers.com","threadId":"51527","inReplyTo":"20190809162900.GA9094@sigill.intra.peff.net","subject":"Re: What's cooking in git.git (Jul 2019, #06; Thu, 25)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2019-08-09T17:45:47Z","receivedAt":"2019-08-09T17:45:52Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> I don't know of any plans for checkout in particular, but I think the\n> docs for restore/switch make it clear that it's way too early to start\n> scripting around them:\n>\n> $ git grep EXPERIMENTAL Documentation/\n> Documentation/git-restore.txt:THIS COMMAND IS EXPERIMENTAL. THE BEHAVIOR MAY CHANGE.\n> Documentation/git-switch.txt:THIS COMMAND IS EXPERIMENTAL. THE BEHAVIOR MAY CHANGE.\n\nWould it ever be OK to script around checkout, restore and/or switch\nPorcelain commands?\n"},{"id":"380233","messageId":"CABURp0pb4QY+Qbvn6YAtQ=bevSQW+vQXFMChyd_phtUK4P5M7w@mail.gmail.com","threadId":"51527","inReplyTo":"xmqq36iadygk.fsf@gitster-ct.c.googlers.com","subject":"Re: What's cooking in git.git (Jul 2019, #06; Thu, 25)","fromName":"Phil Hord","fromEmail":"phil.hord@gmail.com","sentAt":"2019-08-09T18:05:34Z","receivedAt":"2019-08-09T18:05:49Z","isPatch":false,"sender":{"key":"phil.hord@gmail.com","avatar":"https://avatars.githubusercontent.com/u/123908?v=4"},"body":"On Fri, Aug 9, 2019 at 10:48 AM Junio C Hamano wrote:\n>\n> Jeff King writes:\n>\n> > I don't know of any plans for checkout in particular, but I think the\n> > docs for restore/switch make it clear that it's way too early to start\n> > scripting around them:\n> >\n> > $ git grep EXPERIMENTAL Documentation/\n> > Documentation/git-restore.txt:THIS COMMAND IS EXPERIMENTAL. THE BEHAVIOR MAY CHANGE.\n> > Documentation/git-switch.txt:THIS COMMAND IS EXPERIMENTAL. THE BEHAVIOR MAY CHANGE.\n>\n> Would it ever be OK to script around checkout, restore and/or switch\n> Porcelain commands?\n\nUsers who wish to get their job done will script around porcelain all\nthe time. I would be surprised if even 1% of build scripts use 'git\ncheckout-index' instead of 'git checkout'.\n\nNo, this doesn't make it OK. ;)\n"},{"id":"380237","messageId":"003a01d54ee5$902a3460$b07e9d20$@nexbridge.com","threadId":"51527","inReplyTo":"xmqq7e7mdyig.fsf@gitster-ct.c.googlers.com","subject":"RE: What's cooking in git.git (Jul 2019, #06; Thu, 25)","fromName":"Randall S. Becker","fromEmail":"rsbecker@nexbridge.com","sentAt":"2019-08-09T19:06:29Z","receivedAt":"2019-08-09T19:06:44Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On August 9, 2019 1:45 PM, Junio C Hamano wrote:\n> \"Randall S. Becker\" writes:\n> \n> > On 01 Aug 2019 13:05:12, Junio wrote:\n> >> >> *snip*\n> >\n> > I think this got missed in the shuffle, but I am getting questions\n> > about the topic from my own team that I cannot answer.\n> >\n> > I noticed that the switch and restore commands are now available in\n> > 2.23.0 but are not discussed in recent What's Cooking or Git Rev (or I\n> > blithely missed them). The question from my team is what are the plans\n> > for deprecating checkout. They have loads of scripts and want to plan\n> > for moving over.\n> \n> The two new commands were done in response to a common \"checkout\n> does two different things, either checkout a branch in order to start\nworking\n> on it, or checkout paths into the current workspace to work on them\"\n> complaint. Those who are used to and are OK with the \"git\" command that\n> changes behaviour based on the rest of args (i.e.\n> \"checkout \" and \"checkout [] \" are the\n> ways to obtain these two behaviours) can safely keep using the command\n> they are familiar with.\n> \n> I do not think there currently is any plan to deprecate checkout.\n\nThanks.\n\n"},{"id":"380258","messageId":"20190810061006.GB25876@sigill.intra.peff.net","threadId":"51527","inReplyTo":"CABURp0pb4QY+Qbvn6YAtQ=bevSQW+vQXFMChyd_phtUK4P5M7w@mail.gmail.com","subject":"Re: What's cooking in git.git (Jul 2019, #06; Thu, 25)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2019-08-10T06:10:07Z","receivedAt":"2019-08-10T06:10:09Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Aug 09, 2019 at 11:05:34AM -0700, Phil Hord wrote:\n\n> On Fri, Aug 9, 2019 at 10:48 AM Junio C Hamano wrote:\n> >\n> > Jeff King writes:\n> >\n> > > I don't know of any plans for checkout in particular, but I think the\n> > > docs for restore/switch make it clear that it's way too early to start\n> > > scripting around them:\n> > >\n> > > $ git grep EXPERIMENTAL Documentation/\n> > > Documentation/git-restore.txt:THIS COMMAND IS EXPERIMENTAL. THE BEHAVIOR MAY CHANGE.\n> > > Documentation/git-switch.txt:THIS COMMAND IS EXPERIMENTAL. THE BEHAVIOR MAY CHANGE.\n> >\n> > Would it ever be OK to script around checkout, restore and/or switch\n> > Porcelain commands?\n> \n> Users who wish to get their job done will script around porcelain all\n> the time. I would be surprised if even 1% of build scripts use 'git\n> checkout-index' instead of 'git checkout'.\n\nIt's even worse if you really want to switch branches, and not checkout\nfiles. You'd probably need to use symbolic-ref, read-tree, and\ncheckout-index.\n\nIMHO scripting around \"action\" commands like checkout is less bad than\naround \"output\" commands like log. The general action of \"switch to this\nbranch\" is unlikely to be changed much over the years (or via config),\nbut the output of log, etc, is.\n\nThere are no guarantees, of course, but I imagine that the tradeoff in\nsimplicity of using git-switch versus manually reimplementing it is\nprobably a good one for many scripts.\n\n-Peff\n"},{"id":"380294","messageId":"xmqqwofjb4k4.fsf@gitster-ct.c.googlers.com","threadId":"51527","inReplyTo":"20190810061006.GB25876@sigill.intra.peff.net","subject":"Re: What's cooking in git.git (Jul 2019, #06; Thu, 25)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2019-08-12T00:39:07Z","receivedAt":"2019-08-12T00:39:22Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> IMHO scripting around \"action\" commands like checkout is less bad than\n> around \"output\" commands like log. The general action of \"switch to this\n> branch\" is unlikely to be changed much over the years (or via config),\n> but the output of log, etc, is.\n>\n> There are no guarantees, of course, but I imagine that the tradeoff in\n> simplicity of using git-switch versus manually reimplementing it is\n> probably a good one for many scripts.\n\nAnother reason why scripting around \"action\" may be OK is that most\nof the time scriptors would want to (blindly) adopt improvements\nmade to the underly ing command anyway. If you scripted around \"git\ncheckout\" before we introduced multiple worktree feature where a\nbranch that is already active in another worktree is protected from\ngetting checked out elsewhere, your script will automatically get\nthat protection (and more importantly, the error message given as an\nexplanation to the end users) for free. Of course your script must\nbe prepared to react correctly to a failure from \"git checkout\", but\nthat goes without saying for any command you invoke in your script.\n\n"},{"id":"380303","messageId":"003201d55113$6d4c8ee0$47e5aca0$@nexbridge.com","threadId":"51527","inReplyTo":"xmqqwofjb4k4.fsf@gitster-ct.c.googlers.com","subject":"RE: What's cooking in git.git (Jul 2019, #06; Thu, 25)","fromName":"Randall S. Becker","fromEmail":"rsbecker@nexbridge.com","sentAt":"2019-08-12T13:39:50Z","receivedAt":"2019-08-12T13:40:04Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On August 11, 2019 8:39 PM, Junio C Hamano wrote:\n> Jeff King writes:\n> \n> > IMHO scripting around \"action\" commands like checkout is less bad than\n> > around \"output\" commands like log. The general action of \"switch to\n> > this branch\" is unlikely to be changed much over the years (or via\n> > config), but the output of log, etc, is.\n> >\n> > There are no guarantees, of course, but I imagine that the tradeoff in\n> > simplicity of using git-switch versus manually reimplementing it is\n> > probably a good one for many scripts.\n> \n> Another reason why scripting around \"action\" may be OK is that most of the\n> time scriptors would want to (blindly) adopt improvements made to the\n> underly ing command anyway. If you scripted around \"git checkout\" before\n> we introduced multiple worktree feature where a branch that is already\n> active in another worktree is protected from getting checked out elsewhere,\n> your script will automatically get that protection (and more importantly, the\n> error message given as an explanation to the end users) for free. Of course\n> your script must be prepared to react correctly to a failure from \"git\n> checkout\", but that goes without saying for any command you invoke in your\n> script.\n\nThat would describe my subcommunity pretty accurately 😉\n\nThanks,\nRandall\n\n"}]}