"brian m. carlson" <sandals@xxxxxxxxxxxxxxxxxxxx> writes: > On 2022-09-19 at 11:20:13, Ævar Arnfjörð Bjarmason wrote: >> I.e. I think a "deadname" use-case of this would probably: >> >> * Have some comment at the top of .mailmap about why some values are >> over-encoded (or perhaps it would be obvious to everyone working on >> that repo why someone was encoding the "plain ASCII" A-Za-z0-9 space). > > I don't think we need to do this. First of all, it makes people curious > and nosy, and it draws attention to the situation when in many cases, > other contributors might not even notice as they're updating the > mailmap. Adding lots of attention is going to add the potential for > harassment. > >> But should not: >> >> * Assume that other tools such as "fsck", "check-mailmap" or even "log" >> won't have future features that make de-obscuring these values easier, >> or something that's part of a normal workflow. > > Your statement that you intended to write exactly such a feature was the > main reason I dropped the SHA-256 hashed mailmap series. I don't think > it's constructive to offer or propose to offer such a feature in Git if > we're trying to obscure people's names in the mailmap, ... Yes, I remember that exchange, and I find your position reasonable. Yes, we all know how to build such a feature. Yes, we know a third-party implementation of such a feature may materialize. But we do not have to be the ones to encourage use of such a feature. > I also have an alternate proposal which I pitched to some folks at Git > Merge and which I just finished writing up that basically moves personal > names and emails out of commits, replacing them with opaque identifiers, That part I can agree with. > and using a constantly squashed mailmap commit in a special ref to store > the mapping. This part only half (the "special ref" half, not "constatntly squashed" part, even though I know why it matters more to your goal). My gut feeling is that auditing and merging will become nightmare.
