git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Ariadne Conill <ariadne@dereferenced.org>
To: Taylor Blau <me@ttaylorr.com>, Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, Phil Hord <phil.hord@gmail.com>
Subject: Re: What's cooking in git.git (Jul 2019, #06; Thu, 25)
Date: Thu, 08 Aug 2019 21:34:15 -0400	[thread overview]
Message-ID: <3C7105E5-5DE1-42DC-A9A4-65C061FD6139@dereferenced.org> (raw)
In-Reply-To: <20190809001315.GA87896@syl.lan>

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

  reply	other threads:[~2019-08-09  1:34 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-26  0:19 What's cooking in git.git (Jul 2019, #06; Thu, 25) Junio C Hamano
2019-07-26 14:33 ` Johannes Schindelin
2019-07-26 20:23   ` Junio C Hamano
2019-07-27 19:38 ` Rohit Ashiwal
2019-07-27 20:40   ` Elijah Newren
2019-07-27 20:57     ` Rohit Ashiwal
2019-07-27 21:42       ` Elijah Newren
2019-07-28 20:34 ` Carlo Arenas
2019-08-09  0:13 ` Taylor Blau
2019-08-09  1:34   ` Ariadne Conill [this message]
2019-08-09  2:07     ` Taylor Blau
2019-08-09  3:04       ` Ariadne Conill
2019-08-09  3:07       ` Phil Hord
2019-08-09  3:21         ` Ariadne Conill
2019-08-09 11:21           ` Taylor Blau
2019-08-09 11:41         ` Jeff King
2019-08-09 17:39           ` Phil Hord
2019-08-09 14:06     ` Randall S. Becker
2019-08-09 16:29       ` Jeff King
2019-08-09 16:32         ` Randall S. Becker
2019-08-09 17:45         ` Junio C Hamano
2019-08-09 18:05           ` Phil Hord
2019-08-10  6:10             ` Jeff King
2019-08-12  0:39               ` Junio C Hamano
2019-08-12 13:39                 ` Randall S. Becker
2019-08-09 17:44       ` Junio C Hamano
2019-08-09 19:06         ` Randall S. Becker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3C7105E5-5DE1-42DC-A9A4-65C061FD6139@dereferenced.org \
    --to=ariadne@dereferenced.org \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=me@ttaylorr.com \
    --cc=phil.hord@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).