On 2021-01-05 at 20:05:22, Junio C Hamano wrote: > "brian m. carlson" <sandals@xxxxxxxxxxxxxxxxxxxx> writes: > > > For example, a person may transition from one gender to another, > > changing their name, or they may have changed their name to disassociate > > themselves from an abusive family or partner. In such a case, using the > > former name or address in any way may be undesirable and the person may > > wish to replace it as completely as possible. > > I am not sure if we want to even mention the "for example" here. > > These are certainly all legitimate reasons to want this feature, but > after reading the "for example", lack of a corresponding negative > statement (e.g. sometimes people also change their name or address > to hide their bad behaviour in the past that is associated with > these names) needlessly stood out and made me wonder if we need to > somehow defend the feature with "...but we do not mean to abet > people in hiding their past bad behaviour with this mechanism". I'd > prefer us not forced to defend the mechanism if we did not have to. I added it because I imagine the use cases for this feature aren't immediately obvious to a lot of people and the general rule is that commit messages explain why we would implement such a feature. If you'd prefer I drop it and leave it up to the imagination (or to the list archives), I can do that. > > +SHA-1 is not accepted as a hash algorithm in mailmaps. > > Is this needed to be said? After all, we won't take @md5: or > @blake2: or anything other than @sha256: in this version (and > probably any forseeable versions). Unless we offer a way to plug-in > algos of projects' choice, that is, and at that point, "SHA-1 is not > accepted" is a statement too strong for us to make. I'll drop that line. -- brian m. carlson (he/him or they/them) Houston, Texas, US
Attachment:
signature.asc
Description: PGP signature
