From: Jonathan Nieder <jrnieder@gmail.com>
Date: Mon, 02 Aug 2010 20:19:20 GMT
Subject: Re: jk/tag-contains
Message-ID: <20100802201920.GE2180@burratino>
In-Reply-To: <vpqk4o8bwwd.fsf@bauges.imag.fr>

Matthieu Moy wrote:
> Jonathan Nieder <jrnieder@gmail.com> writes:

>>  fatal: committer date <date> precedes parent date <date>
>>  hint: It looks like you are trying to commit on top of a commit
>>  hint: from 5 years into the future.
>>  hint: Use "git rebase -f" to rewrite the commit with a more
>>  hint: sensible date, and please, fix your clocks!
>
> If the problem is the commit you've just pulled, I'd advise against
> re-writing it: it's published, it's too late.

I guess that is the fundamental question.  What do you do when a
completely bogus commit has been published?

(For example, fsck permits extra headers after the "encoding" header,
but a commit object using random such headers would be malformed and
noticeable as such as soon as fsck learns what header is supposed to
come after "encoding".)

I would like it to still be possible to publically acknowledge a
mistake, make people rewrite their history to remove it, and move on.
But another viable solution here would be to just warn about the
problem and maintain a list of bogus commits as Junio suggested.