fsck objects and timestamp ordering

fsck objects and timestamp ordering

[Jon Smirl]

When running fsck objects, does it verify that timestamps are ordered
in the same order as the dependency chains?

I am having trouble with a CVS repository where the timestamp ordering
and dependency order are in conflict. It would be best if git didn't
experience the same problem.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: fsck objects and timestamp ordering

[Shawn Pearce]

Jon Smirl <jonsmirl@gmail.com> wrote:
> When running fsck objects, does it verify that timestamps are ordered
> in the same order as the dependency chains?

No and it can't.  Clock skew between systems could be several
minutes to several hours which means you may have earlier commits
building onto later commits.

The better place to check this (although we don't today) is in
git-commit-tree.  If the new commit's committer timestamp is older
than any of its parent's committer timestamps git-commit-tree
should probably at least issue a warning that there's a possible
timestamp problem on either this system or the system that created
one of those parent commits.

If the committer has a problem with that timestamp issue they could
address it and ammend the commit before the error propagates.
 
> I am having trouble with a CVS repository where the timestamp ordering
> and dependency order are in conflict. It would be best if git didn't
> experience the same problem.

It would be best if Git didn't experience a lot of the weird stuff
people were able to do to their CVS repositories.  Fortunately the
friendly folks on this mailing list have put the better part of a
year and a half into doing just that.  :)

-- 
Shawn.

Re: fsck objects and timestamp ordering

[Shawn Pearce]

Shawn Pearce <spearce@spearce.org> wrote:
> Jon Smirl <jonsmirl@gmail.com> wrote:
> > I am having trouble with a CVS repository where the timestamp ordering
> > and dependency order are in conflict. It would be best if git didn't
> > experience the same problem.
> 
> It would be best if Git didn't experience a lot of the weird stuff
> people were able to do to their CVS repositories.  Fortunately the
> friendly folks on this mailing list have put the better part of a
> year and a half into doing just that.  :)

Wow, on reread that last sentance seems to imply that the fine
people who have contributed to Git have spent the past year and a
half making sure Git has plenty of weird stuff contained within it.
Which is not what I meant at all.  :)

My brain's just not working today (some sort of head cold thing
going on).  Its probably best that I stay away from anything that
requires any sort of logic...  such as English.

-- 
Shawn.

Re: fsck objects and timestamp ordering

[Linus Torvalds]

On Mon, 25 Sep 2006, Jon Smirl wrote:
>
> When running fsck objects, does it verify that timestamps are ordered
> in the same order as the dependency chains?

No. In fact, it's perfectly normal that they aren't.

Two machines with different timestamps will think time is different, and 
then one side doing a merge may have it's parents "in the future" from 
itself.

You can't even solve it sanely: you can't change the other sides 
time-stamps after the fact, and correcting the _merge_ timestamp to be 
later than both parents is a fix worse than the problem, since it would 
tend to just perpetuate a buggy timestamp further down the line.

So this is very fundamental. The first rule of distributed computing is: 
"There is no common time". Any distributed project that thinks such a 
thing exists is just fundamentally flawed, so I'd have been personally 
embarrassed by such a design decision.

So the only thing that matters is always the dependency chain. We've 
occasionally discussed having "sequence numbers" or other things to make 
it easier to decide on partial ordering between commits without having to 
actually follow the whole dependency chain, but times and dates is _never_ 
a valid thing to use for that.

> I am having trouble with a CVS repository where the timestamp ordering
> and dependency order are in conflict. It would be best if git didn't
> experience the same problem.

It's not really a problem. The timestamps don't "matter". The only thing 
git really cares about is the dependency order.

If commit timestamps aren't ordered, some of our programs may look at 
unnecessarily many commits because the heuristics use the (committer) 
timestamp as a way to guess which leg of a parenthood chain to take, but 
that's just a guess.

And the authorship timestamp is never used at all, except purely for 
output. So they show up in the log messages, but you can think of them as 
nothing more than the commit commentary. 

			Linus

Re: fsck objects and timestamp ordering

[Jon Smirl]

It might be worthwhile to print out a warning on commit if the commit
timestamp is earlier than the previous commit. That might weed out
some people with their clocks set wrong.


-- 
Jon Smirl
jonsmirl@gmail.com