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. >> >> I think it's the projects maintainers' responsibility to keep their >> projects graphs quite clean (and they have the right to ask git >> developers for the tools to do that). > > You seem to be saying that a completely linear history is the only one > that is clean. I was thinking about projects that use test suites to make sure new commits don't break a lot of things. But I should have said "to keep their projects graph quite clean or to provide specific information about how to work around potential problems when bisecting." > In an earlier message, I illustrated a case where two people independently > worked on unrelated topic and ended up merging their branches together, to > illustrate why your "not adjacent in goodness space" algorithm does not > give "away from untestable ones in topology space". > > With your definition, that history is _not_ clean. I do not think any > project wnats that kind of cleanness in their history. You just made the > word "clean" to describe the history meaningless. When I wrote "clean", I just mean with not too many untestable commits. > My take on the issue you mentioned above is that we should not penalize > the codepath's simplicity too much, only to cater to pathological > behaviour exhibited on an uninteresting special case of competely linear > history. I tried to make a short yet efficient implementation, not to favor a special case. > Your algorithm is Ok as an initial cut, in that it is an improvement over > the "next in goodness space, not even bother to avoid the pathological > case" algorithm. But I do not think it is much better than HPA's "try the > best one if it is not skipped, otherwise pick one randomly", and if we > wanted to do better and to claim that we pick ones that are _away_ from > untestable ones, we do need to take topology into account. That is all I > am saying. Ok. I started working on optionaly using a PRNG but I am not sure that you will want to add another one. 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