Hi, On Mon, Dec 02, 2013 at 03:55:36PM -0800, Nick Townsend wrote: > > On 29 Nov 2013, at 14:38, Heiko Voigt <hvoigt@xxxxxxxxxx> wrote: > > FYI, I already started to implement this lookup of submodule paths early > > this year[1] but have not found the time to proceed on that yet. I am > > planning to continue on that topic soonish. We need it to implement a > > correct recursive fetch with clone on-demand as a basis for the future > > recursive checkout. > > > > During the work on this I hit too many open questions. Thats why I am > > currently working on a complete plan[2] so we can discuss and define how > > this needs to be implemented. It is an asciidoc document which I will > > send out once I am finished with it. > > > > Cheers Heiko > > > > [1] http://article.gmane.org/gmane.comp.version-control.git/217020 > > [2] https://github.com/hvoigt/git/wiki/submodule-fetch-config > > It seems to me that the question that you are trying to solve is > more complex than the problem I faced in git-archive, where we have a > single commit of the top-level repository that we are chasing. > Perhaps we should split the work into two pieces: > > a. Identifying the complete submodule configuration for a single commit, and > b. the complexity of behaviour when fetching and cloning recursively (which > of course requires a.) You are right the latter (b) is a separate topic. So how about I extract the submodule config parsing part from the mentioned patch and you can then use that patch as a basis for your work? As far as I understand you only need to parse the .gitmodules file for one commit and then lookup the submodule names from paths right? That would simplify matters and we can postpone the caching of multiple commits for the time when I continue on b. > I’m very happy to work on the first, but the second seems to me to require more > understanding than I currently possess. In order to do this it would help to have a > place to discuss this. I see you have used the wiki of your fork of git on GitHub. > Is that the right place to solicit input? I only used that to collect all information into one place. I am not sure if thats actually necessary for the .gitmodules parsing you need. I think we should discuss everything related to the design and patches here on the list. If you have questions regarding my code I am also happy to answer that via private mail. 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