Re: git and time
- From
- Rogan Dawes <discard@dawes.za.net>
- Date
- Sep 28, 2006, 15:29 UTC
- Message-ID
- <451BEA60.9050306@dawes.za.net>
- In-Reply-To
- <20060928145027.26643.qmail@web51011.mail.yahoo.com>
Matthew L Foster wrote:
Show 19 quoted lines
> --- 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