Re: possible bug: inconsistent CLI behaviour for empty user.name

From: Jeff King <peff@peff.net>
Date: Feb 23, 2017, 08:11 UTC
Message-ID: <20170223081157.hwfn3msfux5udmng@sigill.intra.peff.net>
In-Reply-To: <20170203051309.a737846dd26a6ed8df1e4112@gmx.de>

On Fri, Feb 03, 2017 at 05:13:09AM +0100, bs.x.ttp@recursor.net wrote:

Show 5 quoted lines

> The problem is that GIT accepts a user.name of " " for some operations
> (for example when doing a simple "git commit"), but does require a
> "non-empty" user.name for others (like git commit --amend and git
> rebase). In case of the latter commands GIT fails with the message
> "fatal: empty ident name (for <email@address>) not allowed".

I think it's a bug. We try to always reject empty usernames, but the "empty" check is done before we cut off leading and trailing cruft (like whitespace).

The "--amend" command notices because it actually parses the name out of the existing commit. That version has already had its whitespace eaten up (when it was written into the original commit), and so it ends up as blank.

Here's a series which fixes that along with a few other oddities I noticed.

  [1/4]: ident: mark error messages for translation
  [2/4]: ident: handle NULL email when complaining of empty name
  [3/4]: ident: reject all-crud ident name
  [4/4]: ident: do not ignore empty config name/email

 ident.c                       | 49 ++++++++++++++++++++++++++-----------------
 t/t7518-ident-corner-cases.sh | 36 +++++++++++++++++++++++++++++++
 2 files changed, 66 insertions(+), 19 deletions(-)
 create mode 100755 t/t7518-ident-corner-cases.sh

-Peff