Le Wednesday 10 June 2009, Junio C Hamano a écrit : > Christian Couder <christian.couder@xxxxxxxxx> writes: > > On Tue, Jun 9, 2009 at 10:37 PM, Junio C Hamano<gitster@xxxxxxxxx> wrote: > >> Christian Couder <christian.couder@xxxxxxxxx> writes: > >>> My opinion is that we should not penalize all the people working on > >>> "quite clean" projects and also people working on "not clean" > >>> projects who are able to recover, on the pretence that there are > >>> other people on these "not clean" projects who are not. > > > > ... > > When I wrote "clean", I just mean with not too many untestable commits. > > Ok, then the "opinion" in the above paragraph was simply stating the > obvious: we should have a good "bisect skip". I obviously agree with > that ;-). > > In other words, you were not arguing against my observation that your > algorithm would not be much better than randomly picking the next commit > when the best one is untestable, unless the history is linear. I think my algorithm is better enough than a random one to be worth using by default. Like HPA says it's in practice like a random one with a bias. That's because the "goodness" value is something that has a relationship with the graph topology. The "goodness" value is some kind of distance from either the good or the bad commits. The farther from the good and bad commits the higher is the "goodness" value. And my algorithm tries to avoid commits with low "goodness" value because they should be those near the good and bad commits and we know that those near the good and bad commits wont give a lot of information. > I guess > that was what I was confused with. I thought you were saying that we > should give preferential treatment to people with linear history. > > > Ok. I started working on optionaly using a PRNG but I am not sure that > > you will want to add another one. > > It may still make sense to replace, not add to, that "fixed alternating > distance in goodness space" with a randomized one, for the reasons HPA > stated, especially for avoiding to give a false impression that the magic > constants are picked for some reason. But there _is_ a reason. Best regards, 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