On Tue, Jul 19, 2011 at 06:14:38AM +0200, Christian Couder wrote: > > But once you start replacing commits, you need to put in a > > reasonable value for the timestamp. So you may well be replacing a > > perfectly valid commit with one that has bogus, skewed information > > in the commit timestamp. > > Perhaps but with "git replace" you can choose to create new replace refs and > deprecate the old replace refs to fix this where you got it wrong. > > It would be easier to do that if "git replace" supported sub directories like > "refs/replace/clock-skew/ted-july-2011/", so you could manage the replace refs > more easily. I think all of the arguments I cut from your email are reasonable, but the crux of the issue comes down to this point. If you are interested in actually correcting the skew, then yes, replace refs are a good solution. But doing so is going to involve somebody looking at the commits and deciding which ones are wrong, and what they should be. And maybe that's a good thing to do for people who really care about cleaning history. But for something like "speed up revision traversal by assuming commit timestamps are roughly increasing", we want something very automated, and what is needs to say is much weaker (not "this is what this commit _should_ say", but rather "this commit might be right, but it is not a good point for cutting off a traversal"). So that's a much easier problem, and it's easy to do in an automated way. So I think while you could use replace refs to handle this issue, it is not always going to be the right solution, and there is room for something simpler (and weaker). -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