Re: Finding a tag that introduced a submodule change
- Date: Wed, 15 Mar 2017 09:12:55 -0500
- From: Robert Dailey <rcdailey.lists@xxxxxxxxx>
- Subject: Re: Finding a tag that introduced a submodule change
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
> 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!!