From: Marius Storm-Olsen <marius@trolltech.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH v2 1/4] Add log.mailmap as configurational option for mailmap location
Date: Mon, 02 Feb 2009 09:26:47 +0100 [thread overview]
Message-ID: <4986AE47.3010305@trolltech.com> (raw)
In-Reply-To: <7vr62hl1a3.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 2713 bytes --]
Junio C Hamano said the following on 02.02.2009 08:56:
> Marius Storm-Olsen <marius@trolltech.com> 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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 187 bytes --]
next prev parent reply other threads:[~2009-02-02 8:28 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-01 20:59 [PATCH v2 0/4] Extend mailmap functionality Marius Storm-Olsen
2009-02-01 20:59 ` [PATCH v2 1/4] Add log.mailmap as configurational option for mailmap location Marius Storm-Olsen
2009-02-01 20:59 ` [PATCH v2 2/4] Add find_insert_index, insert_at_index and clear_func functions to string_list Marius Storm-Olsen
2009-02-01 20:59 ` [PATCH v2 3/4] Add map_user() and clear_mailmap() to mailmap Marius Storm-Olsen
2009-02-01 20:59 ` [PATCH v2 4/4] Change current mailmap usage to do matching on both name and email of author/committer Marius Storm-Olsen
2009-02-02 3:03 ` [PATCH v2 2/4] Add find_insert_index, insert_at_index and clear_func functions to string_list Junio C Hamano
2009-02-02 7:49 ` Marius Storm-Olsen
2009-02-02 3:01 ` [PATCH v2 1/4] Add log.mailmap as configurational option for mailmap location Junio C Hamano
2009-02-02 7:48 ` Marius Storm-Olsen
2009-02-02 7:56 ` Junio C Hamano
2009-02-02 8:26 ` Marius Storm-Olsen [this message]
2009-02-02 8:40 ` Junio C Hamano
2009-02-02 3:03 ` [PATCH v2 0/4] Extend mailmap functionality Junio C Hamano
2009-02-02 5:26 ` Sverre Rabbelier
2009-02-02 8:07 ` Marius Storm-Olsen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4986AE47.3010305@trolltech.com \
--to=marius@trolltech.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).