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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html