Re: jk/tag-contains (Re: What's cooking in git.git (Jul 2010, #05; Wed, 28))

Jonathan Nieder [off-list ref] writes:

Junio C Hamano wrote:

quoted

You need to be careful here, though.  What if you pulled from somebody
whose clock is set grossly in the future?

We could check for that and give relevant advice:

 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.

Be careful also: Git can hardly guess whether your clock is late, or
whether your co-worker's clock is in the future.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Matthieu Moy wrote:

Jonathan Nieder [off-list ref] writes:

quoted

 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.