Re: [PATCH 1/1] mailmap: support hashed entries in mailmaps
- From
Johannes Sixt <j6t@kdbg.org>
- Date
- Dec 13, 2020, 09:45 UTC
- 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:
Show 10 quoted lines
> 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