Re: Corrupted (?) commit 6e6db85e confusing gitk

From: Brian Downing <bdowning@lavos.net>
Date: Dec 2, 2007, 19:39 UTC
Message-ID: <20071202193918.GQ6212@lavos.net>
In-Reply-To: <7vir3hx70y.fsf@gitster.siamese.dyndns.org>

On Sun, Dec 02, 2007 at 10:53:33AM -0800, Junio C Hamano wrote:

Show 6 quoted lines

> Yeah, I was wondering what that commit that records the change older
> than git or myself come to life ;-)
> 
> I did rewrite the commit a few times, and it was some interaction
> between the built-in commit series, git-rebase -i and git-am, but I do
> not have the details, sorry.

It looks like the "guilty" commit that allowed this behavior was:

commit 13208572fbe8838fd8835548d7502202d1f7b21d
Author: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Date:   Sun Nov 11 17:35:58 2007 +0000

    builtin-commit: fix --signoff

    The Signed-off-by: line contained a spurious timestamp.  The reason was
    a call to git_committer_info(1), which automatically added the
    timestamp.

    Instead, fmt_ident() was taught to interpret an empty string for the
    date (as opposed to NULL, which still triggers the default behavior)
    as "do not bother with the timestamp", and builtin-commit.c uses it.

    Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>

With the above, something like:

echo msg | GIT_AUTHOR_DATE='' git commit-tree sha1

will produce a broken commit without a timestamp, since fmt_ident is also used for the committer and author lines.

Personally, I think if the date_str is not NULL, it should die() on anything that can't successfully be parsed as a date, rather than simply falling back to the current time. But maybe that's a bit extreme.

-bcd