Sven Verdoolaege <skimo@kotnet.org> writes:

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

 - Figuring out the name of the new directory we create (think
   "git clone git://repo.or.cz/git.git" -- it does "mkdir git &&
   cd git" for you before doing the other things).

 - Run "git init" there, obviously.

 - Probably run "git ls-remote" to figure out which branch HEAD
   should point at; you would definitely want to add a mechanism
   to pass the ls-remote result to the "git fetch" you are going
   to call next, as it is the first thing "git fetch" usually
   does -- we would want to reuse it.

 - Recently suggested good addition is to have "--track $branch"
   option to "git clone" to point remotes/origin/HEAD to
   something other than what the remote's HEAD actually points
   at (the discussion was primarily between Carl Worth and
   Linus; see archive).

 - Run "git remote add origin" with the given URL to set up the
   standard "separate remotes" tracking structure.

 - Run "git fetch" for initial fetch ("git remote add -f" could
   do that as well).  You would probably need to pass --tags to
   this "git fetch" to mimick what "git clone" does today.

 - Run initial checkout if asked.

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?

Most likely yes but that is just my gut feeling -- I readily
admit I haven't thought it through.

-
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