git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH v2 5/5] mailmap: support hashed entries in mailmaps

From
brian m. carlson <sandals@crustytoothpaste.net>
Date
Jan 6, 2021, 00:28 UTC
Message-ID
<X/UENS0EXyFjjjHA@camp.crustytoothpaste.net>
In-Reply-To
<xmqqft3fywsd.fsf@gitster.c.googlers.com>
On 2021-01-05 at 20:05:22, Junio C Hamano wrote:
Show 18 quoted lines
> "brian m. carlson" <sandals@crustytoothpaste.net> 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.

Show 7 quoted lines
> > +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
Previous: Junio C HamanoNext: Junio C Hamano
Message 18 of 19 in “Hashed mailmap”
  1. 0/5 Hashed mailmapbrian m. carlson, Jan 3, 2021
  2. 1/5 mailmap: add a function to inspect the number of entriesbrian m. carlson, Jan 3, 2021
  3. Ævar Arnfjörð BjarmasonJan 4, 2021
  4. René ScharfeJan 4, 2021
  5. 2/5 mailmap: switch to opaque structbrian m. carlson, Jan 3, 2021
  6. Ævar Arnfjörð BjarmasonJan 4, 2021
  7. 3/5 t4203: add failing test for case-sensitive local-parts and namesbrian m. carlson, Jan 3, 2021
  8. 4/5 mailmap: use case-sensitive comparisons for local-parts and namesbrian m. carlson, Jan 3, 2021
  9. Ævar Arnfjörð BjarmasonJan 4, 2021
  10. Junio C HamanoJan 6, 2021
  11. Ævar Arnfjörð BjarmasonJan 12, 2021
  12. 5/5 mailmap: support hashed entries in mailmapsbrian m. carlson, Jan 3, 2021
  13. Ævar Arnfjörð BjarmasonJan 5, 2021
  14. brian m. carlsonJan 6, 2021
  15. Ævar Arnfjörð BjarmasonJan 10, 2021
  16. brian m. carlsonJan 10, 2021
  17. Junio C HamanoJan 5, 2021
  18. brian m. carlsonJan 6, 2021
  19. Junio C HamanoJan 6, 2021

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.