Use of a mailmap file with git-log

Hi

I'm working on a project for a large organisation that wants to make widespread use of git and the mailmap feature.

This seems to be supported by default in git-shortlog but not git-log (and other variants) without specifying custom formats, which isn't really something I want to try and 'fix' across the organisation. Is there a reason for this feature omission or has it just evolved that way and could it be fixed?

Thanks Rich

Rich Midwinter <rich.midwinter@gmail.com> writes:

I think it was pretty much the latter, but people may already be depending on the command to give them the "true as recorded back then" names in the output. A fix may have to involve inventing a new option "log --use-mailmap" that is explicitly given from the command line.

Junio C Hamano <gitster@pobox.com> writes:

If somebody wants to do this, I think the overall design should go like this:

 * We may want to rewrite blame.c::get_ac_line() and the code in
   pretty.c::pp_user_info() that parse author/committer lines by
   using ident.c::split_ident_line() for better code reuse as a
   preparation step before all of the below.

 * We may want to lift the buffer length limit from the implementation
   of mailmap.c::map_user() by using the strbuf API as a preparation
   step before all of the below.

 * We may also want to rethink its signature (we may want to get a
   single strbuf and have the function parse out "Name <mail>"; I
   didn't check the existing callers to see if that would make it
   easier to use, and if it does not, this obviously shouldn't be done)
   as a preparation step before all of the below.

 * Introduce a new "struct string_list *mailmap" member to "struct
   pretty_print_context" and "struct rev_info" (default to NULL);

 * In log-tree.c::show_log(), copy opt->mailmap to ctx.mailmap;

 * Update pretty.c::pp_user_info() to convert the email address on
   "line" (between the beginning and "namelen") by calling
   map_user() immediately after it parses time/tz out, and adjust
   the remainder of the function to use it, when pp->mailmap is
   present;

 * Teach log.c::cmd_log_init_finosh() about "--use-mailmap" option.
   Allocate one "struct string_list" instance and use read_mailmap()
   on it when the option is used, and store it in rev->mailmap.

Hi,

I was thinking about that last week. It could indeed be very interesting to have mailmap applied to git-log and especially to git-log --author/--committer.

My first look at the code let me think that we would need to change the parse_commit_buffer to replace, at reading time, the name of author and committer if an option (--use-mailmap seems like a wise choice) and probably a config option. The choice of parse_commit_buffer to do the modification is due to the grepping being done directly on buffer when grepping author/committerer.

Yet I'm afraid it could be:
1. expensive to rewrite all commit log (reallocating the buffer)
2. Inappropriate to change the value in function that is supposed to
read

My 2 cents.

Cheers,

On Mon, Dec 10, 2012 at 7:48 PM, Junio C Hamano <gitster@pobox.com> wrote:

Antoine Pelisse <apelisse@gmail.com> writes:

In my suggestion I avoided rewriting the log buffer, primarily because of #2 (in addition to "read" cleanliness, such a change may break the gpg signature checking for merges).

We do reencode the contents before we write it out when "encoding" is present, so logically such a rewrite of authors and committers belongs to where that happens, in pretty_print_commit(). Note that this existing rewrite is not done to the commit log buffer but is to a separate buffer meant to be used only for output.

Antoine Pelisse <apelisse@gmail.com> writes:

For pattern matching, I think revision.c::commit_match() is probably the right place to do this kind of thing. I just noticed that we grep for the string inside a raw buffer, even when "encoding" is specified, which I think is a bug.