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.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html