This week I started the work on adding .mailmap options to ref-filter. I had been reading the patches that Siddharth Asthana sent in regards to adding .mailmap options to cat-file.

These patches are particularly interesting because of refactoring they do before the actual addition of .mailmap to cat-file. The refactoring is done so that we can grab the headers of commits (or tags) effectively and we also make the function that does it public so that it can be used elsewhere. The latter change is especially important, because that means that we can use this function in ref-filter too (although to grab only the headers and use .mailmap for them).

The function that does the above is apply_mailmap_to_header() and this can be called in a seperate function, local to ref-filter, which can be used to replace the headers with their appropriate .mailmap entries.

It would also be natural to expect that we are able to use .mailmap for trailers in a commit or a tag as well, since these are also a part of the commit or tag where we find names and emails.

Actually, in the same thread that the above patches were sent to, Christian brings up a nice use case where this might matter and suggests a possible starting point.

Coming to the design, I’m not really sure what to do here. There are two ways in which we can do things:

  • Follow cat-file and introduce a --[no-]use-mailmap to for-each-ref possibly.

  • Follow pretty and add new options to say atom like %(authorname). So something like %(authorname:mailmap).

The second way is more verbose and I kind of prefer the first one since we could do something like 

git for-each-ref --use-mailmap --format="%(authorname) %(authoremail)" refs/

The work on describe atom in ref-filter

The describe atom patches are currently in v3. I re-rolled with this version which largely simplified things in how describe atom was implemented in ref-fitler. For parsing the describe options, we just do 

const char **describe_args;

now.

I was worried about us erring in the right places because the implementation before this had not really taken care of it and it was kind of hard to err with that implementation.

Christian suggested that we split out the option parsing code from describe_atom_parser() so that we can err correctly. This was really good and this makes things easier to err whenever something goes wrong.

Hariom suggested that, instead of adding new functions to ref-filter, we should rather refactor the functions in pretty and make them public so that we are able to use them here without re-implementing them.

What else is cooking?

I didn’t take out any time to work on convert_format() (related to Hariom’s idea) this week, which is embarrasing at this point. Was a bit busy with college work, but I did make some progress on it though. Trying to figure out where it will fit into pretty_print_commit().

I experimented a bit with it by trying to call it in format_commit_one(), but that was a total failure.

I also attended Review Club this week which discussed the addition of %(decorate:<options>) placeholder in pretty. Except for the socializing part, I was pretty much silent and lurked in the background. I had a great time and it was pretty fun. Thanks Glen, Jonathan, Calvin and Jacob.

‘til next time,
Kousik