Re: Git commit generation numbers

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Jul 15, 2011, 18:58 UTC
Message-ID: <CA+55aFzeN9jdzU1RBVZ6UDGUT0YvNkzpycKG_mT-z+dt_3GnMw@mail.gmail.com>
In-Reply-To: <CA+8MBbJNZdkpOhA5Kke0VqUA9qCFdzfEP5cWPTMF3eUfDsGRiQ@mail.gmail.com>

On Fri, Jul 15, 2011 at 11:46 AM, Tony Luck <tony.luck@intel.com> wrote:

Show 5 quoted lines

>
> What if my clock is wrong in the opposite direction - set to some time
> out in 2025.
> It would pass the check you propose and let the commit go in - but would
> cause problems for everyone if that tree was pulled into upstream.

I think Shawn suggested that we just notice it at merge time.

But yes, it's why (a) I'd suggest we have a "-f" to override and (b) I do think that generation counts are a better idea. You could still screw them up, but it would be due to an outright bug or malicious behavior, rather than simple incompetence on the part of a user.

Incompetent users (where "date on the machine set to the wrong century" is just _one_ sign of incompetence) are something git should pretty much take for granted. It may not be the common case, but it's certainly something we should design for and take into account.

In contrast, if somebody *wants* to screw his repository up by re-writing objects with "git hash-object" etc, be my guest. We should just make sure fsck catches anything serious.

So I would suggest checking the date regardless of any generation count issues, because it would possibly find badly configured machines that should be fixed. The same way we complain when we find no name.

Whether it should then be a correctness issue or not is kind of separate.

> You'd also want a check in pull(merge) that none of the commits being
> added were in the future (as defined by the time on your machine).

I don't think you need to care about "none of the commits", just making sure the tip is reasonable. That would not only be expensive, and not what we normally do (we show the diff against endpoints, not all changes, etc). It would also cause problems for "fixed" repositories (ie anything that has historical dates that are wrong, but are ok now).

                  Linus