The plumbing part looks very good, although I sensed a slight
slop toward the end (will comment on individual patches later).

I do not like the Porcelain part very much, though.  I do not
think we would want to add anything new to git-clone.  We should
lose as much code from git-clone that is common with git-fetch
as we can first, and add new features to git-fetch, with
possibly passthru options added to git-clone as needed (e.g. a
new --submodule option).

If you --submodule cloned a remote repository when it had two
submodules, and then later the remote adds another submodule,
you would need to have a way to fetch that can discover the
presense of the new submodule and add it for you, and at that
point, having the code that knows much about submodules in clone
would not help you much.

I suspect that a possible interaction between git-fetch and
git-clone would go like this:

 (1) "git-clone [--submodules]" would perform a normal clone,
     having most of its work done by git-remote and git-fetch;

 (2) when "--submodules" is given to "git-clone", it passes it
     through to underlying "git-fetch";

 (3) "git-fetch --submodules", after finishing what it would do
     without "--submodules" option, would inspect the fetched
     tree (or the index derived from it), find the tree entries
     with mode 160000 (i.e. submodule graft points), and _then_
     uses the pathnames of these tree entries to consult the
     config mechanism to see which URL(s) can be used to
     retrieve them, probably only for new submodules.  Your new
     "config --remote" mechanism may be one good way to prime
     the configuration from the originating site.

We could probably extend the upload-pack protocol to send the
same information as you are using submodules.*.url for, instead
of adding a yet another protocol and program pairs you used for
"git config --remote".  Having a generic program and protocol to
dump the whole configuration file is certainly simpler, easier
to debug, and easier to repurpose, it makes me somewhat worried
about security implications (if it is open to http then worrying
about it is not very useful, though).

-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html