Christian Couder wrote: >>> >> Sort-of-kind-of. I doubt most users will be able to recover from a >> stuck situation, and unless we have extremely high cost of testing >> (which is true for some applications) then expecting the user to >> optimizing manually is really bad user design. > > 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). No, it's not. This is saying "it's the user's responsibility to make up for shortcomings in the tools", which is completely bass-ackwards. > If they don't do so, then their > users will suffer anyway. So it's not a big deal to ask them to teach > their users to add a "--prng" option to "git bisect start" for example > or something like that to try to work around the "not cleanliness" of > their graphs. Let's see... we can penalize the default user by 19% (the amount of difference) if and only if they have skip points (at which point your "project manager's responsibility" has already failed) or we can risk an inexperienced user getting stuck? -hpa -- 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