git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Marius Storm-Olsen <marius@trolltech.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH v2 0/4] Extend mailmap functionality
Date: Sun, 01 Feb 2009 19:03:26 -0800	[thread overview]
Message-ID: <7vpri1o801.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: cover.1233520945.git.marius@trolltech.com

Marius Storm-Olsen <marius@trolltech.com> writes:

> 2) Lets you replace both name and email of an author/committer, based
> on a name and/or email. So, should you have done commits with faulty
> address, or if an old email simply isn't valid anymore, you can add
> a mapping for that to replace it. So, the old style mapping is
>     Proper Name <commit@email.xx>
>
> while this patch series adds support for
>     Proper Name <proper@email.xx> <commit@email.xx>
>     Proper Name <proper@email.xx> Commit Name <commit@email.xx>
>
> This extended mapping is necessary when a company wants to have their
> repositories open to the public, but needs to protect the identities
> of the developers. It enables you to only show nicks and standardized
> emails, like 'Dev123 <bugs@company.xx>' in the public repo, but by
> using an private mailmap file, map the name back to
> 'John Doe <john.doe@company.xx>' inside the company.

I do not find the "necessary" argument very convincing nor I find the
particular use case sane.  You may want to do things that way, but I do
not know if it is the best way to go about it.

The new mapping however brings in more flexibility, and there may be other
use cases where people benefit from that flexibility.  I am slightly in
favor than neutral to this new feature.

  parent reply	other threads:[~2009-02-02  3:04 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
2009-02-02  8:40           ` Junio C Hamano
2009-02-02  3:03 ` Junio C Hamano [this message]
2009-02-02  5:26   ` [PATCH v2 0/4] Extend mailmap functionality 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=7vpri1o801.fsf@gitster.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=marius@trolltech.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).