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

From: Junio C Hamano <gitster@pobox.com>
Date: Dec 14, 2020, 00:09 UTC
Message-ID: <xmqqv9d4ergd.fsf@gitster.c.googlers.com>
In-Reply-To: <20201213010539.544101-2-sandals@crustytoothpaste.net>

"brian m. carlson" <sandals@crustytoothpaste.net> writes:

> 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.

Not just "where does the hashed entry can appear in the file", but "how exactly does it gets computed" needs to be described. If it is sufficient to do something like

	set x $(echo doe@example.com | sha256sum) &&
	echo "@sha256sum:$2"

that exact procedure must be described to the users in the documentation (note: I know the above is not correct as I looked at the tests---it is a demonstration of the need for a procedure using commonly available tools).

I wonder if somebody may want to do a dedicated tool that lets you

 (1) given an e-mail and/or a name, look-up existing entries and
     show what <name, e-mail> pair it maps to;

 (2) take a new <name, e-mail> pair and add mapping from it to some
     other <name, e-mail> pair.

 (3) take an existing mailmap file, and obfuscate all the existing
     entries.

The first one is covered by "check-mailmap", so the other two could be new features added to the command to be triggered with a command line option.

> +	cat >hashed <<-EOF &&
> +	$GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL> $hashed_author_name <$GIT_AUTHOR_EMAIL>
> +	EOF
> +	git check-mailmap  "$GIT_AUTHOR_NAME <$GIT_AUTHOR_EMAIL>" >actual &&

The two spaces after "check-mailmap" is not significant but drew my attention. Let's not do so.