On 2021-01-10 at 19:24:34, Ævar Arnfjörð Bjarmason wrote:
> Doesn't the difference in some sense boil down to either an implicit
> promise or an implicit assumption that the hashed version is forever
> going to be protected by some security-through-obscurity/inconvenience
> when it comes to git.git & its default tooling?
> 
> And would those users be as comfortable with the difference between
> encoded v.s. hashed if e.g. "git check-mailmap" learned to read the
> .mailmap and search-replace all the hashed versions with their
> materialized values, or if popular tools like Emacs learned to via a Git
> .mailmap in a "need translation" similar to *.gpg and *.gz. How about if
> popular web views of Git served up that materialized "check-mailmap"
> output by default?
> 
> None of which I think is implausible that we'll get as follow-up
> patches, I might even submit some at some point, not out of some spite.
> Just because I don't want to maintain out-of-tree code for an
> out-of-tree program that understands a Git .mailmap today, but where I'd
> need to search-replace the hashed versions.

Yes, I think we do rely on this being inconvenient.  If you plan to
submit such a patch, I'm going to let this series drop.
-- 
brian m. carlson (he/him or they/them)
Houston, Texas, US