On Sat, Oct 10, 2020 at 11:22 AM Christian Couder <christian.couder@xxxxxxxxx> wrote: > > On Fri, Oct 9, 2020 at 9:35 PM Manuel Bärenz <manuel@xxxxxxxxxxx> wrote: > > 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.
