list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
From: Ariadne Conill <>
To: Jonathan Nieder <>
Cc: Jeff King <>,
	Johannes Schindelin <>,
	Junio C Hamano <>,,
	Git Mailing List <>,
Subject: Re: Git for Windows v2.23.0-rc0, was Re: [ANNOUNCE] Git v2.23.0-rc0
Date: Wed, 31 Jul 2019 19:37:55 -0500	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>


On Wed, Jul 31, 2019 at 7:21 PM Jonathan Nieder <> wrote:
> Jeff King wrote:
> > I think part of what my annoyance is responding to (and your willingness
> > to just squelch this for everybody) is that switching this particular
> > default isn't really that big a deal, that it requires annoying people
> > on every single "git log" invocation. Perhaps we would be better
> > squelching it entirely and just putting a mention in the release notes.
> Yes.
> Although as Dscho mentions, it's particularly irritating because it is
> not part of the paginated output.
> I wonder if the ideal might not be to trigger it more selectively, when
> the output actually changed due to a reflog entry.  I mean something
> like
>         commit 393a9dd0f9762c69f753a8fa0bc89c203c6b4e9e (HEAD, origin/foo, other/pu)
>         Merge: 18598e40e6 1eba6eb1c2
>         Author: A U Thor <> (see "git help mailmap")
>         Date:   Tue Jul 30 15:05:41 2019 -0700
>             Merge branch 'jt/fetch-cdn-offload' into foo
> The message
>         warning: log.mailmap is not set; its implicit value will change in an
>         upcoming release. To squelch this message and preserve current
>         behaviour, set the log.mailmap configuration value to false.
>         To squelch this message and adopt the new behaviour now, set the
>         log.mailmap configuration value to true.
> is *particularly* unactionable in the current state where we're not
> rewriting authors.  I think we should bite the bullet and just flip
> the default to "true", with the config as an escape hatch to allow
> going back to the old behavior.

This is what I originally proposed, but it was suggested that we
should go through the typical cycle for changing default behaviour in
Git, e.g. issue a warning and then flip the default in a later release
cycle (my plan was to do so in the next cycle, in fact).

> Is it too late in the release cycle to do that?  If not, we can do
> -- >8 --
> Subject: log: use mailmap by default in interactive use
> In f0596ecc8de9 (log: add warning for unspecified log.mailmap setting,
> 2019-07-15), we prepared for a future where "git log" uses the mailmap
> by default, using the following conditions:
>  1. If log.mailmap or --[no-]use-mailmap is set explicitly explicitly,
>     respect that.  Otherwise:
>  2. If output is not going to a terminal or pager, we might be in a
>     script.  Match historical behavior by not using the mailmap.
>     Otherwise:

For what it's worth, personally, I believe that it is best to just
always use the mailmap (even in scripts), because most likely if you
care about the author line, you're probably caring about the *present*
identity of the author who made the commit, because you wish to ask
them a question.  However, I decided that it would be best to be
conservative with the behaviour, for now, just in case somebody was
dependent on the historical author lines.

>  3. If the output format was specified using --pretty, we might be in
>     a script that produces output intended for copy/paste.  Match
>     historical behavior by not using the mailmap.  Otherwise:

This one is definitely intentional, as the user specified exactly what
they wanted.  So, we give them what they want -- if they want the raw
author lines, they get that, if they want the mapped version, then
they get that, because they explicitly asked for one or the other.

>  4. This is an interactive use, where we will be able to change the
>     default behavior.  Print a warning about the upcoming change
>     but don't use the mailmap yet.
> In practice, the case (4) turns out to be irritating.  It prints
> before pager setup, so it just flashes on the screen.  It appears on
> every "git log" invocation, even when the mailmap would not result in
> the output changing.  The change is not meaningful to most people, and
> the new default of --use-mailmap is likely to be preferable for all of
> them.
> Let's bite the bullet and jump straight to --use-mailmap in case (4).

Yes, I agree, the warning is suboptimal when used with a pager, but we
can only write to stderr, since writing to stdout may break scripts.
So, given the request of having a transitional period, I felt this was
the best we could do without breaking anything.

> While at it, add a new log.mailmap setting "auto" that can be used to
> explicitly request the new automatic behavior (so that e.g. if
> log.mailmap is set to "true" system-side, I can set it to "auto" in my
> per-user configuration).

This sounds like a great compromise, but honestly we should just flip
the default.  I can't think of any situation where the non-mapped
author lines wouldn't be the more preferable default.  If you want the
raw ones explicitly, you can just ask for them, either with
`--no-use-mailmap` or with `log.mailmap=false`.

> Reported-by: Johannes Schindelin <>
> Signed-off-by: Jonathan Nieder <>

At any rate... I don't have any major objections with going this route
as it solves the problem for the typical use-case, so...

Acked-by: Ariadne Conill <>


  reply	other threads:[~2019-08-01  0:44 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-29 21:49 Junio C Hamano
2019-07-31 12:43 ` Git for Windows v2.23.0-rc0, was " Johannes Schindelin
2019-07-31 23:18   ` Jeff King
2019-08-01  0:21     ` Jonathan Nieder
2019-08-01  0:37       ` Ariadne Conill [this message]
2019-08-01  1:00       ` Jeff King
2019-08-01  1:14         ` Jonathan Nieder
2019-08-01  1:38         ` Ariadne Conill
2019-08-01  2:53           ` Jeff King
2019-08-01  3:21         ` Junio C Hamano
2019-08-01  4:54           ` Ariadne Conill
2019-08-01 21:39             ` Johannes Schindelin
2019-08-01 15:45       ` Junio C Hamano
2019-08-01 16:12         ` Ariadne Conill
2019-08-01 21:36         ` Jeff King
2019-08-01 21:46           ` Junio C Hamano
2019-08-01 21:54             ` Junio C Hamano
2019-08-01 22:18               ` Todd Zullinger
2019-08-02  2:27         ` Jonathan Nieder
2019-08-02 16:53           ` Junio C Hamano
2019-08-02 18:35             ` Jeff King
2019-08-01  1:04   ` [git-for-windows] " Bryan Turner
2019-08-01 21:40     ` Johannes Schindelin
2019-08-01 14:12 ` [PATCH] RelNotes/2.23.0: fix a few typos and other minor issues Martin Ågren
2019-08-01 15:56   ` Junio C Hamano
2019-08-01 15:57   ` Junio C Hamano
2019-08-01 19:28     ` Martin Ågren

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='' \ \ \ \ \ \ \ \ \
    --subject='Re: Git for Windows v2.23.0-rc0, was Re: [ANNOUNCE] Git v2.23.0-rc0' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link list mirror (unofficial, one of many)

This inbox may be cloned and mirrored by anyone:

	git clone --mirror
	git clone --mirror http://ou63pmih66umazou.onion/git
	git clone --mirror http://czquwvybam4bgbro.onion/git
	git clone --mirror http://hjrcffqmbrq6wope.onion/git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 git git/ \
	public-inbox-index git

Example config snippet for mirrors.
Newsgroups are available over NNTP:
 note: .onion URLs require Tor:

code repositories for project(s) associated with this inbox:

AGPL code for this site: git clone