From: "brian m. carlson" <sandals@crustytoothpaste.net>
To: Johannes Sixt <j6t@kdbg.org>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 1/1] mailmap: support hashed entries in mailmaps
Date: Sun, 13 Dec 2020 20:38:41 +0000 [thread overview]
Message-ID: <X9Z70aNc0cWcohNm@camp.crustytoothpaste.net> (raw)
In-Reply-To: <b297b843-99e1-152d-aed1-20371af42d42@kdbg.org>
[-- Attachment #1: Type: text/plain, Size: 1311 bytes --]
On 2020-12-13 at 09:45:58, Johannes Sixt wrote:
> Am 13.12.20 um 10:34 schrieb Johannes Sixt:
> > I don't understand the concept. A mailmap entry of the form
> >
> > A <a@b> <x@y>
> >
> > tells that the former address <x@y>, which is recorded in old project
> > history, should be replaced by A <a@b> when a commit is displayed. I am
> > assuming that the idea is that old <x@y> should be the "banned" address.
> > How does a hashed entry help when the hashed value appears at the right
> > side of a mailmap entry and that literal string never appears anywhere
> > in the history?
>
> Never mind, I got it: A wants to be disassociated from <x@y>, but not
> from their contributions whose authorship was recorded as <x@y>.
> Therefore, Git must always compute the hash of all of <x@y>, <a@b>, etc,
> just in case that the hashed form appears anywhere in the mailmap file.
Yup, exactly. You can't specify the hashed one on the new side
because it has to map to it, but you can on the old side. Sorry if
that wasn't clear.
Come to think of it, this probably needs documentation as well, so I'll
wait for any other feedback and then reroll with that in there.
Hopefully that will clear up any potential confusion.
--
brian m. carlson (he/him or they/them)
Houston, Texas, US
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 263 bytes --]
next prev parent reply other threads:[~2020-12-13 20:39 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-13 1:05 [PATCH 0/1] Hashed mailmap support brian m. carlson
2020-12-13 1:05 ` [PATCH 1/1] mailmap: support hashed entries in mailmaps brian m. carlson
2020-12-13 9:34 ` Johannes Sixt
2020-12-13 9:45 ` Johannes Sixt
2020-12-13 20:38 ` brian m. carlson [this message]
2020-12-14 0:09 ` Junio C Hamano
2020-12-16 0:50 ` brian m. carlson
2020-12-14 11:54 ` Ævar Arnfjörð Bjarmason
2020-12-15 11:13 ` Phillip Wood
2020-12-15 1:48 ` [PATCH 0/1] Hashed mailmap support Jeff King
2020-12-15 2:40 ` Jeff King
2020-12-15 11:15 ` Phillip Wood
2020-12-18 2:29 ` brian m. carlson
2020-12-18 5:56 ` Jeff King
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=X9Z70aNc0cWcohNm@camp.crustytoothpaste.net \
--to=sandals@crustytoothpaste.net \
--cc=git@vger.kernel.org \
--cc=j6t@kdbg.org \
/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.
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 NNTP newsgroup(s).