Re: Re: [PATCH 2/5] implement submodule config cache for lookup of submodule names

[Heiko Voigt <hvoigt@hvoigt.net>]

On Thu, Jun 05, 2014 at 10:46:10AM -0700, W. Trevor King wrote:
> On Thu, Jun 05, 2014 at 08:07:50AM +0200, Heiko Voigt wrote:
> > +The caller can look up information about submodules by using the
> > +`submodule_from_path()` or `submodule_from_name()` functions.
> 
> That's for an already-known submodule.  Do we need a way to list
> submodules (e.g. for 'submodule foreach' style operations) or is the
> preferred way to do that just walking the tree looking for gitlinks?
> The cases where .gitmodules would lead you astray (e.g. via sloppy
> commits after removing a submodule) are:
> 
> * Listing a submodule that wasn't in the tree anymore.  Easy to check
>   for and ignore.
> 
> * Not listing a submodule that is in the tree.  You'd need to walk the
>   tree to check for this, but it's a pretty broken situation already,
>   so I'd be fine just ignoring the orphaned gitlink.

Currently there is no need to list the submodules in a .gitmodule file.
We currently always begin from the gitlink and try to do things. If we
have enough information thats fine we go ahead, if not we stop (or
skip?) the submodule. So for already initialized submodules it is even
ok to not have a .gitmodules entry at all and we can still go ahead with
most operations. Here we should not be too picky, I think.

The only use-case I can think of is for checking whether .gitmodules
contains any extra unneeded values. But on the other hand that is not
so easy. Since .gitmodules are just config files they can contain user
defined values. That is ok.

So in summary: Yes the preferred way to list submodules is via iterating
the gitlinks and I do not think we need a way to iterate through the
.gitmodules file (at least not for the use-cases we currently need this
for).

Cheers Heiko