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

From: Julian Ibarz <julian.ibarz@gmail.com>
Date: Jan 30, 2011, 09:44 UTC
Message-ID: <AANLkTimBCeSnR270eWMcrgCVj6rmiRkJizOxQPAPOAnn@mail.gmail.com>
In-Reply-To: <20110129110807.GA21864@book.hvoigt.net>

Today I have started to implement a proof of concept in C (I know a script would be better but I am really not good in sh so...). I struggle with the manipulation of the git API. I have pushed my work here:

http://gitorious.org/julian_ibarz_git/julian_ibarz_git

in branch submodule_checkout

My work is in:

builtin/submodulecheckout.c

And my questions are prepended by the keyword QUESTION (two questions for now only).

Any help is welcome.

Thanks,

Julian Ibarz

On Sat, Jan 29, 2011 at 6:08 AM, Heiko Voigt <hvoigt@hvoigt.net> wrote:

Show 49 quoted lines

> Hi,
>
> On Wed, Jan 26, 2011 at 02:05:43PM -0800, Junio C Hamano wrote:
>> 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.
>>
> [...]
>>
>> 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.
>
> Lets extend your explanation a little further and maybe demonstrate the problem
> Julian is having a little more. I think what Julian searches for is a tool in
> git that does the lookup for you which is AFAIK not that easy currently. It
> seems to be a quite useful feature. Here what I understand Julian wants:
>
> 1. Find the most recent superproject commit X'' in A that records a submodule
>   commit X' in B which contains the commit X in B you are searching for.
>
>   For this we would need use something similar to git describe --contains
>   but instead of using the list of existing tags in B it should use the list
>   of commits in B which are recorded in A.
>
>   Here a drawing to explain (linear history for simplicity):
>
>   superproject A:
>
>      O---O---X''---O
>               \
>   submodule B: \
>                 \
>      O---X---O---X'---O---O
>
> 2. Look up the commit of C which is recorded in X'' of A and check it
>   out.
>
> Step 2 is easy but for Step 1 the lookup of X' is missing for the commandline.
> Is there already anything that implements git describe --contains for a defined
> list of commits instead of refs?
>
> Cheers Heiko
>