I’ve started actually implementing the mailmap options into ref-filter. Christian, Hariom and I have decided that we will go with options spelled out as, for example, 

git for-each-ref --format="%(authoremail:mailmap,trim)" refs/

so that we use mailmap by specifying “mailmap” in the options of the atom. Currently the goal is to only apply mailmap to the atoms authorname, authoremail and committername, committeremail and leave out the trailers (for now).

I started out with making --format="%(authoremail:mailmap)" and its friends work. The approach taken is as follows:

  • The function copy_email() grabs the email values of a given commit or tag buffer and modifies them according to the options given to the atom.

  • To add mailmap support, that is, to grab these values from .mailmap instead, we need to modify this buffer so that the buffer shows the mailmap equivalents.

  • We do this by checking if we have a mailmap arg in person_email_atom_parser() and if we have one, we modify the given buffer by calling apply_mailmap_to_header() on it.

  • This buffer is then modified according to the options given, that is nothing, trim or localpart.

A similar approach can also be taken to implement mailmap for the name of an author or committer (in which case copy_name() has to be changed).

I haven’t pushed the changes I made to implement mailmap to email because there are some minor things that need to be fixed.

$ git status describe-atom

According to the recent “What’s cooking” email, the describe atom patches are ready to be merged into next. A lot of cool discussions happened during the reviews.

Junio suggested the possiblity of having unit tests written for the functions match_atom_arg_value() and match_atom_bool_arg(). The people at Google have been working on adding a unit test suite to Git, written in C. Unit tests help in testing individual functions, which is obviously a great advantage. More info about the discussion around the adding unit tests to Git are these patches.

Junio said that these functions would be kind of an ideal candidate for something to run unit tests on as these functions when called can lead to so many condidtions and we don’t really get to fully to use them in order to test them. Also with unit tests, we have the added advantage of documentation as unit tests give a clear understanding of what a particular function needs to do.

Another thing that was discussed was to generalize the way we parse multiple options as we are beginning to see them more often in the code. Junio suggested that we do something similar to parse_config_key() in config.c in which case , we use this to parse config options like

section.(subsection.)?key

I learnt quite a bit from these reviews and the discussions around them.

The patches that are to be merged in next are in v4.

I’ve also made a bit of a progress on using ref-filter in pretty where I worked on changing convert_format(), which converts pretty placeholders to ref-filter atoms, to return the ref format instead of the the placeholder length, in hope that this can then be use to pass onto a ref-filter function to grab the necessary values instead of pretty doing all the work. Although pretty printing must be done by pretty.

‘til next time,
Kousik