# Use of a mailmap file with git-log 6 messages from 2012-12-10 to 2012-12-10. Participants: Rich Midwinter, Junio C Hamano, Antoine Pelisse. Thread: https://gitlist.dev/t/32307 ## Rich Midwinter, 2012-12-10 18:22 Subject: Use of a mailmap file with git-log Message-ID: URL: https://gitlist.dev/e/CALKB1SXdNVsQop5VYmShOMx93%2Bj5SPdkGF9yNU5k7nXg87TwMw%40mail.gmail.com ``` 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 ``` ## Junio C Hamano, 2012-12-10 18:48 Subject: Re: Use of a mailmap file with git-log Message-ID: <7v38zdbv6d.fsf@alter.siamese.dyndns.org> URL: https://gitlist.dev/e/7v38zdbv6d.fsf%40alter.siamese.dyndns.org In-Reply-To: ``` Rich Midwinter 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. ``` ## Junio C Hamano, 2012-12-10 19:43 Subject: Re: Use of a mailmap file with git-log Message-ID: <7vobi1ae26.fsf@alter.siamese.dyndns.org> URL: https://gitlist.dev/e/7vobi1ae26.fsf%40alter.siamese.dyndns.org In-Reply-To: <7v38zdbv6d.fsf@alter.siamese.dyndns.org> ``` Junio C Hamano writes: > Rich Midwinter 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 "; 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. ``` ## Antoine Pelisse, 2012-12-10 19:47 Subject: Re: Use of a mailmap file with git-log Message-ID: URL: https://gitlist.dev/e/CALWbr2ydMkR_O-Gev7k-HjGadRJMv0UH3XdqtM0Jt%3DvC82GwJw%40mail.gmail.com In-Reply-To: <7v38zdbv6d.fsf@alter.siamese.dyndns.org> ``` 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 wrote: > Rich Midwinter 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 ``` ## Junio C Hamano, 2012-12-10 20:05 Subject: Re: Use of a mailmap file with git-log Message-ID: <7vk3spad0k.fsf@alter.siamese.dyndns.org> URL: https://gitlist.dev/e/7vk3spad0k.fsf%40alter.siamese.dyndns.org In-Reply-To: ``` Antoine Pelisse 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. ``` ## Junio C Hamano, 2012-12-10 20:16 Subject: Re: Use of a mailmap file with git-log Message-ID: <7vfw3dacj5.fsf@alter.siamese.dyndns.org> URL: https://gitlist.dev/e/7vfw3dacj5.fsf%40alter.siamese.dyndns.org In-Reply-To: ``` Antoine Pelisse 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. ```