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

From: Christian Couder <christian.couder@gmail.com>
Date: Jun 10, 2009, 08:14 UTC
Message-ID: <c07716ae0906100114n61ca5553k2f54918dd32afbb4@mail.gmail.com>
In-Reply-To: <4A2EB8E9.5040207@zytor.com>

On Tue, Jun 9, 2009 at 9:32 PM, H. Peter Anvin<hpa@zytor.com> wrote:

Show 11 quoted lines

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

By the way, if for example you have a project with 10% chance to land in a "stuck area" of the graph, then with my algorithm the chance to get stuck when you hit an untestable commit is 0.1^3 that is 0.1%. So in this kind of projects the chance that the first bad commit is near a lot untestable commits is much higher than that.

In fact I think that it's probably very hard to find a kind of project where the chance to get stuck when using my algorithm is not dwarfed by the chance of the first bad commit to be near or among many untestable commits.

Show 6 quoted lines

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

I think that what I said is just the opposite that. If you find shortcomings in the tools then you are welcome to ask us to fix them.

And if users find shortcomings in the cleanliness of the project graph, they should be welcome to ask the maintainers to provide them with ways to work around them, like for example a file that contains many commits and range of commits that should always be skipped and that can be used like for example:

$ git bisect start $ git bisect skip $(cat always_skipped_file) $ git bisect good ... $ git bisect bad ... ...

Or the maintainers can in turn ask git developers what's going on with "git replace" if they would prefer using that instead of such a file...

Show 10 quoted lines

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

I am not sure I understand you very well but as I said above I think with a "reasonably clean" graph the risk of the inexperienced user getting stuck because of my algorithm is very low compared to the risk of getting stuck because the first bad commit happens to be near many untestable ones.

Best regards, Christian.