I noticed recently that the GitHub contributions page for git.git did not seem very accurate. The problem is that while it uses shortlog, it does not respect .mailmap, because we do not have a working tree from which to read the .mailmap. This series adds a config option analogous to mailmap.file, but which reads from a blob in the repository (so the obvious thing to set it to is "HEAD:.mailmap" in a bare repo, and probably "master:.mailmap" if you frequently want to traverse while on unrelated branches). The obvious alternative is to checkout a temporary file of .mailmap and point mailmap.file at it, but this is a bit more convenient. A config option is perhaps not the most flexible way to access this. For example, one could in theory want to pull the mailmap from the tip of the history being traversed (e.g., because you have multiple unrelated DAGs in a single repo). But that could also produce the _wrong_ results, if you are looking at the shortlog of older history (e.g., when doing "git shortlog v1.5.0..v1.5.5", you would still want to be using the modern mailmap from "master"). By making it a config option, the simple, common case does the right thing, and people with complex cases can use "git -c mailmap.blob=..." to feed the appropriate map for the history they are traversing. If somebody wants to do something fancier (like --mailmap-from-tip or something), it would be easy to build on top later. [1/2]: mailmap: refactor mailmap parsing for non-file sources [2/2]: mailmap: support reading mailmap from blobs -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