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
Attachment:
signature.asc
Description: PGP signature