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

Re: [PATCH v2 0/4] Extend mailmap functionality

From
Marius Storm-Olsen <marius@trolltech.com>
Date
Feb 2, 2009, 08:07 UTC
Message-ID
<4986A9CE.9040009@trolltech.com>
In-Reply-To
<7vpri1o801.fsf@gitster.siamese.dyndns.org>
Junio C Hamano said the following on 02.02.2009 04:03:
Show 10 quoted lines
>> 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.

Well, this is the use-case for my company. We have open-source repos, which are the exact same repos which the company's developers work on, not a modified mirror repo. However, laws in some countries requires that employees information be kept away from the public, should they so wish. So, for our developers to work on the exact same repo as the open-source community, we need a way to map both Names and Emails back to the original author, inside the company without using a different repo.

Also, the company commit policy might be such that the email on the commit is always the companys <bugs@company.xx>. This might be so that if someone finds a bug to your commit, they send the bug report to the companys bug-tracker instead of the individual email address. However, that breaks the old mailmap system, since it requires unique email addresses to map to a name.

> 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.
You could use this feature in git.git itself, where for example
     Junio C Hamano <gitster@pobox.com>
     Junio C Hamano <gitster@pobox.com> <junio@twinsun.com>
(or any of the others in the .mailmap file with X number of different 
email addresses), to ensure that you are always associated with one 
specific email address.
-- 
.marius [@trolltech.com]
'if you know what you're doing, it's not research'
Previous: Sverre Rabbelier
Message 15 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.