The mailmap options have finally taken form and I have pushed the initial version to my fork with the branch name “mailmap0”. The approach used is as described in my previous post with some additional changes so that we now can also grab mailmap values for the name atoms (that is, %(authorname), %(committername) and %(taggername)).

The function that does this grabbing is change_to_mailmap_value(), which reads the mailmap and if an entry exists, grabs it and changes our buffer accordingly, giving us the mailmap version of the email or name or both.

The additional changes that I mention above are to the function find_wholine(). What this function does is that it finds the author, committer and tagger lines (if they exist) and strips off the who part of the first such occurrence and returns the refs/foo/bar buffer.

The changes were made so that we now return the whole buffer, because we need the who part of this buffer for mailmap purposes (code in mailmap wants this info). The subsequent code was also changed so that we do actually skip the who part where ever needed.

Christian took a look at the commits and left a few comments which were really helpful and which I agree should definitely go into the changed version of these commits. Those changes are

  • Instead of always returning the whole buffer from find_wholine(), we should rather add a flag so that we can control the skipping of the who part.
  • When handling the options of the email, we normally use an enum which has all the possible options with 0 to final_option - 1 indexing. Instead of this, we should rather use bit fields, which has a number of advantages and makes the code a lot cleaner and easy to err wherever we want (more info at this comment).

  • The current code only handles options in a specific order and errs if they are not in that order. For example,

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

    is fine, but

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

    errs. So the implementation needs to change a bit so that this is allowed too. Anyone using this option obviously expects this also to work.

There were also some other minor comments about refactoring things for more cleanness.

Apart from the mailmap options

For the last many posts, I have been saying that I am making progress on Hariom’s idea but I haven’t pushed anything because most of it gets stashed and then dropped. This especially happened in the last week because I shifted my focus a bit from mailmap and worked on this.

Every time I use gdb for some seg fault or some other error where the output for the code that I wrote is not what I expected, I learn something new about the command and how it calls the different functions and what serves as a pipe to what. This kind of changes things in the code that I already wrote and I’ve slowly began to realize that the code I wrote was wrong for many reasons and the reason mostly being that one should also keep in mind how the command runs and jumps from function to function TOP to BOTTOM and not BOTTOM to TOP. BOTTOM to TOP was the only view I had till now and this lead to writing code that would unnecessarily call private functions and when you compile such a thing, you obviously get an error and you try to somehow make the functions public but what you should be thinking about is how you should make use of the public functions so that they automatically handle the private functions themselves and give you what you need.

This seems kind of obvious now but I somehow didn’t realize it all this while.

‘til next time,
Kousik