Re: [PATCH v2 5/5] mailmap: support hashed entries in mailmaps
- From
brian m. carlson <sandals@crustytoothpaste.net>
- Date
- Jan 10, 2021, 21:26 UTC
- Message-ID
- <X/txB8b3/qqbwbmC@camp.crustytoothpaste.net>
- In-Reply-To
- <87sg7861e5.fsf@evledraar.gmail.com>
On 2021-01-10 at 19:24:34, Ævar Arnfjörð Bjarmason wrote:
Show 18 quoted lines
> 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