git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Johannes Sixt <j6t@kdbg.org>
Date
Dec 13, 2020, 09:34 UTC
Message-ID
<2cc4925f-3661-1dfb-2668-5f56edcb8455@kdbg.org>
In-Reply-To
<20201213010539.544101-2-sandals@crustytoothpaste.net>
Am 13.12.20 um 02:05 schrieb brian m. carlson:
Show 37 quoted lines
> 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>
> ---
...
Show 15 quoted lines
> 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
...
Show 5 quoted lines
> +	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
Previous: brian m. carlsonNext: Johannes Sixt
Message 3 of 14 in “Hashed mailmap support”
  1. 0/1 Hashed mailmap supportbrian m. carlson, Dec 13, 2020
  2. 1/1 mailmap: support hashed entries in mailmapsbrian m. carlson, Dec 13, 2020
  3. Johannes SixtDec 13, 2020
  4. Johannes SixtDec 13, 2020
  5. brian m. carlsonDec 13, 2020
  6. Junio C HamanoDec 14, 2020
  7. brian m. carlsonDec 16, 2020
  8. Ævar Arnfjörð BjarmasonDec 14, 2020
  9. Phillip WoodDec 15, 2020
  10. Jeff KingDec 15, 2020
  11. Jeff KingDec 15, 2020
  12. Phillip WoodDec 15, 2020
  13. brian m. carlsonDec 18, 2020
  14. Jeff KingDec 18, 2020

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.