From: Johannes Sixt <j6t@kdbg.org>
Date: Sun, 13 Dec 2020 09:45:58 GMT
Subject: Re: [PATCH 1/1] mailmap: support hashed entries in mailmaps
Message-ID: <b297b843-99e1-152d-aed1-20371af42d42@kdbg.org>
In-Reply-To: <2cc4925f-3661-1dfb-2668-5f56edcb8455@kdbg.org>

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.

-- Hannes