Hi Ted, maximilian attems attems noticed that ‘git name-rev’ has trouble with some commits from the ext4 tree [1]. Jeff King investigated: Jeff King wrote: > On Thu, Apr 22, 2010 at 10:03:25AM -0500, Jonathan Nieder wrote: >> Jeff King wrote: >>> Still looking, but definitely some kind of skew problem. >> >> That explains it, then: >> >> $ git log --format=%cd' %h' 19f5fb7 ^v2.6.34-rc1~200 >> Sun Jan 24 14:34:07 2010 -0500 19f5fb7 >> Mon Dec 7 10:36:20 2009 -0500 d2eecb0 [...] > Thanks for confirming, that was the same stretch of history I ended up > looking at. It seems that the committer date is set to coincide with the author date for ext4 patches, which breaks some assumptions by git that each commit has a later or equal committer date than all parents (modulo some skew). How is the ext4 tree generated from your patch queue? Jonathan [1] http://thread.gmane.org/gmane.comp.version-control.git/145449 >> Is the rule that every commit must be at most one day before each of >> its parents? This should probably be documented somewhere, since it >> is possible to override the committer date with GIT_COMMITTER_DATE. > > There is no hard and fast rule. We have to deal with _some_ clock skew, > but I think it has been anybody's guess how much. One can always treat > the graph purely topologically (which is what my first patch removing > the cutoff_date check did), but that usually means more computation. In > this case, we go all the way to the roots instead of looking at a > "recent" subgraph. I think we also look at timestamps in rev-list when > linearizing to avoid doing a full topo-sort, but I don't remember what > effects clock skew can have there. > > So what should we do with this incident? > > 1. Declare it too much clock skew and ignore it. > > 2. Drop the cutoff optimization in favor of correctness. We already do > this for --stdin, as there is no sensible cutoff for multiple > inputs. So you can see how much slower it is: > > $ time git name-rev a1de02dccf906faba2ee2d99cac56799bda3b96a > a1de02dccf906faba2ee2d99cac56799bda3b96a undefined > > real 0m0.163s > user 0m0.140s > sys 0m0.020s > > $ time echo a1de02dccf906faba2ee2d99cac56799bda3b96a | > git name-rev --stdin > a1de02dccf906faba2ee2d99cac56799bda3b96a (tags/v2.6.34-rc1~199^2~35) > > real 0m3.411s > user 0m3.244s > sys 0m0.164s > > So perhaps it is something one would want to enable with a > command-line option. Or even something we could fall back on > automatically as a "slow case" when coming up with an un-nameable > rev. > > 3. Bump the slop date. 60 days would work here. What's reasonable? A > year? At one year, we are still noticeably slower: > > # patched for CUTOFF_SLOP_DATE (365*86400) > $ time git name-rev a1de02dccf906faba2ee2d99cac56799bda3b96a > a1de02dccf906faba2ee2d99cac56799bda3b96a > tags/v2.6.34-rc1~199^2~35 > > real 0m1.075s > user 0m1.028s > sys 0m0.044s > > -Peff -- 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