Re: [PATCH v3 0/3] automatically skip away from broken commits

[Junio C Hamano <gitster@pobox.com>]

Christian Couder <christian.couder@gmail.com> 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.