Re: jk/tag-contains

From: Jonathan Nieder <jrnieder@gmail.com>
Date: Aug 2, 2010, 20:19 UTC
Message-ID: <20100802201920.GE2180@burratino>
In-Reply-To: <vpqk4o8bwwd.fsf@bauges.imag.fr>

Matthieu Moy wrote:

> Jonathan Nieder <jrnieder@gmail.com> writes:

Show 8 quoted lines

>>  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.