Robert Dailey <rcdailey.lists@xxxxxxxxx> 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).