Matthieu Moy wrote: > Jonathan Nieder <jrnieder@xxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html