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

Re: [PATCH v2 1/4] Add log.mailmap as configurational option for mailmap location

From
Junio C Hamano <gitster@pobox.com>
Date
Feb 2, 2009, 07:56 UTC
Message-ID
<7vr62hl1a3.fsf@gitster.siamese.dyndns.org>
In-Reply-To
<4986A539.3080606@trolltech.com>
Marius Storm-Olsen <marius@trolltech.com> writes:
Show 13 quoted lines
> Junio C Hamano said the following on 02.02.2009 04:01:
>> Marius Storm-Olsen <marius@trolltech.com> writes:
>>> This allows us to override a repo mailmap file, or to use
>>> mailmap files elsewhere than the repository root.
>>
>> I think the new feature is not so well conceived.
>>
>> Should it always be a wholesale override, or should it also support
>> augmenting the repository version with a private copy?
>
> Sure, I can rewrite it to be augmenting, rather than overriding.
> I assume that the normal .mailmap file should be parsed first, then
> the log.mailmap one?

Augmenting one would behave that way. I was more wondering if people would want to be able to choose either, perhaps from the command line option or something.

> Sure, but I left it in to allow "old-style" usage. Just in case the
> were use-cases for not using the log.mailmap one. I can nuke the
> arguments if you don't want them anymore.

What I think would be sensible, if we really want to make this feature flexible, would be to introduce a command line option (and perhaps environment variable) that takes the usual precidence (the command line that specifies the mailmap file, then the environment and then finally the log.mailmap config variable). And if we go that route, that "usuall NULL" parameter would be where the callers pass the filename they got from their command line.

But if you feel it is overengineering, I would not disagree. In such a case, however, I do not think there is a reason for one particular caller to pass some custom value there, just to be inconsistent from others.

Previous: Marius Storm-OlsenNext: Marius Storm-Olsen
Message 10 of 15 in “Extend mailmap functionality”
  1. 0/4 Extend mailmap functionalityMarius Storm-Olsen, Feb 1, 2009
  2. 1/4 Add log.mailmap as configurational option for mailmap locationMarius Storm-Olsen, Feb 1, 2009
  3. 2/4 Add find_insert_index, insert_at_index and clear_func functions to string_listMarius Storm-Olsen, Feb 1, 2009
  4. 3/4 Add map_user() and clear_mailmap() to mailmapMarius Storm-Olsen, Feb 1, 2009
  5. 4/4 Change current mailmap usage to do matching on both name and email of author/committer.Marius Storm-Olsen, Feb 1, 2009
  6. Junio C HamanoFeb 2, 2009
  7. Marius Storm-OlsenFeb 2, 2009
  8. Junio C HamanoFeb 2, 2009
  9. Marius Storm-OlsenFeb 2, 2009
  10. Junio C HamanoFeb 2, 2009
  11. Marius Storm-OlsenFeb 2, 2009
  12. Junio C HamanoFeb 2, 2009
  13. Junio C HamanoFeb 2, 2009
  14. Sverre RabbelierFeb 2, 2009
  15. Marius Storm-OlsenFeb 2, 2009

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.