Jeff King [off-list ref] writes:
On Sat, Jul 31, 2010 at 01:07:03AM -0500, Jonathan Nieder wrote:
quoted
quoted
The third one is where we start defaulting things to "assume no more
than 1 day of clock skew by default", which can cause incorrect answers
in the face of skew.
I think the default should be something that (just barely) works
correctly for linux-2.6.git.
I am tempted by that (and it is why I made the fourth patch to actually
calculate the worst skew). But my concern is that there are projects
with even worse skew. Maybe that is unfounded.
quoted
quoted
The fourth is just an illustrative patch for per-repo skew detection.
I have been hoping for a chance to look these over, time hasn’t come my
way yet.
Sorry, but I am right in the middle of phisically moving, so my weekend
and evening git time has been nil recently.
It just a git-skew program to calculate the skew, but doesn't do
anything fancy like detect-on-gc. However, it would be nice to have
somebody sanity check the algorithm. Looking at it again, I think it
might actually miss some skew if the skewed commit can be reached in
multiple ways.
quoted
Additional things to do (this is mostly a note to myself):
- refuse to commit with a timestamp long before any parent
Agreed.
You need to be careful here, though. What if you pulled from somebody
whose clock is set grossly in the future?
quoted
- check slop and warn about it in fsck (maybe your patch does this
already)
No, it doesn't, but it is something we should probably do.
I wonder if we can make fsck to notice a commit with a wrong timestamp
(i.e. older than some of its parents) and make a note of it (hopefully
they are miniscule minority)---then during the revision traversal when we
hit such a commit, we perhaps ignore its timestamp (pretending as if its
timestamp is one of its children or parent---I haven't thought about the
details, but the note fsck leaves can record what adjusted timestamp
should be used) to fix the issue?
Junio C Hamano wrote:
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!
I wonder if we can make fsck to notice a commit with a wrong timestamp
(i.e. older than some of its parents) and make a note of it (hopefully
they are miniscule minority)---then during the revision traversal when we
hit such a commit, we perhaps ignore its timestamp (pretending as if its
timestamp is one of its children or parent---I haven't thought about the
details, but the note fsck leaves can record what adjusted timestamp
should be used) to fix the issue?
Thanks --- at first glance, this idea would seem to allow much faster
revision limiting.
On Sun, Aug 01, 2010 at 09:04:23PM -0700, Junio C Hamano wrote:
Sorry, but I am right in the middle of phisically moving, so my weekend
and evening git time has been nil recently.
Didn't you just do that? ;P
quoted
quoted
Additional things to do (this is mostly a note to myself):
- refuse to commit with a timestamp long before any parent
Agreed.
You need to be careful here, though. What if you pulled from somebody
whose clock is set grossly in the future?
Reading the rest of this thread and thinking about it more, I think
warning is the best thing we can do. Because only the user is in a
position to know whether it is their clock or the previous commit that
is in error. And if it is the previous commit, then only the user knows
what the next logical step is: redo the commit, complain to somebody
else, or just ignore and continue.
I wonder if we can make fsck to notice a commit with a wrong timestamp
(i.e. older than some of its parents) and make a note of it (hopefully
they are miniscule minority)---then during the revision traversal when we
hit such a commit, we perhaps ignore its timestamp (pretending as if its
timestamp is one of its children or parent---I haven't thought about the
details, but the note fsck leaves can record what adjusted timestamp
should be used) to fix the issue?
That's basically a finer-grained version of what I implemented. Mine
finds the _worst_ skew for the whole graph, and never lets you optimize
a traversal cutoff more than that skew. So it is nicely bounded
space-wise, as it is always a single integer, but you waste effort on
the entire traversal because a couple of commits are skewed. Yours
optimizes perfectly, but needs O(skewed commits) storage. Which is
probably a better tradeoff when the number of skewed commits is tiny
(which is what we expect).
I think your technique would work, but with one note. You probably want
to pull the timestamp from the parent (pulling from the child makes no
sense to me, as there can be an infinite number of children), but you
need to process the parent first and pull from its _corrected_
timestamp. Because at least in the linux-2.6 case, there is a run of
skewed commits. So if you have something like:
A -- B -- C -- D
A, timestamp = 1000
B, timestamp = 900
C, timestamp = 950
D, timestamp = 1100
where obviously the timestamps are shortened to be readable, but are
meant to be seconds-since-epoch. You'd probably want to end up with:
A, timestamp = 1000
B, timestamp = 1001
C, timestamp = 1002
D, timestamp = 1100
which means recursing all the way to the root, and fixing timestamps as
you back out.
This seems like just a straight sha1->int mapping, which presumably one
could do using "git notes". Though I worry it could slow down traversal
for all of the lookup misses for non-skewed commits.
-Peff