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 jun...@cox.net 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.gb176...@google.com/

> 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

Reply via email to