Re: RFC: Make git bisect submodule aware.

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, [off-list ref]
www.herland.net