Hi Peff, On Mon, 12 Nov 2012, Jeff King wrote: > On Tue, Nov 13, 2012 at 01:16:01AM +0000, Johannes Schindelin wrote: > > > > We can do much better than O(number of commits), though, if we stop > > > traversing down a path when its timestamp shows that it is too old to > > > contain the commits we are searching for. The problem is that the > > > timestamps cannot always be trusted, because they are generated on > > > machines with wrong clocks, or by buggy software. This could be solved > > > by calculating and caching a "generation" number, but last time it was > > > discussed there was a lot of arguing and nothing got done. > > > > Sadly, not only machines with skewed clocks, but in particular buggy > > 3rd-party SCMs make this more than just problematic. In a git-svn clone > > that was used as base for heavy Git development, I encountered quite a lot > > of Jan 1, 1970 commits. > > Yeah. We tolerate a certain amount of skew (24 hours for --name-rev, and > 5 broken commits in a row for --since). But the big ones are usually > software bugs (the big kernel ones were from broken "guilt", I think) or > broken imports (when I published a bunch of skew statistics last year, > the interesting ones were all imports; I don't know if they were > software bugs, or just garbage in, garbage out). > > > It just cannot be helped, we must distrust timestamps completely. > > Note that name-rev will produce wrong answers in the face of clock skew. > And I think that you even wrote that code. :) IIRC the cute code to short-circuit using the date is not from me. If it is, I am very ashamed. Ciao, Johannes -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html