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

[Johannes Sixt <j6t@kdbg.org>]

Am 13.12.20 um 02:05 schrieb brian m. carlson:
> Many people, through the course of their lives, will change either a
> name or an email address.  For this reason, we have the mailmap, to map
> from a user's former name or email address to their current, canonical
> forms.  Normally, this works well as it is.
> 
> However, sometimes people change a name or an email address and wish to
> wholly disassociate themselves from that former name or email address.
> For example, a person may have left a company which engaged in a deeply
> unethical act with which the person does not want to be associated, or
> they may have changed their name to disassociate themselves from an
> abusive family or partner.  In such a case, using the former name or
> address in any way may be undesirable and the person may wish to replace
> it as completely as possible.
> 
> For projects which wish to support this, introduce hashed forms into the
> mailmap.  These forms, which start with "@sha256:" followed by a SHA-256
> hash of the entry, can be used in place of the form used in the commit
> field.  This form is intentionally designed to be unlikely to conflict
> with legitimate use cases.  For example, this is not a valid email
> address according to RFC 5322.  In the unlikely event that a user has
> put such a form into the actual commit as their name, we will accept it.
> 
> While the form of the data is designed to accept multiple hash
> algorithms, we intentionally do not support SHA-1.  There is little
> reason to support such a weak algorithm in new use cases and no
> backwards compatibility to consider.  Moreover, SHA-256 is faster than
> the SHA1DC implementation we use, so this not only improves performance,
> but simplifies the current implementation somewhat as well.
> 
> Note that it is, of course, possible to perform a lookup on all commit
> objects to determine the actual entry which matches the hashed form of
> the data.  However, a project for which this feature is valuable may
> simply insert entries for many contributors in order to make discovery
> of "interesting" entries significantly less convenient.
> 
> Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
> ---

...

> diff --git a/t/t4203-mailmap.sh b/t/t4203-mailmap.sh
> index 586c3a86b1..794133ba5d 100755
> --- a/t/t4203-mailmap.sh
> +++ b/t/t4203-mailmap.sh
> @@ -62,6 +62,41 @@ test_expect_success 'check-mailmap --stdin arguments' '
>  	test_cmp expect actual
>  '
>  
> +test_expect_success 'hashed mailmap' '
> +	test_config mailmap.file ./hashed &&
> +	hashed_author_name="@sha256:$(printf "$GIT_AUTHOR_NAME" | test-tool sha256)" &&
> +	hashed_author_email="@sha256:$(printf "$GIT_AUTHOR_EMAIL" | test-tool sha256)" &&
> +	cat >expect <<-EOF &&
> +	$GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL>
> +	EOF
...
> +	cat >hashed <<-EOF &&
> +	$GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL> <$hashed_author_email>
> +	EOF
> +	git check-mailmap  "$GIT_AUTHOR_NAME <$GIT_AUTHOR_EMAIL>" >actual &&
> +	test_cmp expect actual

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?

-- Hannes