On Mon, Dec 02, 2013 at 03:55:36PM -0800, Nick Townsend wrote:
> On 29 Nov 2013, at 14:38, Heiko Voigt <hvo...@hvoigt.net> 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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to