1. 15
  1. 1

    In my opinion this should not be included into git, because it is much better/easier implemented using external tools and the use case/algorithm is too narrow.

    Python for example has a good package for interfacing with git. You can checkout commits, but also get the contents of individual files (which would make parallel execution possible). In the Python ecosystem you also have access to the full range of scientific tooling, which makes it easy to implement other search algorithms.

    1. 3

      What’s the rationale for making it external? Bisect by itself is plenty powerful for most purposes it will need to, and this just adds another use-case for it.

      1. 1

        Mainly feature bloat. Every line of code needs to be maintained. Therefore in my opinion it is better to have good interfaces (which git has) than having one tool which can do everything. Its close to the GNU philosophy: “Make each program do one thing well. […]. Expect the output of every program to become the input to another, as yet unknown, program.“ Also in my opinion languages other than C are better suited for such task.