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. 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. 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. 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. -- 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