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/