On Wednesday 09 June 2010, Steven Michalske wrote: > When git bisect discovers that the change set that creates the > failure also contains a submodule change, that submodule should then > be bisected starting with the good super modules code and working to > a break in the sub module. If the change contains submodule change > and super code changes than the bisection gets trickier, so we need > some ideas on how to solve that search. > > Example: > > Super: A-B-C-D-E > Sub: s-s-y-y-z > > Where s is not required to be a parent of y, meaning that there > might be 300 commits or just 1 between s and y in the submodule or > they are disjoint then the bisecting should happen both routes into > the submodule. > > [...] My general feeling about this scenario is that 'git bisect' should not automatically descend into submodules and continue bisecting there. As you observe, there may be weird co-dependencies between the superproject and the submodule (or even between different submodules), so the safest default in this situation is for 'git bisect' to simply bail out. Then the user can at his/her leisure figure out if the best way to proceed is indeed a nested 'git bisect' in the submodule, and if so, which is the most appropriate version of the superproject (or other submodules) to use for this nested bisect. Trying to make Git too "clever" about these things is likely to come back and bite us in the ass. ...Johan -- Johan Herland, <johan@xxxxxxxxxxx> www.herland.net -- 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