RFC: Make git bisect submodule aware.

RFC: Make git bisect submodule aware.

[Steven Michalske]

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.

So the git bisect found that the offending commit is C

Now if the offending commit only changes 1 submodule than it is a  
normal bisect for the changed submodule.

If in commit C file foo.c changed and the submodule changed a bit more  
work is needed.

If foo.c is not dependent on a new feature from between s and y than  
we are good, otherwise I feel a bit of human intervention might be  
needed for marking a 'good' version in the submodule.  Otherwise we  
have to search for a 'good' starting point, a binary bisection  
probably won't help much but probably would not hurt, since you need a  
'good' commit to start the bisection from.

So for the not dependent on new feature/bugfix in the submodule.

B's foo.c and s -> good/bad?
B's foo.c and y -> good/bad?
C's foo.c and s -> good/bad?
C's foo.c and y -> good/bad?

have fun bisecting.....

It might be good to interactively ask, for this bisection will file  
foo.c have an affect?
If the file has an effect:
Ask if C's foo.c will work with range s..y, if not what is the  
expected range for operation, we know that we need version u of  
submodule to compile C's foo.c. Or we have to search (linear from s)  
to where we can work.
otherwise, just bisect the submodule.

Steve

Re: RFC: Make git bisect submodule aware.

[Johan Herland]

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@herland.net>
www.herland.net