What's cooking in git.git (Jul 2019, #06; Thu, 25)

What's cooking in git.git (Jul 2019, #06; Thu, 25)

[Junio C Hamano]

Here are the topics that have been cooking.  Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.  The ones marked with '.' do not appear in any of
the integration branches, but I am still holding onto them.

The seventh batch is in; I've merged fix-up topics that has been in
'master' for some time (i.e. up to the third batch of this cycle)
down to 'maint'.

You can find the changes described here in the integration branches
of the repositories listed at

    http://git-blame.blogspot.com/p/git-public-repositories.html

--------------------------------------------------
[Graduated to "master"]

* ab/test-env (2019-07-11) 9 commits
  (merged to 'next' on 2019-07-15 at 42e86beb20)
 + env--helper: mark a file-local symbol as static
  (merged to 'next' on 2019-07-09 at 096658f382)
 + tests: make GIT_TEST_FAIL_PREREQS a boolean
 + tests: replace test_tristate with "git env--helper"
 + tests README: re-flow a previously changed paragraph
 + tests: make GIT_TEST_GETTEXT_POISON a boolean
 + t6040 test: stop using global "script" variable
 + config.c: refactor die_bad_number() to not call gettext() early
 + env--helper: new undocumented builtin wrapping git_env_*()
 + config tests: simplify include cycle test

 Many GIT_TEST_* environment variables control various aspects of
 how our tests are run, but a few followed "non-empty is true, empty
 or unset is false" while others followed the usual "there are a few
 ways to spell true, like yes, on, etc., and also ways to spell
 false, like no, off, etc." convention.


* ac/log-use-mailmap-by-default-transition (2019-07-15) 3 commits
  (merged to 'next' on 2019-07-19 at e5669de950)
 + tests: defang pager tests by explicitly disabling the log.mailmap warning
 + documentation: mention --no-use-mailmap and log.mailmap false setting
 + log: add warning for unspecified log.mailmap setting

 The "git log" command learns to issue a warning when log.mailmap
 configuration is not set and --[no-]mailmap option is not used, to
 prepare users for future versions of Git that uses the mailmap by
 default.


* di/readme-markup-fix (2019-07-18) 1 commit
  (merged to 'next' on 2019-07-19 at 339470d824)
 + README: fix rendering of text in angle brackets

 Docfix.


* es/local-atomic-push-failure-with-http (2019-07-16) 2 commits
  (merged to 'next' on 2019-07-19 at 8d5b776a96)
 + transport-helper: avoid var decl in for () loop control
  (merged to 'next' on 2019-07-15 at 960e92d24f)
 + transport-helper: enforce atomic in push_refs_with_push

 "git push --atomic" that goes over the transport-helper (namely,
 the smart http transport) failed to prevent refs to be pushed when
 it can locally tell that one of the ref update will fail without
 having to consult the other end, which has been corrected.


* jc/denoise-rm-to-resolve (2019-07-18) 1 commit
  (merged to 'next' on 2019-07-19 at 12f7e5d413)
 + rm: resolving by removal is not a warning-worthy event

 "git rm" to resolve a conflicted path leaked an internal message
 "needs merge" before actually removing the path, which was
 confusing.  This has been corrected.


* jc/post-c89-rules-doc (2019-07-18) 1 commit
  (merged to 'next' on 2019-07-19 at 8acd58e189)
 + CodingGuidelines: spell out post-C89 rules

 We have been trying out a few language features outside c89; the
 coding guidelines document did not talk about them and instead had
 a blanket ban against them.


* jk/test-commit-bulk (2019-07-23) 6 commits
  (merged to 'next' on 2019-07-23 at edc849c7dd)
 + t6200: use test_commit_bulk
 + t5703: use test_commit_bulk
 + t5702: use test_commit_bulk
 + t3311: use test_commit_bulk
 + t5310: increase the number of bitmapped commits
 + test-lib: introduce test_commit_bulk

 A test helper has been introduced to optimize preparation of test
 repositories with many simple commits, and a handful of test
 scripts have been updated to use it.


* js/clean-report-too-long-a-path (2019-07-19) 1 commit
  (merged to 'next' on 2019-07-19 at b7da0a821c)
 + clean: show an error message when the path is too long

 "git clean" silently skipped a path when it cannot lstat() it; now
 it gives a warning.


* js/mingw-spawn-with-spaces-in-path (2019-07-16) 1 commit
  (merged to 'next' on 2019-07-19 at 33dd6d0401)
 + mingw: support spawning programs containing spaces in their names

 Window 7 update ;-)


* js/unmap-before-ext-diff (2019-07-11) 1 commit
  (merged to 'next' on 2019-07-15 at 7aa292c66c)
 + diff: munmap() file contents before running external diff

 Windows update.


* mt/dir-iterator-updates (2019-07-11) 10 commits
  (merged to 'next' on 2019-07-19 at 2ebb586ce6)
 + clone: replace strcmp by fspathcmp
 + clone: use dir-iterator to avoid explicit dir traversal
 + clone: extract function from copy_or_link_directory
 + clone: copy hidden paths at local clone
 + dir-iterator: add flags parameter to dir_iterator_begin
 + dir-iterator: refactor state machine model
 + dir-iterator: use warning_errno when possible
 + dir-iterator: add tests for dir-iterator API
 + clone: better handle symlinked files at .git/objects/
 + clone: test for our behavior on odd objects/* content

 Adjust the dir-iterator API and apply it to the local clone
 optimization codepath.


* rm/gpg-program-doc-fix (2019-07-12) 1 commit
  (merged to 'next' on 2019-07-15 at ef358ec2e9)
 + gpg(docs): use correct --verify syntax

 Docfix.


* sr/gpg-interface-stop-at-the-end (2019-07-16) 1 commit
  (merged to 'next' on 2019-07-19 at 5d38aa1236)
 + gpg-interface: do not scan past the end of buffer

 A codepath that reads from GPG for signed object verification read
 past the end of allocated buffer, which has been fixed.


* tg/range-diff-output-update (2019-07-11) 14 commits
  (merged to 'next' on 2019-07-15 at b847d206ed)
 + range-diff: add headers to the outer hunk header
 + range-diff: add filename to inner diff
 + range-diff: add section header instead of diff header
 + range-diff: suppress line count in outer diff
 + range-diff: don't remove funcname from inner diff
 + range-diff: split lines manually
 + range-diff: fix function parameter indentation
 + apply: make parse_git_diff_header public
 + apply: only pass required data to gitdiff_* functions
 + apply: only pass required data to find_name_*
 + apply: only pass required data to check_header_line
 + apply: only pass required data to git_header_name
 + apply: only pass required data to skip_tree_prefix
 + apply: replace marc.info link with public-inbox

 "git range-diff" output has been tweaked for easier identification
 of which part of what file the patch shown is about.


* tg/stash-keep-index-with-removed-paths (2019-07-16) 1 commit
  (merged to 'next' on 2019-07-19 at d4ae24a939)
 + stash: fix handling removed files with --keep-index

 "git stash --keep-index" did not work correctly on paths that have
 been removed, which has been fixed.


* vn/xmmap-gently (2019-07-14) 1 commit
  (merged to 'next' on 2019-07-19 at d95c1d2be3)
 + read-cache.c: do not die if mmap fails

 Clean-up an error codepath.

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

* bb/grep-pcre2-bug-message-fix (2019-07-23) 1 commit
  (merged to 'next' on 2019-07-23 at 8bd5a68618)
 + grep: print the pcre2_jit_on value

 BUG() message fix.

 The codepath may want to just simply be removed, though.


* ra/rebase-i-more-options (2019-07-23) 4 commits
 - SQUASH???
 - rebase -i: support --committer-date-is-author-date
 - sequencer: add NULL checks under read_author_script
 - rebase -i: add --ignore-whitespace flag

 "git rebase -i" learned a few options that are known by "git
 rebase" proper.

 Needs a bit of fixups, at least.


* sg/travis-gcc-4.8 (2019-07-19) 1 commit
  (merged to 'next' on 2019-07-25 at e3d546eb15)
 + travis-ci: build with GCC 4.8 as well

 Add a job to build with a tad older GCC to make sure we are still
 buildable.

 Will merge to 'master'.


* ab/pcre-jit-fixes (2019-07-24) 3 commits
 - grep: stop using a custom JIT stack with PCRE v1
 - grep: stop "using" a custom JIT stack with PCRE v2
 - grep: remove overly paranoid BUG(...) code

 A few simplification and bugfixes to PCRE interface.

 Will merge to 'next'.


* jk/xdiff-clamp-funcname-context-index (2019-07-23) 1 commit
  (merged to 'next' on 2019-07-25 at b2944a0ba6)
 + xdiff: clamp function context indices in post-image

 The internal diff machinery can be made to read out of bounds while
 looking for --funcion-context line in a corner case, which has been
 corrected.

 Will merge to 'master'.


* js/rebase-cleanup (2019-07-25) 2 commits
  (merged to 'next' on 2019-07-25 at 3d9cedf470)
 + git: mark cmd_rebase as requiring a worktree
 + rebase: fix white-space

 A few leftover cleanup to "git rebase" in C.

 Will merge to 'master'.


* js/rebase-r-strategy (2019-07-25) 12 commits
 - rebase -r: do not (re-)generate root commits with `--root` *and* `--onto`
 - t3418: test `rebase -r` with merge strategies
 - t/lib-rebase: prepare for testing `git rebase --rebase-merges`
 - rebase -r: support merge strategies other than `recursive`
 - t3427: mark two test cases as requiring support for `git rebase -p`
 - t3427: fix another incorrect assumption
 - t3427: accommodate for the `rebase --merge` backend having been replaced
 - t3427: fix erroneous assumption
 - t3427: condense the unnecessarily repetitive test cases into three
 - t3427: move the `filter-branch` invocation into the `setup` case
 - t3427: simplify the `setup` test case significantly
 - t3427: add a clarifying comment

 "git rebase --rebase-merges" learned to drive different merge
 strategies and pass strategy specific options to them.


* js/trace2-json-schema (2019-07-25) 3 commits
 - ci: run trace2 schema validation in the CI suite
 - trace2: add a schema validator for trace2 events
 - trace2: add a JSON schema for trace2 events

 The JSON output produced by "trace2" subsystem now has JSON schema
 defined on it, to allow us validate the output and catch deviation.

 The CI integration may be a bit too heavy-handed.

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

* cb/xdiff-no-system-includes-in-dot-c (2019-06-19) 1 commit
 - xdiff: avoid accidental redefinition of LFS feature in OpenIndiana

 Compilation fix.

 Will be rerolled together with patches from the
 jk/no-system-includes-in-dot-c topic.


* jk/no-system-includes-in-dot-c (2019-06-19) 2 commits
 - wt-status.h: drop stdio.h include
 - verify-tag: drop signal.h include

 Compilation fix.

 Will be rerolled with the above.


* nd/index-dump-in-json (2019-06-26) 11 commits
 - SQUASH???
 - t3008: use the new SINGLE_CPU prereq
 - read-cache.c: dump "IEOT" extension as json
 - read-cache.c: dump "EOIE" extension as json
 - resolve-undo.c: dump "REUC" extension as json
 - fsmonitor.c: dump "FSMN" extension as json
 - split-index.c: dump "link" extension as json
 - dir.c: dump "UNTR" extension as json
 - cache-tree.c: dump "TREE" extension as json
 - read-cache.c: dump common extension info in json
 - ls-files: add --json to dump the index

 "ls-files" learned "--debug-json" option to dump the contents and
 the extensions of the index file.

 At least the fixup at the tip needs to be squashed into the right
 commit.  Also the new test seems flaky.


* jn/unknown-index-extensions (2018-11-21) 2 commits
 - index: offer advice for unknown index extensions
 - index: do not warn about unrecognized extensions

 A bit too alarming warning given when unknown index extensions
 exist is getting revamped.

 Expecting a reroll.


* jc/format-patch-delay-message-id (2019-04-05) 1 commit
 - format-patch: move message-id and related headers to the end

 The location "git format-patch --thread" adds the Message-Id:
 header in the series of header fields has been moved down, which
 may help working around a suspected bug in GMail MSA, reported at
 <CAHk-=whP1stFZNAaJiMi5eZ9rj0MRt20Y_yHVczZPH+O01d+sA@mail.gmail.com>

 Waiting for feedback to see if it truly helps.
 Needs tests.


* jt/fetch-cdn-offload (2019-03-12) 9 commits
 - SQUASH???
 - upload-pack: send part of packfile response as uri
 - fetch-pack: support more than one pack lockfile
 - upload-pack: refactor reading of pack-objects out
 - Documentation: add Packfile URIs design doc
 - Documentation: order protocol v2 sections
 - http-fetch: support fetching packfiles by URL
 - http: improve documentation of http_pack_request
 - http: use --stdin when getting dumb HTTP pack

 WIP for allowing a response to "git fetch" to instruct the bulk of
 the pack contents to be instead taken from elsewhere (aka CDN).


* js/protocol-advertise-multi (2018-12-28) 1 commit
 - protocol: advertise multiple supported versions

 The transport layer has been updated so that the protocol version
 used can be negotiated between the parties, by the initiator
 listing the protocol versions it is willing to talk, and the other
 side choosing from one of them.

 Expecting a reroll.
 cf. <CANq=j3u-zdb_FvNJGPCmygNMScseav63GhVvBX3NcVS4f7TejA@mail.gmail.com>


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

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


* dl/remote-save-to-push (2018-12-11) 1 commit
 - remote: add --save-to-push option to git remote set-url

 "git remote set-url" learned a new option that moves existing value
 of the URL field to pushURL field of the remote before replacing
 the URL field with a new value.

 Anybody who wants to champion this topic?
 I am personally not yet quite convinced if this is worth pursuing.

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

* js/builtin-add-i (2019-07-18) 11 commits
 - built-in add -i: implement the `help` command
 - built-in add -i: use color in the main loop
 - built-in add -i: support `?` (prompt help)
 - built-in add -i: show unique prefixes of the commands
 - Add a function to determine unique prefixes for a list of strings
 - built-in add -i: implement the main loop
 - built-in add -i: color the header in the `status` command
 - built-in add -i: refresh the index before running `status`
 - built-in add -i: implement the `status` command
 - diff: export diffstat interface
 - Start to implement a built-in version of `git add --interactive`

 The beginning of rewriting "git add -i" in C.


* js/visual-studio (2019-07-18) 24 commits
 - git: avoid calling aliased builtins via their dashed form
 - t5505,t5516: create .git/branches/ when needed
 - bin-wrappers: append `.exe` to target paths if necessary
 - .gitignore: ignore Visual Studio's temporary/generated files
 - .gitignore: touch up the entries regarding Visual Studio
 - vcxproj: also link-or-copy builtins
 - msvc: add a Makefile target to pre-generate the Visual Studio solution
 - contrib/buildsystems: add a backend for modern Visual Studio versions
 - contrib/buildsystems: handle options starting with a slash
 - contrib/buildsystems: also handle -lexpat
 - contrib/buildsystems: handle libiconv, too
 - contrib/buildsystems: handle the curl library option
 - contrib/buildsystems: error out on unknown option
 - contrib/buildsystems: optionally capture the dry-run in a file
 - contrib/buildsystems: redirect errors of the dry run into a log file
 - contrib/buildsystems: ignore gettext stuff
 - contrib/buildsystems: handle quoted spaces in filenames
 - contrib/buildsystems: fix misleading error message
 - contrib/buildsystems: ignore irrelevant files in Generators/
 - contrib/buildsystems: ignore invalidcontinue.obj
 - Vcproj.pm: urlencode '<' and '>' when generating VC projects
 - Vcproj.pm: do not configure VCWebServiceProxyGeneratorTool
 - Vcproj.pm: list git.exe first to be startup project
 - Vcproj.pm: auto-generate GUIDs

 Support building Git with Visual Studio

 The ".git/branches" bit needs to be ejected and treated separately,
 but other than that, the topic looked reasonable.


* bc/hash-independent-tests-part-4 (2019-07-01) 10 commits
 - t2203: avoid hard-coded object ID values
 - t1710: make hash independent
 - t1007: remove SHA1 prerequisites
 - t0090: make test pass with SHA-256
 - t0027: make hash size independent
 - t6030: make test work with SHA-256
 - t5000: make hash independent
 - t1450: make hash size independent
 - t1410: make hash size independent
 - t: add helper to convert object IDs to paths

 Update to the tests to help SHA-256 transition continues.

 Will merge to 'next'.


* es/walken-tutorial (2019-07-02) 1 commit
 - documentation: add tutorial for revision walking

 Yet another revision walker tutorial.


* ds/early-access (2019-07-01) 3 commits
 - repo-settings: pack.useSparse=true
 - repo-settings: use index.version=4 by default
 - repo-settings: create core.featureAdoptionRate setting

 A mechanism to enable newish configuration settings in bulk has
 been invented.

 Will replace with a redesigned variant which is being discussed
 when the dust settles.
 cf. <pull.292.v2.git.gitgitgadget@gmail.com> (v2)


* ab/no-kwset (2019-07-01) 10 commits
  (merged to 'next' on 2019-07-15 at ed0479ce3d)
 + grep: use PCRE v2 for optimized fixed-string search
 + grep: remove the kwset optimization
 + grep: drop support for \0 in --fixed-strings <pattern>
 + grep: make the behavior for NUL-byte in patterns sane
 + grep tests: move binary pattern tests into their own file
 + grep tests: move "grep binary" alongside the rest
 + grep: inline the return value of a function call used only once
 + t4210: skip more command-line encoding tests on MinGW
 + grep: don't use PCRE2?_UTF8 with "log --encoding=<non-utf8>"
 + log tests: test regex backends in "--encode=<enc>" tests

 Retire use of kwset library, which is an optimization for looking
 for fixed strings, with use of pcre2 JIT.

 Needs to wait for a few pcre JIT related fixups, including the
 handling of non-UTF8 haystack.


* md/list-objects-filter-combo (2019-06-28) 10 commits
 - list-objects-filter-options: make parser void
 - list-objects-filter-options: clean up use of ALLOC_GROW
 - list-objects-filter-options: allow mult. --filter
 - strbuf: give URL-encoding API a char predicate fn
 - list-objects-filter-options: make filter_spec a string_list
 - list-objects-filter-options: move error check up
 - list-objects-filter: implement composite filters
 - list-objects-filter-options: always supply *errbuf
 - list-objects-filter: put omits set in filter struct
 - list-objects-filter: encapsulate filter components

 The list-objects-filter API (used to create a sparse/lazy clone)
 learned to take a combined filter specification.

 Will merge to 'next'.


* cc/multi-promisor (2019-06-25) 15 commits
 - Move core_partial_clone_filter_default to promisor-remote.c
 - Move repository_format_partial_clone to promisor-remote.c
 - Remove fetch-object.{c,h} in favor of promisor-remote.{c,h}
 - remote: add promisor and partial clone config to the doc
 - partial-clone: add multiple remotes in the doc
 - t0410: test fetching from many promisor remotes
 - builtin/fetch: remove unique promisor remote limitation
 - promisor-remote: parse remote.*.partialclonefilter
 - Use promisor_remote_get_direct() and has_promisor_remote()
 - promisor-remote: use repository_format_partial_clone
 - promisor-remote: add promisor_remote_reinit()
 - promisor-remote: implement promisor_remote_get_direct()
 - Add initial support for many promisor remotes
 - fetch-object: make functions return an error code
 - t0410: remove pipes after git commands

 Teach the lazy clone machinery that there can be more than one
 promisor remote and consult them in order when downloading missing
 objects on demand.

 Will merge to 'next'.


* jc/format-patch-noclobber (2019-02-22) 1 commit
 - format-patch: --no-clobber refrains from overwriting output files

 "git format-patch" used to overwrite an existing patch/cover-letter
 file.  A new "--no-clobber" option stops it.

 Will discard.


* dl/rebase-i-keep-base (2019-04-25) 6 commits
 - rebase: teach rebase --keep-base
 - rebase: fast-forward --fork-point in more cases
 - rebase: fast-forward --onto in more cases
 - rebase: refactor can_fast_forward into goto tower
 - t3432: test rebase fast-forward behavior
 - t3431: add rebase --fork-point tests

 "git rebase --keep-base <upstream>" tries to find the original base
 of the topic being rebased and rebase on top of that same base,
 which is useful when running the "git rebase -i" (and its limited
 variant "git rebase -x").

 The command also has learned to fast-forward in more cases where it
 can instead of replaying to recreate identical commits.

 On hold.
 cf. <20190508001252.15752-1-avarab@gmail.com>
 cf. <20190719210156.GA9688@archbookpro.localdomain>

Re: What's cooking in git.git (Jul 2019, #06; Thu, 25)

[Johannes Schindelin]

Hi Junio,

On Thu, 25 Jul 2019, Junio C Hamano wrote:

> The seventh batch is in; I've merged fix-up topics that has been in
> 'master' for some time (i.e. up to the third batch of this cycle)
> down to 'maint'.

Would you terribly mind also merging `js/gcc-8-and-9` into `maint`?
Otherwise, the CI build is broken after my upgrade of the Git for
Windows SDk to GCC v9.x.

Thanks,
Dscho

Re: What's cooking in git.git (Jul 2019, #06; Thu, 25)

[Junio C Hamano]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> Hi Junio,
>
> On Thu, 25 Jul 2019, Junio C Hamano wrote:
>
>> The seventh batch is in; I've merged fix-up topics that has been in
>> 'master' for some time (i.e. up to the third batch of this cycle)
>> down to 'maint'.
>
> Would you terribly mind also merging `js/gcc-8-and-9` into `maint`?
> Otherwise, the CI build is broken after my upgrade of the Git for
> Windows SDk to GCC v9.x.

I do not mind.  I am just taking things in smaller batches than just
the whole ball of wax.

Re: What's cooking in git.git (Jul 2019, #06; Thu, 25)

[Rohit Ashiwal]

Hi Junio

On Thu, 25 Jul 2019 17:19:23 -0700 Junio C Hamano <gitster@pobox.com> wrote:
> 
> [...]
> [New Topics]
> 
> * bb/grep-pcre2-bug-message-fix (2019-07-23) 1 commit
>   (merged to 'next' on 2019-07-23 at 8bd5a68618)
>  + grep: print the pcre2_jit_on value
> 
>  BUG() message fix.
> 
>  The codepath may want to just simply be removed, though.
> 
> 
> * ra/rebase-i-more-options (2019-07-23) 4 commits
>  - SQUASH???

There are only 3 commits in this "series".

>  - rebase -i: support --committer-date-is-author-date
>  - sequencer: add NULL checks under read_author_script
>  - rebase -i: add --ignore-whitespace flag

The correct order should be:
   - rebase -i: add --ignore-whitespace flag
   - sequencer: add NULL checks under read_author_script
   - rebase -i: support --committer-date-is-author-date

I'll soon send another revision and while on it, let's merge
these topics into one. Should I also rebase them on the tip
of git/git's master?

> [...]

Best
Rohit

Re: What's cooking in git.git (Jul 2019, #06; Thu, 25)

[Elijah Newren]

Hi Rohit,

Let me attempt to answer on Junio's behalf...

On Sat, Jul 27, 2019 at 12:48 PM Rohit Ashiwal
<rohit.ashiwal265@gmail.com> wrote:
>
> Hi Junio
>
> On Thu, 25 Jul 2019 17:19:23 -0700 Junio C Hamano <gitster@pobox.com> wrote:
> >
> > * ra/rebase-i-more-options (2019-07-23) 4 commits
> >  - SQUASH???
>
> There are only 3 commits in this "series".

There are four, including Junio's commit he had to add in order to
make the series merge with pu (a rename of your t3431 to the
unoccupied t3433 slot).  He labelled that commit "SQUASH???" and it's
still quoted above.  However, in general, when you submit the next
round of your series, you should certainly include his fixups from his
squash (or alternative fixes) inside your commits in order to get rid
of the need for the squash commit.

> >  - rebase -i: support --committer-date-is-author-date
> >  - sequencer: add NULL checks under read_author_script
> >  - rebase -i: add --ignore-whitespace flag
>
> The correct order should be:
>    - rebase -i: add --ignore-whitespace flag
>    - sequencer: add NULL checks under read_author_script
>    - rebase -i: support --committer-date-is-author-date

Are you thinking in order of application, or order that would be shown
by `git log --oneline`?  Junio includes the latter in his report.

> I'll soon send another revision and while on it, let's merge
> these topics into one. Should I also rebase them on the tip
> of git/git's master?

What do you mean by merge these topics into one?  Do you mean merge
all the commits into a single commit (which would be bad), or that
your two original topics should be one, much like Junio already did?

In general, once submitted, avoid rebasing unless needed to integrate
with someone else's work and clean up conflicts.


Hope that helps,
Elijah

Re: What's cooking in git.git (Jul 2019, #06; Thu, 25)

[Rohit Ashiwal]

Hi Elijah

On Sat, 27 Jul 2019 13:40:13 -0700 Elijah Newren <newren@gmail.com> wrote:
> 
> Let me attempt to answer on Junio's behalf...

:)

> [...]
> There are four, including Junio's commit he had to add in order to
> make the series merge with pu (a rename of your t3431 to the
> unoccupied t3433 slot).  He labelled that commit "SQUASH???" and it's
> still quoted above.  However, in general, when you submit the next
> round of your series, you should certainly include his fixups from his
> squash (or alternative fixes) inside your commits in order to get rid
> of the need for the squash commit.

Understood!

> > >  - rebase -i: support --committer-date-is-author-date
> > >  - sequencer: add NULL checks under read_author_script
> > >  - rebase -i: add --ignore-whitespace flag
> >
> > The correct order should be:
> >    - rebase -i: add --ignore-whitespace flag
> >    - sequencer: add NULL checks under read_author_script
> >    - rebase -i: support --committer-date-is-author-date
> 
> Are you thinking in order of application, or order that would be shown
> by `git log --oneline`?  Junio includes the latter in his report.

If applied in this order, I think, there is no need of fixups.
But renaming t3431 to t3433 is still required.

> > I'll soon send another revision and while on it, let's merge
> > these topics into one. Should I also rebase them on the tip
> > of git/git's master?
> 
> What do you mean by merge these topics into one?  Do you mean merge
> all the commits into a single commit (which would be bad), or that
> your two original topics should be one, much like Junio already did?

I am thinking of mergin the original topics, yes, just like Junio did.

> In general, once submitted, avoid rebasing unless needed to integrate
> with someone else's work and clean up conflicts.

I have not checked but git/git:master is like 569 commits ahead of
r1walz/git:master, there _might_ be conflicts. Should I rebase if
need be?

Thanks
Rohit

Re: What's cooking in git.git (Jul 2019, #06; Thu, 25)

[Elijah Newren]

On Sat, Jul 27, 2019 at 2:00 PM Rohit Ashiwal
<rohit.ashiwal265@gmail.com> wrote:
> > In general, once submitted, avoid rebasing unless needed to integrate
> > with someone else's work and clean up conflicts.
>
> I have not checked but git/git:master is like 569 commits ahead of
> r1walz/git:master, there _might_ be conflicts. Should I rebase if
> need be?

First get your topic ready using the same base as you did for your
earlier submission(s) of your series.  Then when your changes are
ready:

* Try to merge with origin/master.  If there are no conflicts, undo the merge.
* Try to merge with origin/next.  If there are no conflicts, undo the merge.
* Try to merge with origin/pu.  If there are no conflicts, undo the merge.

If there are no conflicts in any of these steps, submit the next round
of your series.  If there are conflicts in any step, there's more work
to do.  If it conflicts with master, then yeah, just rebase on master.
If it conflicts with next or pu, there are a few different steps you
could take: (1) rebase on the topic that yours conflicts with
(assuming it's just one), (2) rebase on next (if next conflicts,
though this means your topic can't advance until everything else in
next does first so is strongly discouraged), (3) if the conflicts are
small/trivial you could just submit anyway and prominently call it out
in your cover letter.

If there were any conflicts or you rebased at all, make sure to call
it out in your cover letter, especially if your series depends on
anything not in master.  And if you did anything other than rebasing
on master, then expect a discussion to start around who should rebase
on whom and what order we want to apply topics in, and maybe other
steps to take.

Elijah

Re: What's cooking in git.git (Jul 2019, #06; Thu, 25)

[Carlo Arenas]

On Thu, Jul 25, 2019 at 5:19 PM Junio C Hamano <gitster@pobox.com> wrote:
> [Stalled]
>
> * cb/xdiff-no-system-includes-in-dot-c (2019-06-19) 1 commit
>  - xdiff: avoid accidental redefinition of LFS feature in OpenIndiana
>
>  Compilation fix.
>
>  Will be rerolled together with patches from the
>  jk/no-system-includes-in-dot-c topic.
>
> * jk/no-system-includes-in-dot-c (2019-06-19) 2 commits
>  - wt-status.h: drop stdio.h include
>  - verify-tag: drop signal.h include
>
>  Compilation fix.
>
>  Will be rerolled with the above.

a merged reroll of both topics was published in:
https://public-inbox.org/git/20190728200724.35630-1-carenas@gmail.com/

apologies for keeping Peff's patches hostage otherwise

Carlo

Re: What's cooking in git.git (Jul 2019, #06; Thu, 25)

[Taylor Blau]

Hi Junio,

On Thu, Jul 25, 2019 at 05:19:23PM -0700, Junio C Hamano wrote:
> Here are the topics that have been cooking.  Commits prefixed with
> '-' are only in 'pu' (proposed updates) while commits prefixed with
> '+' are in 'next'.  The ones marked with '.' do not appear in any of
> the integration branches, but I am still holding onto them.
>
> The seventh batch is in; I've merged fix-up topics that has been in
> 'master' for some time (i.e. up to the third batch of this cycle)
> down to 'maint'.
>
> You can find the changes described here in the integration branches
> of the repositories listed at
>
>     http://git-blame.blogspot.com/p/git-public-repositories.html
>
> --------------------------------------------------
> [Graduated to "master"]
>
> *snip*
>
> * ac/log-use-mailmap-by-default-transition (2019-07-15) 3 commits
>   (merged to 'next' on 2019-07-19 at e5669de950)
>  + tests: defang pager tests by explicitly disabling the log.mailmap warning
>  + documentation: mention --no-use-mailmap and log.mailmap false setting
>  + log: add warning for unspecified log.mailmap setting
>
>  The "git log" command learns to issue a warning when log.mailmap
>  configuration is not set and --[no-]mailmap option is not used, to
>  prepare users for future versions of Git that uses the mailmap by
>  default.

Sorry for jumping into this discussion quite late. I was discussing this
change with a colleague of mine who pointed out an issue with the
eventual new defaults. I'd like to re-raise the issues they shared with
me on the list for discussion, and if agreement is reached, I will send
a series that reverts these changes.

If a transgender person uses '.mailmap' to rewrite their deadname to
their legal name (as was the original motivation in [1]), there are two
potential issues:

  - The '.mailmap' provides a list of transgender individuals, along
    with their deadname, which can be used to harass them.

  - If they are not in control of the '.mailmap', and 'log.mailmap' is
    not specifiable (and instead defaults to 'true'), then a malicious
    maintainer or contributor can submit a change that rewrites their
    real name to their deadname, and harasses them further.

This issue was not raised in the original discussion, but it's clear
that this has the potential be used for bad, not good.

Given that the release is so close, I propose we revert this change
before v2.23.0 is tagged. After that, we ought to discuss ways for folks
to change how their name is displayed in porcelain commands, and
thoroughly consider whether or not a new plan is exploitable.

If you think this is a good course of action, I will send a series to
revert the changes that were queued here.

Thanks,
Taylor

[1]: https://public-inbox.org/git/CABURp0poUjSBTTFUXP8dAmJ=37qvpe64=o+t_+mHOiK9Cv+=kg@mail.gmail.com/

Re: What's cooking in git.git (Jul 2019, #06; Thu, 25)

[Ariadne Conill]

Hello,

On August 8, 2019 8:13:15 PM EDT, Taylor Blau <me@ttaylorr.com> wrote:
>Hi Junio,
>
>On Thu, Jul 25, 2019 at 05:19:23PM -0700, Junio C Hamano wrote:
>> Here are the topics that have been cooking.  Commits prefixed with
>> '-' are only in 'pu' (proposed updates) while commits prefixed with
>> '+' are in 'next'.  The ones marked with '.' do not appear in any of
>> the integration branches, but I am still holding onto them.
>>
>> The seventh batch is in; I've merged fix-up topics that has been in
>> 'master' for some time (i.e. up to the third batch of this cycle)
>> down to 'maint'.
>>
>> You can find the changes described here in the integration branches
>> of the repositories listed at
>>
>>     http://git-blame.blogspot.com/p/git-public-repositories.html
>>
>> --------------------------------------------------
>> [Graduated to "master"]
>>
>> *snip*
>>
>> * ac/log-use-mailmap-by-default-transition (2019-07-15) 3 commits
>>   (merged to 'next' on 2019-07-19 at e5669de950)
>>  + tests: defang pager tests by explicitly disabling the log.mailmap
>warning
>>  + documentation: mention --no-use-mailmap and log.mailmap false
>setting
>>  + log: add warning for unspecified log.mailmap setting
>>
>>  The "git log" command learns to issue a warning when log.mailmap
>>  configuration is not set and --[no-]mailmap option is not used, to
>>  prepare users for future versions of Git that uses the mailmap by
>>  default.
>
>Sorry for jumping into this discussion quite late. I was discussing
>this
>change with a colleague of mine who pointed out an issue with the
>eventual new defaults. I'd like to re-raise the issues they shared with
>me on the list for discussion, and if agreement is reached, I will send
>a series that reverts these changes.
>
>If a transgender person uses '.mailmap' to rewrite their deadname to
>their legal name (as was the original motivation in [1]), there are two
>potential issues:

What does myself being transgender have to do with anything?  Please explain.

My motivation was to allow anyone to document their name change.  People other than transgender individuals do change their names.

Perhaps the fact that I am transgender means I am more attuned to the risks involved in using .mailmap in this way.

>  - The '.mailmap' provides a list of transgender individuals, along
>    with their deadname, which can be used to harass them.

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

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

>  - If they are not in control of the '.mailmap', and 'log.mailmap' is
>    not specifiable (and instead defaults to 'true'), then a malicious
>    maintainer or contributor can submit a change that rewrites their
>    real name to their deadname, and harasses them further.

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

The commit does make `git shortlog` and `git log` consistent which is what most people expect.

>This issue was not raised in the original discussion, but it's clear
>that this has the potential be used for bad, not good.

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

>Given that the release is so close, I propose we revert this change
>before v2.23.0 is tagged. After that, we ought to discuss ways for
>folks
>to change how their name is displayed in porcelain commands, and
>thoroughly consider whether or not a new plan is exploitable.
>
>If you think this is a good course of action, I will send a series to
>revert the changes that were queued here.

I do not think this is a good course of action and I think your justification is extremely flimsy.

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

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

>Thanks,
>Taylor
>
>[1]:
>https://public-inbox.org/git/CABURp0poUjSBTTFUXP8dAmJ=37qvpe64=o+t_+mHOiK9Cv+=kg@mail.gmail.com/

Ariadne

Re: What's cooking in git.git (Jul 2019, #06; Thu, 25)

[Taylor Blau]

Hi Ariadne,

Thank you for replying. I'm replying myself to the quoted hunks below,
and I very much appreciate your input. I would like to note that I
myself did not come up with these concerns alone, they were merely
suggested to me by a coworker, and I found them concerning.

I am not myself transgender, instead I am simply raising an issue that I
found myself concerning.

On Thu, Aug 08, 2019 at 09:34:15PM -0400, Ariadne Conill wrote:
> Hello,
>
> On August 8, 2019 8:13:15 PM EDT, Taylor Blau <me@ttaylorr.com> wrote:
> >Hi Junio,
> >
> >On Thu, Jul 25, 2019 at 05:19:23PM -0700, Junio C Hamano wrote:
> >> Here are the topics that have been cooking.  Commits prefixed with
> >> '-' are only in 'pu' (proposed updates) while commits prefixed with
> >> '+' are in 'next'.  The ones marked with '.' do not appear in any of
> >> the integration branches, but I am still holding onto them.
> >>
> >> The seventh batch is in; I've merged fix-up topics that has been in
> >> 'master' for some time (i.e. up to the third batch of this cycle)
> >> down to 'maint'.
> >>
> >> You can find the changes described here in the integration branches
> >> of the repositories listed at
> >>
> >>     http://git-blame.blogspot.com/p/git-public-repositories.html
> >>
> >> --------------------------------------------------
> >> [Graduated to "master"]
> >>
> >> *snip*
> >>
> >> * ac/log-use-mailmap-by-default-transition (2019-07-15) 3 commits
> >>   (merged to 'next' on 2019-07-19 at e5669de950)
> >>  + tests: defang pager tests by explicitly disabling the log.mailmap
> >warning
> >>  + documentation: mention --no-use-mailmap and log.mailmap false
> >setting
> >>  + log: add warning for unspecified log.mailmap setting
> >>
> >>  The "git log" command learns to issue a warning when log.mailmap
> >>  configuration is not set and --[no-]mailmap option is not used, to
> >>  prepare users for future versions of Git that uses the mailmap by
> >>  default.
> >
> >Sorry for jumping into this discussion quite late. I was discussing
> >this
> >change with a colleague of mine who pointed out an issue with the
> >eventual new defaults. I'd like to re-raise the issues they shared with
> >me on the list for discussion, and if agreement is reached, I will send
> >a series that reverts these changes.
> >
> >If a transgender person uses '.mailmap' to rewrite their deadname to
> >their legal name (as was the original motivation in [1]), there are two
> >potential issues:
>
> What does myself being transgender have to do with anything?  Please
> explain.
>
> My motivation was to allow anyone to document their name change.
> People other than transgender individuals do change their names.

I think that the '.mailmap' is a good solution for other identity
changes, like when someone leaves a company, acquires an email address,
and wishes to take their contributions with them.

I don't think that being transgender changes one's usage of '.mailmap'.
I do, however, share the concern with my coworker that these patches are
being used to assist in deadname rewriting. It was my impression that
these patches are a response to the thread [1] that I linked in my last
email, and thus that eventually turning on '.mailmap'-rewriting by
default was the solution given to Phil Hord.

> Perhaps the fact that I am transgender means I am more attuned to the
> risks involved in using .mailmap in this way.

I'll certainly defer to your opinion on how this feature affects
transgender users over mine, and very much appreciate your perspective
and insight.

> >  - The '.mailmap' provides a list of transgender individuals, along
> >    with their deadname, which can be used to harass them.
>
> This 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.

Ah, I may be severely mistaken -- my memory was that '.mailmap'
rewriting could be used to rewrite both name and email, not merely
email. I thought that records could take:

  A U Thor <author@xample.com> -> B C Xyzz <newname@example.com>

instead of canonicalizing by email alone. If this is the case, then I
completely agree and share the opinion that this is not as bad as I
originally depicted.

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

Indeed. I think the '.mailmap' file doesn't contain much information if
it doesn't remap author names, and certainly individuals can choose not
to use it.

> >  - If they are not in control of the '.mailmap', and 'log.mailmap' is
> >    not specifiable (and instead defaults to 'true'), then a malicious
> >    maintainer or contributor can submit a change that rewrites their
> >    real name to their deadname, and harasses them further.
>
> The 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.

I think that I might be mistaken about the intentions of your patch
series. Do you hope to eventually remove 'log.mailmap', instead having
all clients automatically obey the '.mailmap'? If so, I think that this
does change the behavior, at least down the road. If a maintainer wishes
to abuse mailmap, today no one has to see it, because they have the
option to turn off mailmap rewriting. If this setting doesn't exist, it
gives more power to maintainers and contributors with write-level
access to force mailmap rewriting to take place.

> The commit does make `git shortlog` and `git log` consistent which is what most people expect.
>
> >This issue was not raised in the original discussion, but it's clear
> >that this has the potential be used for bad, not good.
>
> Every 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.

Yes, I agree that tools can be abused, and I do not question your
judgement in submitting this patch whatsoever. Again, I was merely
pointing out that there does seem to be a greater potential for this
tool to be misused, but only if I am understanding it correctly.

> >Given that the release is so close, I propose we revert this change
> >before v2.23.0 is tagged. After that, we ought to discuss ways for
> >folks
> >to change how their name is displayed in porcelain commands, and
> >thoroughly consider whether or not a new plan is exploitable.
> >
> >If you think this is a good course of action, I will send a series to
> >revert the changes that were queued here.
>
> I do not think this is a good course of action and I think your
> justification is extremely flimsy.
>
> While 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.
>
> While 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.

I'm happy to defer to the judgement of others, here; again I merely
wanted to raise a concern and share a proposed course of action in
response to it. If others do not buy into the justification, or if I
have misunderstood the feature, then we ought to let the release proceed
as normal.

> >Thanks,
> >Taylor
> >
> >[1]:
> >https://public-inbox.org/git/CABURp0poUjSBTTFUXP8dAmJ=37qvpe64=o+t_+mHOiK9Cv+=kg@mail.gmail.com/
>
> Ariadne

Thanks,
Taylor

Re: What's cooking in git.git (Jul 2019, #06; Thu, 25)

[Ariadne Conill]

Hello,

On Thu, Aug 8, 2019 at 9:07 PM Taylor Blau <me@ttaylorr.com> wrote:
>
> Hi Ariadne,
>
> Thank you for replying. I'm replying myself to the quoted hunks below,
> and I very much appreciate your input. I would like to note that I
> myself did not come up with these concerns alone, they were merely
> suggested to me by a coworker, and I found them concerning.
>
> I am not myself transgender, instead I am simply raising an issue that I
> found myself concerning.

Sure, there are concerns with the use of .mailmap being the primary
source of truth for identities in a git repository.  However, this is
the present design.  I'm not against improving the design, but see no
reason to block changes that *improve quality of life* for people who
are both transgender (or simply have changed their name for whatever
reason) and those who collaborate with said people.  I also believe
that this is an *intended* use of the design, since mailmap allows
rewriting names.  If it is not intended, then why does mailmap support
rewriting names?

This isn't an either/or thing.  This is more along the lines of --
lets improve what we have now -- and deal with making a more robust
mailmap replacement down the line, because that is going to require
more careful consideration.

> On Thu, Aug 08, 2019 at 09:34:15PM -0400, Ariadne Conill wrote:
> > Hello,
> >
> > On August 8, 2019 8:13:15 PM EDT, Taylor Blau <me@ttaylorr.com> wrote:
> > >Hi Junio,
> > >
> > >On Thu, Jul 25, 2019 at 05:19:23PM -0700, Junio C Hamano wrote:
> > >> Here are the topics that have been cooking.  Commits prefixed with
> > >> '-' are only in 'pu' (proposed updates) while commits prefixed with
> > >> '+' are in 'next'.  The ones marked with '.' do not appear in any of
> > >> the integration branches, but I am still holding onto them.
> > >>
> > >> The seventh batch is in; I've merged fix-up topics that has been in
> > >> 'master' for some time (i.e. up to the third batch of this cycle)
> > >> down to 'maint'.
> > >>
> > >> You can find the changes described here in the integration branches
> > >> of the repositories listed at
> > >>
> > >>     http://git-blame.blogspot.com/p/git-public-repositories.html
> > >>
> > >> --------------------------------------------------
> > >> [Graduated to "master"]
> > >>
> > >> *snip*
> > >>
> > >> * ac/log-use-mailmap-by-default-transition (2019-07-15) 3 commits
> > >>   (merged to 'next' on 2019-07-19 at e5669de950)
> > >>  + tests: defang pager tests by explicitly disabling the log.mailmap
> > >warning
> > >>  + documentation: mention --no-use-mailmap and log.mailmap false
> > >setting
> > >>  + log: add warning for unspecified log.mailmap setting
> > >>
> > >>  The "git log" command learns to issue a warning when log.mailmap
> > >>  configuration is not set and --[no-]mailmap option is not used, to
> > >>  prepare users for future versions of Git that uses the mailmap by
> > >>  default.
> > >
> > >Sorry for jumping into this discussion quite late. I was discussing
> > >this
> > >change with a colleague of mine who pointed out an issue with the
> > >eventual new defaults. I'd like to re-raise the issues they shared with
> > >me on the list for discussion, and if agreement is reached, I will send
> > >a series that reverts these changes.
> > >
> > >If a transgender person uses '.mailmap' to rewrite their deadname to
> > >their legal name (as was the original motivation in [1]), there are two
> > >potential issues:
> >
> > What does myself being transgender have to do with anything?  Please
> > explain.
> >
> > My motivation was to allow anyone to document their name change.
> > People other than transgender individuals do change their names.
>
> I think that the '.mailmap' is a good solution for other identity
> changes, like when someone leaves a company, acquires an email address,
> and wishes to take their contributions with them.

Then maybe .mailmap should be scoped to rewriting e-mail addresses only.

> I don't think that being transgender changes one's usage of '.mailmap'.
> I do, however, share the concern with my coworker that these patches are
> being used to assist in deadname rewriting. It was my impression that
> these patches are a response to the thread [1] that I linked in my last
> email, and thus that eventually turning on '.mailmap'-rewriting by
> default was the solution given to Phil Hord.

Yes, they *are* being used to assist in deadname rewriting, because
that is the mechanism that already exists in the code to facilitate
it.

In what case would you *not* want to know the current name of the
person who authored a contribution?  There are legal situations
involving auditing the copyright status of contributions where
*current* identity information for the author is desirable over what
was there historically, because you need to contact the author and
find out his or her wishes involving the code.  Situations like
relicensing, for example.

> > Perhaps the fact that I am transgender means I am more attuned to the
> > risks involved in using .mailmap in this way.
>
> I'll certainly defer to your opinion on how this feature affects
> transgender users over mine, and very much appreciate your perspective
> and insight.
>
> > >  - The '.mailmap' provides a list of transgender individuals, along
> > >    with their deadname, which can be used to harass them.
> >
> > This 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.
>
> Ah, I may be severely mistaken -- my memory was that '.mailmap'
> rewriting could be used to rewrite both name and email, not merely
> email. I thought that records could take:
>
>   A U Thor <author@xample.com> -> B C Xyzz <newname@example.com>
>
> instead of canonicalizing by email alone. If this is the case, then I
> completely agree and share the opinion that this is not as bad as I
> originally depicted.

Yes, you can write mailmap entries with just the email like I have
done in pkgconf for example[1].

> > And 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.
>
> Indeed. I think the '.mailmap' file doesn't contain much information if
> it doesn't remap author names, and certainly individuals can choose not
> to use it.
>
> > >  - If they are not in control of the '.mailmap', and 'log.mailmap' is
> > >    not specifiable (and instead defaults to 'true'), then a malicious
> > >    maintainer or contributor can submit a change that rewrites their
> > >    real name to their deadname, and harasses them further.
> >
> > The 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.
>
> I think that I might be mistaken about the intentions of your patch
> series. Do you hope to eventually remove 'log.mailmap', instead having
> all clients automatically obey the '.mailmap'? If so, I think that this
> does change the behavior, at least down the road. If a maintainer wishes
> to abuse mailmap, today no one has to see it, because they have the
> option to turn off mailmap rewriting. If this setting doesn't exist, it
> gives more power to maintainers and contributors with write-level
> access to force mailmap rewriting to take place.

I have no interest in removing the log.mailmap setting, but I would
like to see the setting behave consistently across all applets.  In
other words, "git shortlog", "git log" and "git blame" should have the
same behaviour given log.mailmap being set a certain way.  They
presently don't have consistent behaviour (shortlog and blame always
use mailmap), and I found that surprising.  This allows people to look
at the raw data if they have explicit interest in it, by setting
log.mailmap to false, and ensuring that people get reasonable
behaviour by default (log.mailmap is default to true).

I also want to explicitly state that I believe wholeheartedly that
people will fork projects with a hostile maintainer who renames people
in the mailmap file to derogatory names, so I think that is a
non-issue.  Somebody who is trolling by using mailmap files to rewrite
contributor names is indicative that a project shouldn't be taken
seriously.

> > The commit does make `git shortlog` and `git log` consistent which is what most people expect.
> >
> > >This issue was not raised in the original discussion, but it's clear
> > >that this has the potential be used for bad, not good.
> >
> > Every 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.
>
> Yes, I agree that tools can be abused, and I do not question your
> judgement in submitting this patch whatsoever. Again, I was merely
> pointing out that there does seem to be a greater potential for this
> tool to be misused, but only if I am understanding it correctly.

Based on your misunderstanding of the mailmap feature, I believe
you're not understanding the patches correctly.

> > >Given that the release is so close, I propose we revert this change
> > >before v2.23.0 is tagged. After that, we ought to discuss ways for
> > >folks
> > >to change how their name is displayed in porcelain commands, and
> > >thoroughly consider whether or not a new plan is exploitable.
> > >
> > >If you think this is a good course of action, I will send a series to
> > >revert the changes that were queued here.
> >
> > I do not think this is a good course of action and I think your
> > justification is extremely flimsy.
> >
> > While 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.
> >
> > While 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.
>
> I'm happy to defer to the judgement of others, here; again I merely
> wanted to raise a concern and share a proposed course of action in
> response to it. If others do not buy into the justification, or if I
> have misunderstood the feature, then we ought to let the release proceed
> as normal.

As previously stated, I think that your justification is flimsy, but I
think that's simply due to a misunderstanding of how mailmap works,
and to what level of consistency mailmap is respected.  Hopefully this
explanation is useful.

[1]: https://git.sr.ht/~kaniini/pkgconf/tree/master/.mailmap

Ariadne

Re: What's cooking in git.git (Jul 2019, #06; Thu, 25)

[Phil Hord]

The issue of deadnaming aside, turning on log.mailmap by default is
the sensible thing to do given that other Git features already honor
it that way.  Having it ignored-by-default (but only sometimes) just
adds confusion when a mailmap is available.

> > >  - The '.mailmap' provides a list of transgender individuals, along
> > >    with their deadname, which can be used to harass them.
> >
> > This 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.
>
> Ah, I may be severely mistaken -- my memory was that '.mailmap'
> rewriting could be used to rewrite both name and email, not merely
> email. I thought that records could take:
>
>   A U Thor <author@xample.com> -> B C Xyzz <newname@example.com>
>
> instead of canonicalizing by email alone. If this is the case, then I
> completely agree and share the opinion that this is not as bad as I
> originally depicted.

The long form you give there is to be used in case the old email
address is not a unique key. See 'git help shortlog'.

The problem we have at work is that one woman's old email address
includes her deadname, like <firstname.lastname@company.com>.  I will
leave it up to her whether she chooses to be listed explicitly in the
mailmap.  I have wondered if we should permit hashed email addresses
to be used for this specific case, but this also has its drawbacks.

Phil

Re: What's cooking in git.git (Jul 2019, #06; Thu, 25)

[Ariadne Conill]

Hello,

On Thu, Aug 8, 2019 at 10:07 PM Phil Hord <phil.hord@gmail.com> wrote:
>
> The issue of deadnaming aside, turning on log.mailmap by default is
> the sensible thing to do given that other Git features already honor
> it that way.  Having it ignored-by-default (but only sometimes) just
> adds confusion when a mailmap is available.

This is my point exactly!  My motive for improving this behaviour is
entirely irrelevant, honestly.  I regret ever bringing it up elsewhere
in the discussions, as it's completely irrelevant.

> > > >  - The '.mailmap' provides a list of transgender individuals, along
> > > >    with their deadname, which can be used to harass them.
> > >
> > > This 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.
> >
> > Ah, I may be severely mistaken -- my memory was that '.mailmap'
> > rewriting could be used to rewrite both name and email, not merely
> > email. I thought that records could take:
> >
> >   A U Thor <author@xample.com> -> B C Xyzz <newname@example.com>
> >
> > instead of canonicalizing by email alone. If this is the case, then I
> > completely agree and share the opinion that this is not as bad as I
> > originally depicted.
>
> The long form you give there is to be used in case the old email
> address is not a unique key. See 'git help shortlog'.
>
> The problem we have at work is that one woman's old email address
> includes her deadname, like <firstname.lastname@company.com>.  I will
> leave it up to her whether she chooses to be listed explicitly in the
> mailmap.  I have wondered if we should permit hashed email addresses
> to be used for this specific case, but this also has its drawbacks.

I'd be open to looking into adding support for hashing the e-mail for
cases like this if people are interested.  The
firstname.lastname@company.com case is certainly a tough one to crack
otherwise, but I think that a solution that works for most cases still
is useful.  In the meantime, I think it makes sense to let people
decide whether they wish to use mailmap for this purpose, based on
their own understanding of the risks involved.

Ariadne

Re: What's cooking in git.git (Jul 2019, #06; Thu, 25)

[Taylor Blau]

Hi Ariadne,

On Thu, Aug 08, 2019 at 10:21:02PM -0500, Ariadne Conill wrote:
> Hello,
>
> On Thu, Aug 8, 2019 at 10:07 PM Phil Hord <phil.hord@gmail.com> wrote:
> >
> > The issue of deadnaming aside, turning on log.mailmap by default is
> > the sensible thing to do given that other Git features already honor
> > it that way.  Having it ignored-by-default (but only sometimes) just
> > adds confusion when a mailmap is available.
>
> This is my point exactly!  My motive for improving this behaviour is
> entirely irrelevant, honestly.  I regret ever bringing it up elsewhere
> in the discussions, as it's completely irrelevant.

Yeah, I think that this makes much more sense (at least to me) as an
issue separate from the deadname rewriting topic. If nothing else, this
makes 'git log' act like 'git shortlog', which only makes sense.

> > > > >  - The '.mailmap' provides a list of transgender individuals, along
> > > > >    with their deadname, which can be used to harass them.
> > > >
> > > > This 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.
> > >
> > > Ah, I may be severely mistaken -- my memory was that '.mailmap'
> > > rewriting could be used to rewrite both name and email, not merely
> > > email. I thought that records could take:
> > >
> > >   A U Thor <author@xample.com> -> B C Xyzz <newname@example.com>
> > >
> > > instead of canonicalizing by email alone. If this is the case, then I
> > > completely agree and share the opinion that this is not as bad as I
> > > originally depicted.
> >
> > The long form you give there is to be used in case the old email
> > address is not a unique key. See 'git help shortlog'.
> >
> > The problem we have at work is that one woman's old email address
> > includes her deadname, like <firstname.lastname@company.com>.  I will
> > leave it up to her whether she chooses to be listed explicitly in the
> > mailmap.  I have wondered if we should permit hashed email addresses
> > to be used for this specific case, but this also has its drawbacks.
>
> I'd be open to looking into adding support for hashing the e-mail for
> cases like this if people are interested.  The
> firstname.lastname@company.com case is certainly a tough one to crack
> otherwise, but I think that a solution that works for most cases still
> is useful.  In the meantime, I think it makes sense to let people
> decide whether they wish to use mailmap for this purpose, based on
> their own understanding of the risks involved.

Yep. Totally agreed, and thank you for these patches.

> Ariadne

Thanks,
Taylor

Re: What's cooking in git.git (Jul 2019, #06; Thu, 25)

[Jeff King]

On Thu, Aug 08, 2019 at 08:07:36PM -0700, Phil Hord wrote:

> The long form you give there is to be used in case the old email
> address is not a unique key. See 'git help shortlog'.
> 
> The problem we have at work is that one woman's old email address
> includes her deadname, like <firstname.lastname@company.com>.  I will
> leave it up to her whether she chooses to be listed explicitly in the
> mailmap.  I have wondered if we should permit hashed email addresses
> to be used for this specific case, but this also has its drawbacks.

Since the set of hash inputs is finite and small (i.e., the set of all
emails in the repository), it would be trivial to generate the plaintext
mapping from even a cryptographically strong hashed mapping.

Which isn't to say it's _totally_ worthless, since that adds an extra
step, but it really is just obfuscating the data.

-Peff

RE: What's cooking in git.git (Jul 2019, #06; Thu, 25)

[Randall S. Becker]

On 01 Aug 2019 13:05:12, Junio wrote:
> >> *snip*

I think this got missed in the shuffle, but I am getting questions about the topic from my own team that I cannot answer.

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

Regards and Thanks,
Randall

Re: What's cooking in git.git (Jul 2019, #06; Thu, 25)

[Jeff King]

On Fri, Aug 09, 2019 at 10:06:06AM -0400, Randall S. Becker wrote:

> On 01 Aug 2019 13:05:12, Junio wrote:
> > >> *snip*
> 
> I think this got missed in the shuffle, but I am getting questions about the topic from my own team that I cannot answer.
> 
> I 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.

I don't know of any plans for checkout in particular, but I think the
docs for restore/switch make it clear that it's way too early to start
scripting around them:

  $ git grep EXPERIMENTAL Documentation/
  Documentation/git-restore.txt:THIS COMMAND IS EXPERIMENTAL. THE BEHAVIOR MAY CHANGE.
  Documentation/git-switch.txt:THIS COMMAND IS EXPERIMENTAL. THE BEHAVIOR MAY CHANGE.

-Peff

RE: What's cooking in git.git (Jul 2019, #06; Thu, 25)

[Randall S. Becker]

On August 9, 2019 12:29 PM, Jeff King wrote:
> On Fri, Aug 09, 2019 at 10:06:06AM -0400, Randall S. Becker wrote:
> 
> > On 01 Aug 2019 13:05:12, Junio wrote:
> > > >> *snip*
> >
> > I think this got missed in the shuffle, but I am getting questions about the
> topic from my own team that I cannot answer.
> >
> > I 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.
> 
> I don't know of any plans for checkout in particular, but I think the docs for
> restore/switch make it clear that it's way too early to start scripting around
> them:
> 
>   $ git grep EXPERIMENTAL Documentation/
>   Documentation/git-restore.txt:THIS COMMAND IS EXPERIMENTAL. THE
> BEHAVIOR MAY CHANGE.
>   Documentation/git-switch.txt:THIS COMMAND IS EXPERIMENTAL. THE
> BEHAVIOR MAY CHANGE.

Thanks Peff. Good guidance. I did not notice that part.

Appreciations,
Randall

Re: What's cooking in git.git (Jul 2019, #06; Thu, 25)

[Phil Hord]

On Fri, Aug 9, 2019 at 4:41 AM Jeff King <peff@peff.net> wrote:
>
> On Thu, Aug 08, 2019 at 08:07:36PM -0700, Phil Hord wrote:
>
> > The long form you give there is to be used in case the old email
> > address is not a unique key. See 'git help shortlog'.
> >
> > The problem we have at work is that one woman's old email address
> > includes her deadname, like <firstname.lastname@company.com>.  I will
> > leave it up to her whether she chooses to be listed explicitly in the
> > mailmap.  I have wondered if we should permit hashed email addresses
> > to be used for this specific case, but this also has its drawbacks.
>
> Since the set of hash inputs is finite and small (i.e., the set of all
> emails in the repository), it would be trivial to generate the plaintext
> mapping from even a cryptographically strong hashed mapping.
>
> Which isn't to say it's _totally_ worthless, since that adds an extra
> step, but it really is just obfuscating the data.

Yes, obfuscation is all I expect. Someone who needs deeper scrubbing
will need to rewrite their history instead.

Re: What's cooking in git.git (Jul 2019, #06; Thu, 25)

[Junio C Hamano]

"Randall S. Becker" <rsbecker@nexbridge.com> writes:

> On 01 Aug 2019 13:05:12, Junio wrote:
>> >> *snip*
>
> I think this got missed in the shuffle, but I am getting questions
> about the topic from my own team that I cannot answer.
>
> I 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.

The two new commands were done in response to a common "checkout
does two different things, either checkout a branch in order to
start working on it, or checkout paths into the current workspace to
work on them" complaint.  Those who are used to and are OK with the
"git" command that changes behaviour based on the rest of args (i.e.
"checkout <branchname>" and "checkout [<tree-ish>] <pathspec>" are
the ways to obtain these two behaviours) can safely keep using the
command they are familiar with.

I do not think there currently is any plan to deprecate checkout.

Re: What's cooking in git.git (Jul 2019, #06; Thu, 25)

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> I don't know of any plans for checkout in particular, but I think the
> docs for restore/switch make it clear that it's way too early to start
> scripting around them:
>
>   $ git grep EXPERIMENTAL Documentation/
>   Documentation/git-restore.txt:THIS COMMAND IS EXPERIMENTAL. THE BEHAVIOR MAY CHANGE.
>   Documentation/git-switch.txt:THIS COMMAND IS EXPERIMENTAL. THE BEHAVIOR MAY CHANGE.

Would it ever be OK to script around checkout, restore and/or switch
Porcelain commands?

Re: What's cooking in git.git (Jul 2019, #06; Thu, 25)

[Phil Hord]

On Fri, Aug 9, 2019 at 10:48 AM Junio C Hamano <gitster@pobox.com> wrote:
>
> Jeff King <peff@peff.net> writes:
>
> > I don't know of any plans for checkout in particular, but I think the
> > docs for restore/switch make it clear that it's way too early to start
> > scripting around them:
> >
> >   $ git grep EXPERIMENTAL Documentation/
> >   Documentation/git-restore.txt:THIS COMMAND IS EXPERIMENTAL. THE BEHAVIOR MAY CHANGE.
> >   Documentation/git-switch.txt:THIS COMMAND IS EXPERIMENTAL. THE BEHAVIOR MAY CHANGE.
>
> Would it ever be OK to script around checkout, restore and/or switch
> Porcelain commands?

Users who wish to get their job done will script around porcelain all
the time.  I would be surprised if even 1% of build scripts use 'git
checkout-index' instead of 'git checkout'.

No, this doesn't make it OK. ;)

RE: What's cooking in git.git (Jul 2019, #06; Thu, 25)

[Randall S. Becker]

On August 9, 2019 1:45 PM, Junio C Hamano wrote:
> "Randall S. Becker" <rsbecker@nexbridge.com> writes:
> 
> > On 01 Aug 2019 13:05:12, Junio wrote:
> >> >> *snip*
> >
> > I think this got missed in the shuffle, but I am getting questions
> > about the topic from my own team that I cannot answer.
> >
> > I 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.
> 
> The two new commands were done in response to a common "checkout
> does two different things, either checkout a branch in order to start
working
> on it, or checkout paths into the current workspace to work on them"
> complaint.  Those who are used to and are OK with the "git" command that
> changes behaviour based on the rest of args (i.e.
> "checkout <branchname>" and "checkout [<tree-ish>] <pathspec>" are the
> ways to obtain these two behaviours) can safely keep using the command
> they are familiar with.
> 
> I do not think there currently is any plan to deprecate checkout.

Thanks.

Re: What's cooking in git.git (Jul 2019, #06; Thu, 25)

[Jeff King]

On Fri, Aug 09, 2019 at 11:05:34AM -0700, Phil Hord wrote:

> On Fri, Aug 9, 2019 at 10:48 AM Junio C Hamano <gitster@pobox.com> wrote:
> >
> > Jeff King <peff@peff.net> writes:
> >
> > > I don't know of any plans for checkout in particular, but I think the
> > > docs for restore/switch make it clear that it's way too early to start
> > > scripting around them:
> > >
> > >   $ git grep EXPERIMENTAL Documentation/
> > >   Documentation/git-restore.txt:THIS COMMAND IS EXPERIMENTAL. THE BEHAVIOR MAY CHANGE.
> > >   Documentation/git-switch.txt:THIS COMMAND IS EXPERIMENTAL. THE BEHAVIOR MAY CHANGE.
> >
> > Would it ever be OK to script around checkout, restore and/or switch
> > Porcelain commands?
> 
> Users who wish to get their job done will script around porcelain all
> the time.  I would be surprised if even 1% of build scripts use 'git
> checkout-index' instead of 'git checkout'.

It's even worse if you really want to switch branches, and not checkout
files. You'd probably need to use symbolic-ref, read-tree, and
checkout-index.

IMHO scripting around "action" commands like checkout is less bad than
around "output" commands like log. The general action of "switch to this
branch" is unlikely to be changed much over the years (or via config),
but the output of log, etc, is.

There are no guarantees, of course, but I imagine that the tradeoff in
simplicity of using git-switch versus manually reimplementing it is
probably a good one for many scripts.

-Peff

Re: What's cooking in git.git (Jul 2019, #06; Thu, 25)

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> IMHO scripting around "action" commands like checkout is less bad than
> around "output" commands like log. The general action of "switch to this
> branch" is unlikely to be changed much over the years (or via config),
> but the output of log, etc, is.
>
> There are no guarantees, of course, but I imagine that the tradeoff in
> simplicity of using git-switch versus manually reimplementing it is
> probably a good one for many scripts.

Another reason why scripting around "action" may be OK is that most
of the time scriptors would want to (blindly) adopt improvements
made to the underly ing command anyway.  If you scripted around "git
checkout" before we introduced multiple worktree feature where a
branch that is already active in another worktree is protected from
getting checked out elsewhere, your script will automatically get
that protection (and more importantly, the error message given as an
explanation to the end users) for free.  Of course your script must
be prepared to react correctly to a failure from "git checkout", but
that goes without saying for any command you invoke in your script.

RE: What's cooking in git.git (Jul 2019, #06; Thu, 25)

[Randall S. Becker]

On August 11, 2019 8:39 PM, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
> 
> > IMHO scripting around "action" commands like checkout is less bad than
> > around "output" commands like log. The general action of "switch to
> > this branch" is unlikely to be changed much over the years (or via
> > config), but the output of log, etc, is.
> >
> > There are no guarantees, of course, but I imagine that the tradeoff in
> > simplicity of using git-switch versus manually reimplementing it is
> > probably a good one for many scripts.
> 
> Another reason why scripting around "action" may be OK is that most of the
> time scriptors would want to (blindly) adopt improvements made to the
> underly ing command anyway.  If you scripted around "git checkout" before
> we introduced multiple worktree feature where a branch that is already
> active in another worktree is protected from getting checked out elsewhere,
> your script will automatically get that protection (and more importantly, the
> error message given as an explanation to the end users) for free.  Of course
> your script must be prepared to react correctly to a failure from "git
> checkout", but that goes without saying for any command you invoke in your
> script.

That would describe my subcommunity pretty accurately 😉

Thanks,
Randall