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

[Heiko Voigt <hvoigt@hvoigt.net>]

Hi Julian,

interesting work so far.

One thing regarding the mailing list: Please do not top post and try to cut non
relevant text (the one you are not replying to) from your replies.

On Wed, Feb 02, 2011 at 11:31:40PM -0500, Julian Ibarz wrote:
> 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.

Sounds great. That will be one tool you need. Here is a small script
snippet which already does that as an example for the msysgit repository
(git://repo.or.cz/msysgit.git):

export sub=git
git log --pretty="%h" -- $sub | \
    while read i; do git ls-tree $i -- $sub; done | \
        cut -f3 -d" " | cut -f1

It outputs all the hashes that have been registered for the git
submodule. Maybe thats a good starting point to find example code in C.
You can use it for other submodules also just change the name in the variable
sub.

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

Have a look at the codepath that is used for

  git branch --contains <sha1>

It essentially does the thing you want (find all refs that contain a
commit). An approach could be to extend this mechanism not to iterate
through all refs but e.g. take a list of sha1's for iteration.

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

Please see the tips above.

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

There are a few points I would like to mention:

 * Citing my drawing:
> >>   superproject A:
> >>
> >>      O---O---X''---O
> >>               \
> >>   submodule B: \
> >>                 \
> >>      O---X---O---X'---O---O

   There can be multiple X' which contain X. These are all valid
   candidates. The same applies to X'' where there can be multiple
   candidates that record a specific X'. IMO, all of them need to be
   considered. If in the end they all reduce to one commit in submodule C
   you can check that out. If not printing a list of all candidates is
   probably the best option.

 * If we want your code to go upstream it probably needs to be
   integrated as a subcommand into the current submodule script. I can
   offer to help you on the bash scripting side. I think once the tools
   to find the appropriate commits are ready that will not be a big
   issue.

 * I think for protoyping the tools you can later use in the submodule
   script its fine to implement your own command. Keep in mind that you
   later on you should probably integrate your code into the appropriate
   existing commands. Here some suggestions.

   To support proper bash scripting two parts come into my mind:

   1. A tool to output all of the submodules commits which are
      candidates for X'' like the script snippet above.

   2. A tool that takes the list from 1. and then reduces that list to
      a list of commits that actually register the possible commits X'.
      If that is one commit X'' we can directly checkout. If not we
      print the list in a nice format and let the user choose.

Looking forward to your work.

Cheers Heiko