On Fri, Mar 3, 2017 at 12:04 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > 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). Hi Junio, my apologies for the very late response. I really like your idea, however unfortunately often times people on my team accidentally rewind the submodule. However your latter suggestion about just doing merge-base on each change would be a worthy solution to try. Thank you very much, I will certainly give this a try!!