Git silently ignores --date when data is not in the correct format

Hi,

on 1.7.3.3, I have noticed that git --commit silently ignores the 
--date=<date> switch if <date> is not in the current format.

for instance

git --commit --amend --date="10.11.2010" creates a commit with the current
date and time, because the --date argument misses the time.

possibly, it would be better to stop with an error message.

On Mon, Dec 13, 2010 at 03:20:07PM +0000, Sergio wrote:

on 1.7.3.3, I have noticed that git --commit silently ignores the 
--date=<date> switch if <date> is not in the current format.

for instance

git --commit --amend --date="10.11.2010" creates a commit with the current
date and time, because the --date argument misses the time.

possibly, it would be better to stop with an error message.

Yeah, we should definitely be flagging the error. This patch fixes it,
but I'm not sure if it is optimal (see below).

-- >8 --
Subject: [PATCH/RFC] ident: die on bogus date format

If the user gives "git commit --date=foobar", we silently
ignore the --date flag. We should note the error.

This patch puts the fix at the lowest level of fmt_ident,
which means it also handles GIT_AUTHOR_DATE=foobar, as well.

There are two down-sides to this approach:

  1. Technically this breaks somebody doing something like
     "git commit --date=now", which happened to work because
     bogus data is the same as "now". Though we do
     explicitly handle the empty string, so anybody passing
     an empty variable through the environment will still
     work.

     If the error is too much, perhaps it can be downgraded
     to a warning?

  2. The error checking happens _after_ the commit message
     is written, which can be annoying to the user. We can
     put explicit checks closer to the beginning of
     git-commit, but that feels a little hack-ish; suddenly
     git-commit has to care about how fmt_ident works. Maybe
     we could simply call fmt_ident earlier?

Signed-off-by: Jeff King <redacted>
---
 ident.c           |    6 ++++--
 t/t7501-commit.sh |    4 ++++
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/ident.c b/ident.c
index 9e24388..1c4adb0 100644
--- a/ident.c
+++ b/ident.c

@@ -217,8 +217,10 @@ const char *fmt_ident(const char *name, const char *email,
 	}
 
 	strcpy(date, git_default_date);
-	if (!name_addr_only && date_str)
-		parse_date(date_str, date, sizeof(date));
+	if (!name_addr_only && date_str && date_str[0]) {
+		if (parse_date(date_str, date, sizeof(date)) < 0)
+			die("invalid date format: %s", date_str);
+	}
 
 	i = copy(buffer, sizeof(buffer), 0, name);
 	i = add_raw(buffer, sizeof(buffer), i, " <");

diff --git a/t/t7501-commit.sh b/t/t7501-commit.sh
index 8297cb4..8980738 100755
--- a/t/t7501-commit.sh
+++ b/t/t7501-commit.sh

@@ -230,6 +230,10 @@ test_expect_success 'amend commit to fix date' '
 
 '
 
+test_expect_success 'commit complains about bogus date' '
+	test_must_fail git commit --amend --date=10.11.2010
+'
+
 test_expect_success 'sign off (1)' '
 
 	echo 1 >positive &&

-- 
1.7.3.3.784.gccc31.dirty

Thanks for looking (and coding) into it!

For my usage case, a warning would be ok too. If the commit generates a warning,
one can notice the warning and --amend the commit.

One can perhaps have the warning now and maybe an
error from version 1.8, so: (i) we are sure that the different behavior does not 
break anything and
(ii) there is time to move the fmt_ident up in the code so that it is invoked 
earlier
(to avoid the burden of writing the commit message and then seeing the commit 
aborted).

By the way, note that I got into the issue by trying to use --date forgetting 
the time.
Don't know if it could make sense to accept the date with some default time in 
this case.

Regards

Sergio