On Sun, Aug 25, 2013 at 10:27:52PM -0700, Junio C Hamano wrote: > > I'm on the fence. It doesn't actually save that many lines of code, and > > I guess it's possible that somebody would want a custom mailmap in the > > future. Even though you can't do it right now, all it would take is > > exposing read_mailmap_file and read_mailmap_blob outside of mailmap.c. > > Of course, it would be easy to expose map_user_from at the same time. > > I am of two minds on this, but if I were forced to pick one _today_, > I would have to say that I am moderately negative to the approach. > > Having to always specify that you want to use mailmap and make sure > you read it is a bit cumbersome from callers' point of view, and > using a singleton global may be one attractive way to do so. It is also slightly wasteful, in that we may parse and store the mailmap multiple times. But I doubt it's a big deal. > I think it is a reasonable tentative solution to hook a singleton > instance to something that is commonly used, e.g. the rev_info > structure, for large subset of commands that do use the structure > chosen to host that singleton instance, but those that do not work > based on revision traversal (e.g. "grep") need to also honor mailmap > consistently, so we must keep the lower level API that takes an > explicit mailmap instance for them anyway. My patch kept the lower-level API (well, it de-publicized it because nobody was using it, but we do not need to do that part). But as I said, I am on the fence, and you do not seem enthused, so let's just drop it. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html