Thread (14 messages) 14 messages, 6 authors, 2020-12-18

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

From: Johannes Sixt <hidden>
Date: 2020-12-13 09:49:25

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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help