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

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

Hi,

After a couple of hours, I have finally succeeded to go through the
entire history of a repository and I can detect the submodules in a
tree of a commit. For those interested here is the source code:

http://gitorious.org/julian_ibarz_git/julian_ibarz_git/blobs/submodule_checkout/builtin/submodulecheckout.c

Next time I will build the list of commits of a submodule in the
entire history. Then I will need to find the distance of each commit
in the list compared to the current  commit of a submodule and keep
the closest one (which has to be a parent so an algebric distance
would be good to have).

So now my two questions that could save me some time are:
- is there a function that gives the distance between two commits? I'm
sure there is something like this coded somewhere but I didn't find it
yet
- is the struct decorate a hash map and if yes could someone explain
me how to use it or point me to a location where it is used?

Except from that I think I have all the information I need.

Best regards,
Julian Ibarz

On Sun, Jan 30, 2011 at 4:44 AM, Julian Ibarz <julian.ibarz@gmail.com> wrote:
> 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:
>> 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
>>
>