Re: Feature request: Exponential search in git bisect

From: Christian Couder <christian.couder@gmail.com>
Date: Oct 10, 2020, 09:46 UTC
Message-ID: <CAP8UFD16WX-HE6TW2Q15a3us8UMaogPpR+0C8shiEdP3-Cba=Q@mail.gmail.com>
In-Reply-To: <CAP8UFD2dWrUXJUuiFtgCu6krbnbGGqJZ7K+6KqstGTcNmSc_xQ@mail.gmail.com>

On Sat, Oct 10, 2020 at 11:22 AM Christian Couder <christian.couder@gmail.com> wrote:

>
> On Fri, Oct 9, 2020 at 9:35 PM Manuel Bärenz <manuel@enigmage.de> wrote:

Show 13 quoted lines

> > That's problematic because then I might accidentally mark a
> > commit as good that was already untestable bad. Given that bisect has no
> > undo functionality, that can quickly mess up my search. Distinguishing
> > untestable good from untestable bad is really hard automatically. I
> > shouldn't have to do that.
>
> Sometimes it's not very difficult to test if the feature has been
> implemented yet or not. For example with Git you could check if an
> option for a command has been implemented by just checking if it
> appears in the doc. So the bisection script could first check that and
> exit 0 (which means good) if the option doesn't appear in the doc. If
> it appears in the doc, then it could do the regular test: "skip" if
> untestable, "good" if there is no bug, "bad" otherwise.

Also note that it might actually be simpler in many cases to find when a feature has been implemented by different means than some checks in the script.

For example in the above example to find using the documentation when an option for a Git command has been implemented, one could use:

git log --reverse  -S'--option' Documentation/git-command.txt

It could also work by using `git log --reverse -S...` to find when some functions or variables related to the feature appeared in the code itself.