From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: Simon <simonzack@gmail.com>, git@vger.kernel.org
Subject: Re: Git commit amend empty emails
Date: Wed, 10 Dec 2014 10:46:16 -0800 [thread overview]
Message-ID: <xmqqmw6vgx6v.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <20141210153952.GA14910@peff.net> (Jeff King's message of "Wed, 10 Dec 2014 10:39:53 -0500")
Jeff King <peff@peff.net> writes:
> However, there's something else going on. I am surprised that we allow
> empty emails at all and the code here is quite strange. The first check
> on the ident format is when we feed the data to fmt_ident to generate
> the string that goes into the commit object. We disallow empty _names_
> there, but not empty _emails_. I'm not sure if this is an oversight, or
> an intentional historic compatibility thing.
Looking at e27ddb6 you cited, I think we knew about historical
mistakes that allowed an empty names, but not an empty e-mail
address. We probably have tried to kill both in one stone.
> Once upon a time, it relied only on split_ident_lane to report problems.
> But Junio's e27ddb6 (split_ident_line(): make best effort when parsing
> author/committer line, 2012-08-31) made split_ident_line more lenient,
> and introduced sane_ident_split to cover the difference. Except that it
> did more than that: besides checking whether the name is empty (which
> the original split_ident_line used to do), it also complains if the
> email is empty (which is new in that commit).
> So we now notice the empty email in this code path, but the only thing
> we do is avoid writing out the environment variables and continue. Which
> means that the actual string generated by fmt_ident (complete with empty
> email) is what goes into the commit. So why are we setting the
> environment variables at all?
I think that part was more underthinking than oversight.
We didn't want to abort the commit but we didn't want to contaminate
the environment variables with known-to-be-bad values to spread the
problem further. But there is no guarantee that not exporting the
environment variables would give us more comformant name and e-mail
address, so that thinking is flawed.
> Here are two patches to improve this. These are on top of the
> jk/commit-date-approxidate topic, as that is where the regression was
> introduced.
>
> The first one fixes the regression and can stand by itself. The second
> fixes the GIT_AUTHOR problem, but AFAIK that has been there for years.
> So it is not as urgent, but is still maint-worthy, in my opinion.
>
> [1/2]: commit: loosen ident checks when generating template
> [2/2]: commit: always populate GIT_AUTHOR_* variables
>
> If we did want to truly disallow empty emails, we could do a follow-on
> 3/2 that teaches fmt_ident to reject them (that is the right place
> because it is where the validation checks for the author go, and also
> because we would probably want the same validation for the committer).
>
> But I do not think we should do that lightly. It has been this way for
> years, and clearly at least one person is depending on it. If we're
> going to change it, we might want a warning/deprecation period.
>
> -Peff
next prev parent reply other threads:[~2014-12-10 18:46 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-10 13:17 Git commit amend empty emails Simon
2014-12-10 15:39 ` Jeff King
2014-12-10 15:42 ` [PATCH 1/2] commit: loosen ident checks when generating template Jeff King
2014-12-11 20:26 ` Eric Sunshine
2014-12-10 15:43 ` [PATCH 2/2] commit: always populate GIT_AUTHOR_* variables Jeff King
2014-12-10 18:46 ` Junio C Hamano [this message]
2014-12-10 19:45 ` Git commit amend empty emails Jeff King
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqmw6vgx6v.fsf@gitster.dls.corp.google.com \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=peff@peff.net \
--cc=simonzack@gmail.com \
/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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.