Marius Storm-Olsen <marius@xxxxxxxxxxxxx> writes: > Junio C Hamano said the following on 02.02.2009 08:56: >> Marius Storm-Olsen <marius@xxxxxxxxxxxxx> writes: >>> Junio C Hamano said the following on 02.02.2009 04:01: >>>> Should it always be a wholesale override, or should it also >>>> support augmenting the repository version with a private copy? >>> Sure, I can rewrite it to be augmenting, rather than overriding. I >>> assume that the normal .mailmap file should be parsed first, >>> then the log.mailmap one? >> >> Augmenting one would behave that way. I was more wondering if >> people would want to be able to choose either, perhaps from the >> command line option or something. > > Oh, I see. *ponder* maybe, though you could say that about any option > in the .git/config file, right? I was more thinking along the line of how .gitignore works, accumulating exclude patterns we find from .gitignore files along the way while descending into the directory hierarchy, and all the while honoring what the user added in .git/info/excludes. > I'm not sure of the use case of the command line option. In which case > would you want to only use the mailmap for that one command? It > doesn't normally affect your git commands, so it doesn't hurt to just > set the log.mailmap option. The environment use case would be just > like setting it in your ~/.gitconfig, other than you can have a > different one for each console, I guess. Yeah, that is exactly why I suggested you to say that is overengineered and is not useful ;-) > Now, if we extended the mailmap feature even further, to report the > mappings from the rev-list code ((optional of course)), so that any > log viewer would show the mapped information; _then_ I would consider > the command-line and environment variables as mandatory. Since, then > you might want the feature off by default, and only use the mappings > when you need to figure out a breakage, thus need a quick way to > enable it. Now you mention it, it might be wonderful if "git log --author" honored the mailmap file, but I do not think command line nor environment do not have much to do with it. In any case, it is an independent issue from how mailmap maching and rewriting should work, which was the main point fo your series. > So, unless anyone raises their hand that they need > command-line/environment ways of setting the mailmap file used, I'll > leave it as is for now. Ok? My point was that you should drop the second always-NULL parameter if the plan is not to have any command line filename. And I agree with your reasoning that a command line filename is not useful, so... -- 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
