On Fri, May 04, 2007 at 03:52:15PM -0700, Junio C Hamano wrote:
quoted text
> 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 ?

quoted text
> 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.

quoted text
>  (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?

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