From: Rogan Dawes <discard@dawes.za.net>
Date: Thu, 28 Sep 2006 15:29:36 GMT
Subject: Re: git and time
Message-ID: <451BEA60.9050306@dawes.za.net>
In-Reply-To: <20060928145027.26643.qmail@web51011.mail.yahoo.com>

Matthew L Foster wrote:
> --- Theodore Tso <tytso@mit.edu> wrote:
> 
>> In git, we believe that all repositories are equal, and that any sense
>> that a particular repository is the "master" or the "mainline" is
>> strictly speaking, a matter of convention.  What Matthew I think is
>> asking for is direct support in git for that notion.
> 
> No. I merely think git should try harder to ensure that commit order is consistent with time
> order, it really should (somehow) be impossible for git and gitweb.cgi to have commit dates ~2
> days in the future. I think replication is a separate issue. In a distributed system the only
> "time" that makes any sense or is the most relevant in many situations and most importantly is the
> only thing that can be semi-trusted is local time. "Creation date" is basically just random text
> someone entered, there is no guarantee and you are tempting inconsistent time order. And git
> shouldn't be so fragile as to need each and every git server to have time set semi-correctly, but
> I guess it's a bigger deal to non-developers as we actually use time and also believe even web
> interfaces should have consistency and integrity. 
> 
> -Matt
> 

See, the confusion here seems to be that you think that not caring about 
the time attached to a commit for anything more than a heuristic makes 
git fragile.

I think that the rest of the git developers prefer to see this as a 
feature that makes git more robust in the face of something that they 
might not have any control over (or desire to control).

That said, if *you* are managing a repository, it shouldn't be difficult 
to enforce the kind of rule that you are asking for. Simply implement a 
pre-commit hook that checks all commits that will be added to *your* 
repo to make sure that time is monotonically increasing from the last 
commit, and that it does not pass "now".

So if you receive a commit from a developer that violates this rule, you 
can send the commit back to them with a request to fix their system 
time, and recreate the patch/series.

I just don't think that any of the kernel developers feel the need to 
police any one else's clocks . . . they're more interested in the 
contents of the patch.

Regards,

Rogan