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

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 26, 2011, 22:05 UTC
Message-ID: <7v1v3zjp6w.fsf@alter.siamese.dyndns.org>
In-Reply-To: <AANLkTik8VrhbBSLwRq9gd39hofnmifk15zSqXVTsSzAp@mail.gmail.com>

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

Show 23 quoted lines

> 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.