On 29 Sep 2012, Darrell Anderson said:
But you
don't want to do this anyway: you want to use 'git bisect',
which is designed for this sort of binary-searching for bugs with
unknown origin. (Note that after every 'git bisect good/bad' you will
need to do a 'git submodule update' to bring the submodules up to date
properly.)
Thank you for the explanation.
Like 'git reset --hard', seems every explanation I read is focused on
a repo for a single product/package and not a multi-layered repo like
Trinity. As I mentioned in a previous mail, the Trinity repo is really
134 (or so) repos, or 134 products. Whereas I can easily 'git reset
--hard' or 'git bisect' an individual Trinity package/module, I can't
easily bisect the entire Trinity source tree. At least, I am not
seeing how to do this.
You can 'git bisect' the top-level repo, and 'git submodule update'
between each step -- but if there were multiple commits in a submodule which
were skipped over by the overarching module, 'git bisect' will not
descend into them. It doesn't really understand submodules.
--
NULL && (void)