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

Julian Ibarz [off-list ref] writes:

On Wed, Jan 26, 2011 at 3:41 PM, Junio C Hamano [off-list ref] wrote:

quoted

Julian Ibarz [off-list ref] writes:

quoted

quoted

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.