On Fri, May 04, 2007 at 03:52:15PM -0700, Junio C Hamano wrote: > 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). So what would you want to keep in git-clone ? > 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. True. > (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. Would git-fetch then call git-clone for these new submodules? > 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). We could easily have dump-config only dump a predefined "known safe" set of config options, although that would mean you have to upgrade the server side each time you add a new dumpable config option. Or we could do the preselection only when called from git-daemon. skimo - 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