Re: Updating a submodule with a compatible version from another submodule version using the parent meta-repository

[Junio C Hamano <gitster@pobox.com>]

Julian Ibarz <julian.ibarz@gmail.com> writes:

> On Wed, Jan 26, 2011 at 3:41 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> Julian Ibarz <julian.ibarz@gmail.com> writes:
>>
>>>> Hmm, looks like I lost you here ... you want to bisect in B although
>>>> you know what commit you want there? Care to explain a bit more?
>>>
>>> In B I have a feature to integrate in master branch. This feature is
>>> in branch old_feature. But this branch is really old. To try this
>>> feature I need to rebuild it at this version. To make the build
>>> success I need also to revert back the submodule C because B is
>>> dependent on it. But finding the good version of C that match
>>> old_feature version is a pain... Is it clear?
>>
>> That sounds like bisecting in C with a frozen checkout of B to see which
>> version in C works well with that target commit in B you know you want to
>> use.  Why do you need to bisect in B???
>
> Forget about bisect. This is a different use case where I need the
> feature I am talking about: checkout an old version in B and
> automatically having A and C switch to a compatible version (the cause
> can be because of a bisect or just because I want to try an old
> feature not yet integrated into master or whatever the reason I want
> to be on this old version).

If that version of submodule B is explicitly bound to a commit in the
superproject A, you know which version of A and C were recorded, and the
problem is solved.

But otherwise, you are wishing for a miracle, I am afraid, without giving
your tool (git or your own tool you write on top of it) some hint to say
how "similar" commits in B are, as there is no guarantee that anybody even
tried a commit that is not directly referenced from the superproject
together with other parts of the system.

If you are confident that you didn't introduce different kind of
dependency to other submodules while developing your "old_feature" branch
in submodule B, one strategy may be to find an ancestor, preferrably the
fork point, of your "old_feature" branch that is bound to the superproject
A.  Then at that point at least you know whoever made that commit in A
tested the combination of what was recorded in that commit, together with
the version of B and C, and you can go forward from there, replaying the
changes you made to the "old_feature" branch in submodule B.