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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Junio C Hamano said the following on 02.02.2009 08:56:
Marius Storm-Olsen <marius@xxxxxxxxxxxxx> writes:
Junio C Hamano said the following on 02.02.2009 04:01:
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.

Oh, I see. *ponder* maybe, though you could say that about any option in the .git/config file, right?


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.

I'm not sure of the use case of the command line option. In which case would you want to only use the mailmap for that one command? It doesn't normally affect your git commands, so it doesn't hurt to just set the log.mailmap option. The environment use case would be just like setting it in your ~/.gitconfig, other than you can have a different one for each console, I guess.

Now, if we extended the mailmap feature even further, to report the mappings from the rev-list code ((optional of course)), so that any log viewer would show the mapped information; _then_ I would consider the command-line and environment variables as mandatory. Since, then you might want the feature off by default, and only use the mappings when you need to figure out a breakage, thus need a quick way to enable it.

So, unless anyone raises their hand that they need command-line/environment ways of setting the mailmap file used, I'll leave it as is for now. Ok?

--
.marius [@trolltech.com]
'if you know what you're doing, it's not research'

Attachment: signature.asc
Description: OpenPGP digital signature


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux