Re: [PATCH 1/1] mailmap: support hashed entries in mailmaps

From: brian m. carlson <sandals@crustytoothpaste.net>
Date: Dec 13, 2020, 20:38 UTC
Message-ID: <X9Z70aNc0cWcohNm@camp.crustytoothpaste.net>
In-Reply-To: <b297b843-99e1-152d-aed1-20371af42d42@kdbg.org>

On 2020-12-13 at 09:45:58, Johannes Sixt wrote:

Show 16 quoted lines

> 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