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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html