On Thu, Aug 01, 2019 at 08:45:54AM -0700, Junio C Hamano wrote: > While I think "revert to hardcoded default" may be a good idea, I do > not think the hardcoded default you implemented that changes the > behaviour based on the output destination makes much sense. If I > want to eradicate junkio@xxxxxxx from my paged/interactive output, I > want to eradicate it also in the output piped to the script I use > for authorship stats. > > I suspect that you may have misread the "is interactive" bit in the > original; that was used only to decide if we are going to warn. Yeah, I wondered about the same misreading when I read the response in: https://public-inbox.org/git/20190801011448.GB176307@xxxxxxxxxx/ > Anyway, how about this much simplified version? Yes, this is what I was thinking of in my earlier responses, but... > @@ -214,12 +204,8 @@ static void cmd_log_init_finish(int argc, const char **argv, const char *prefix, > memset(&w, 0, sizeof(w)); > userformat_find_requirements(NULL, &w); > > - if (mailmap < 0) { > - if (session_is_interactive() && !rev->pretty_given) > - warning("%s\n", _(warn_unspecified_mailmap_msg)); > - > + if (mailmap < 0) > mailmap = 0; > - } This should be "mailmap = 1" to match the commit message, no? (Which also implies we may want a new test). I'd also be OK with leaving it at "0" for now, making a note of the upcoming change in the release notes, and flipping it _next_ time. But IMHO we don't need to be that conservative (and I share your pessimism that enough people actually read the release notes to merit that kind of advance notice). -Peff
