Use of a mailmap file with git-log

Use of a mailmap file with git-log

[Rich Midwinter]

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

Re: Use of a mailmap file with git-log

[Junio C Hamano]

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

> 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?

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.

Re: Use of a mailmap file with git-log

[Junio C Hamano]

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

> Rich Midwinter <rich.midwinter@gmail.com> writes:
>
>> 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?
>
> 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.

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.

Re: Use of a mailmap file with git-log

[Antoine Pelisse]

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:
> Rich Midwinter <rich.midwinter@gmail.com> writes:
>
>> 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?
>
> 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.
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Use of a mailmap file with git-log

[Junio C Hamano]

Antoine Pelisse <apelisse@gmail.com> writes:

> 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

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.

Re: Use of a mailmap file with git-log

[Junio C Hamano]

Antoine Pelisse <apelisse@gmail.com> writes:

> It could indeed be very interesting to have mailmap applied to git-log and
> especially to git-log --author/--committer.
> ...
> The choice of parse_commit_buffer to do the modification is due to
> the grepping being done directly on buffer when grepping author/committerer.

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.