On Tue, Jul 19, 2011 at 10:00 PM, Jeff King <peff@xxxxxxxx> wrote: > On Tue, Jul 19, 2011 at 06:14:38AM +0200, Christian Couder wrote: > >> 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. I think that we can help the user a lot to find the skew, and then to decide which commits are wrong, and then to fix the skew even if the fix we suggest is far from being perfect. > And maybe that's a good thing to do for people who really > care about cleaning history. Yeah, so maybe at one point we will want to help these people even if we have implemented automatic generation numbers. Then this means that automated generation numbers are useful only if: 1) there are commits with skews 2) the heuristics to deal with some skew don't work 3) the user is too lazy to use the help we (can) provide to fix the skews I think that we can probably find heuristics that will deal with at least 95% of the cases. For example we could perhaps decide that we don't cut off a traversal until the date difference is greater than 5 days. Then in the hopefully few cases where there are really big skews that won't be caught by our heuristics, (but that we can automatically detect when fetching or commiting,) we can perhaps afford to ask the user to do a small analysis to properly fix the skew. I mean that at one point when things are too weird it is ok and perhaps even a good thing to involve the user. > 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. Yeah, generation numbers look like an easy thing to do. And yeah, being automated is great too. But it does not mean it is the right thing to do. (Or perhaps we could have them but not save them in any cache, nor in the commit object.) > 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). You know, replace refs can be used to fix or improve a lot of things like bad authors, clock skews, bisecting on a fixed up history, working on a larger or smaller repository than the original, and so on. And of course for each of these problems you may find another solution tailored to the problem at hand that will seem simpler or easier. But in the end if you develop all these other solutions you will have developed a lot of stuff that will be harder to maintain, less generic, more complex and so on, that properly developed replace refs. Thanks, Christian. -- 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