Robert Dailey <rcdailey.li...@gmail.com> writes:
> Sometimes I run into a situation where I need to find out which
> release of the product a submodule change was introduced in. This is
> nontrivial, since there are no tags in the submodule itself.
Does your superproject rewind the commit in the submodule project as
it goes forward? That is, is this property guaranteed to hold by
your project's discipline:
Given any two commits C1 and C2 in the superproject, and the
commit in the submodule bound to C1's and C2's tree (call
them S1 and S2, respectively), if C1 is an ancestor of C2,
then S1 is the same as S2 or an ancestor of S2.
If so, I think you can do a bisection of the history in the
superproject. Pick an old commit in the superproject that binds an
old commit from the submodule that does not have the change and call
it "good". Similarly pick a new one in the superproject that binds
a newer commit from the submodule that does have the change, and
call it "bad". Then do
$ git bisect start $bad $good -- $path_to_submodule
which would suggest you to test commits that change what commit is
bound at the submodule's path.
When testing each of these commits, you would see if the commit
bound at the submodule's path has the change or not.
$ current=$(git rev-parse HEAD:$path_to_submodule)
would give you the object name of that commit, and then
$ git -C $path_to_submodule merge-base --is-ancestor $change $current
would tell you if the $change you are interested in is already
contained in that $current commit. Then you say "git bisect good"
if $current is too old to contain the $change, and "git bisect bad"
if $current is sufficiently new and contains the $change, to
continue.
If your superproject rewinds the commit in the submodule as it goes
forward, e.g. an older commit in the superproject used submodule
commit from day X, but somebody who made yesterday's commit in the
superproject realized that that submodule commit was broken and used
an older commit in the submodule from day (X-1), then you cannot
bisect. In such a case, I think you would essentially need to check
all superproject commits that changed the commit bound at the
submodule's path.
$ git rev-list $bad..$good -- $path_to_submodule
would give a list of such commits, and you would do the "merge-base"
check for all them to see which ones have and do not have the
$change (replace "HEAD" with the commit you are testing in the
computation that gives you $current).
