Re: Finding a tag that introduced a submodule change

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