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