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

[Julian Ibarz <julian.ibarz@gmail.com>]

> Am 26.01.2011 20:10, schrieb Julian Ibarz:
>> On Wed, Jan 26, 2011 at 2:06 PM, Jens Lehmann <Jens.Lehmann@web.de> wrote:
>>> Am 26.01.2011 19:32, schrieb Julian Ibarz:
>>>> I am using git submodule in one of my professional projects and I am
>>>> facing an issue when I am using git bisect in one of the submodules.
>>>>
>>>> Basically I have a meta repository which I will call A and two
>>>> submodules B and C. Sometimes I use git bisect in B but it is
>>>> dependent on C so when I go back too much in the history of B, C needs
>>>> to change its version to a compatible one. Doing this manually is
>>>> really time consuming for me and I guess a lot of people have this
>>>> issue so I was a little bit surprise to not find easily anything on
>>>> the net that permits to do this automatically.
>>>
>>> What about bisecting in A (doing "git submodule update" after every
>>> step) to bisect to a smaller range of commits in B (which are then
>>> not dependent on your submodule C anymore and can be bisected inside
>>> B)? This of course assumes A properly records the dependencies
>>> between B and C.
>>
>> Yes but actually my real use case that made me write this mail was
>> more I have a feature done in an old branch and to try it I never to
>> revert back to this version. In this case, I have to find out the
>> corresponding good version in A and C. In this case I cannot start
>> like what you propose in A to find out the good version in B and C, I
>> already know the version I want in B.
>
> 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?

>>>> Is there anything existing to do that and I just didn't find it yet?
>>>> If not I think I might have an implementation idea I would like to try
>>>> out.
>>>
>>> The call to "git submodule update" after each bisect step in the
>>> superproject will be obsolete as soon as the recursive checkout
>>> I am currently working on is done, but that is not here yet.
>>
>> Can you be more detailed about your recursive checkout feature? Is it
>> what I proposed?
>
> I don't think so, that will just get rid of the extra call to "git
> submodule update" when bisecting in A.

Basically my feature would work like this:

in B:
git submodule checkout some_version

This will checkout B but also change A and C so that it is compatible
with some_version of B. Basically it will find the commit in A that
has the closest parent commit of some_version in B. When this is done
it just does git submodule udate on other submodules.

I see in gitk that there is a feature that has a common implementation
for what I want to do:

For every commits you can see Follows and Precedes which lists the
closest label before this release and after. What I need is the same
thing: instead of finding a closest labeled commit, I need to find a
closest commit referenced by A that precedes current HEAD of B. When
this is done I know which commit A has to be and then just have to
call git submodule update in A (update every other submodules except
for B).

Julian