git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Ariadne Conill <ariadne@dereferenced.org>
To: Jeff King <peff@peff.net>
Cc: Jonathan Nieder <jrnieder@gmail.com>,
	Johannes Schindelin <Johannes.Schindelin@gmx.de>,
	Junio C Hamano <gitster@pobox.com>,
	git-for-windows@googlegroups.com,
	Git Mailing List <git@vger.kernel.org>,
	git-packagers@googlegroups.com
Subject: Re: Git for Windows v2.23.0-rc0, was Re: [ANNOUNCE] Git v2.23.0-rc0
Date: Wed, 31 Jul 2019 20:38:14 -0500	[thread overview]
Message-ID: <CAAOiGNwDV3LNGRVPQN6DgES6raG76u-rW0nBuw=i2oHTibVSPg@mail.gmail.com> (raw)
In-Reply-To: <20190801010022.GA6553@sigill.intra.peff.net>

Hello,

On Wed, Jul 31, 2019 at 8:00 PM Jeff King <peff@peff.net> wrote:
>
> On Wed, Jul 31, 2019 at 05:21:25PM -0700, Jonathan Nieder wrote:
>
> > 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 <author@example.com> (see "git help mailmap")
> >       Date:   Tue Jul 30 15:05:41 2019 -0700
> >
> >           Merge branch 'jt/fetch-cdn-offload' into foo
>
> I actually kind of like that, because it tells you exactly when it is
> impacting things (not just that the mailmap was used, but that this
> _particular_ name was mapped, which is going to be the most actionable
> thing). But I do think the syntax above might end up breaking somebody
> who's trying to parse it (people aren't supposed to be parsing log
> output, but...).
>
> Something like:
>
>   Author: A U Thor <author@example.com>
>   Original-Author: I M Mailmapped <orig@example.com>
>
> gives even more information while leaving the "Author:" line untouched.
> But in introducing a new line, it may also be breaking somebody.

It also makes this entire exercise completely moot because not only
does it deadname the contributor, it discloses that it is deadnaming
the contributor while also telling you who they are now, which is even
worse than the current behaviour.  The purpose of this exercise is to
ensure that users have the *current* contact information of the
contributor by default, including their current name and e-mail.  My
entire goal behind transitioning this config default is to ensure that
git respects *present* identity information by default, while giving
access to the raw identity data in cases where it makes sense to do so
(such as historical research or whatever).  I don't really wish for
git to remind me of my previous identity while browsing through
historical git logs.  I also don't think most people care about the
previous identity data of contributors -- in most cases, if you're
looking up a commit's author, you're doing so because you intend to
ask them a question about the commit, and so, having the most current
identity data available is what actually makes sense.

> I think all of these are riskier than just quietly engaging the mailmap.
> That's syntactically identical, so no risk of parsing regressions That's
> almost always going to be what people _actually_ want if there's a
> mailmap in the repo. The only exception is if they're somehow trying to
> do analysis on original versus mapped names. At which point they really
> ought to be using a parseable format like --pretty=raw, or "%an <%ae>".

Precisely, which is why I think we should just flip the default.
However, as previously mentioned, it was requested to do a formal
transition for the config setting, just to be absolutely sure that
people are aware the default was going to flip.

> > 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.
> >
> > Is it too late in the release cycle to do that?  If not, we can do
>
> IMHO no, it is not too late. This is a new feature in this release, and
> we're at -rc0. The point of the rc period is to find problems in the new
> code. So certainly I think it is not too late to change our minds about
> this feature. I could see an argument that instead of changing it now,
> we should revert for v2.23 and work on it with less urgency during the
> next cycle. But personally I'd see what a day or two of discussion turns
> up; if everybody agrees on the path forward and the implementation isn't
> complicated, it may be easiest to just proceed now.

Honestly, the current default is arguably an unintentional bug.  As
you note, it's a default that makes no sense and flipping it will give
people what they *actually* want.  Accordingly, I have thought, and
still think, that we're best off just flipping the default and saying
we fixed a bug, because the current behaviour is certainly perceived
by many people as being a bug -- in fact, when I first looked into
this, I thought it *was* a bug, only to find out that the default was
the way it was.  I'm certainly not alone in perceiving the current
behaviour as a bug, especially since `git shortlog` respects mailmap
by default and `git log` doesn't.

>
> > -- >8 --
> > Subject: log: use mailmap by default in interactive use
>
> This seems OK to me, though I kind of wonder if anybody really wants
> "auto". Unlike log.decorate, which changes the syntax, there is no real
> reason to avoid mailmap when somebody else is parsing the output. And I
> could imagine it is especially confusing if:
>
>   git log --author=whoever
>
> and
>
>   git log | grep whoever | wc -l
>
> do not agree.
>
> -Peff

  parent reply	other threads:[~2019-08-01  1:38 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-29 21:49 [ANNOUNCE] Git v2.23.0-rc0 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
2019-08-01  1:00       ` Jeff King
2019-08-01  1:14         ` Jonathan Nieder
2019-08-01  1:38         ` Ariadne Conill [this message]
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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

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

  git send-email \
    --in-reply-to='CAAOiGNwDV3LNGRVPQN6DgES6raG76u-rW0nBuw=i2oHTibVSPg@mail.gmail.com' \
    --to=ariadne@dereferenced.org \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git-for-windows@googlegroups.com \
    --cc=git-packagers@googlegroups.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jrnieder@gmail.com \
    --cc=peff@peff.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).