Re: [RFC] Third round of support for cloning submodules

On Sun, May 20, 2007 at 12:10:04PM -0700, Junio C Hamano wrote:

quoted

bash-3.00$ ./git-config --remote=http://www.liacs.nl/~sverdool/isa.git --get-regexp 'submodule\..*\.url' 
submodule.cloog.url /home/sverdool/public_html/cloog.git
submodule.cloog.url http://www.liacs.nl/~sverdool/cloog.git

You are priming the process by having these configuration
variables in the superproject to be cloned (i.e. this is done by
the owner of the superproject).

Is that a question?
The answer would be that if the user didn't put this information
in a config file, then git will try to get the information from
any remote it can get its hands on.

What's the design like to make clone and checkout work together?
When you run the first clone with -n ("do not checkout"), what
should happen (I am not asking what your code does, but what the
desired behaviour should be)?  My take on that question is
"subproject cloning is done by checkout, not clone".

Then I guess you are not asking me.
I took the suggestion of doing the subproject cloning during checkout
from you.

I am very worried about this big red switch that says "all
subprojects to be cloned and checked out, or nothing".  I think
this would not work well with projects that truly need
superproject support (i.e. very large ones, where most people
would not want to clone and check out every single subproject).

It's pretty easy to add a "submodule.*.skip" or "submodule.*.ignore".
Since the subcloning only happens at checkout, you could set these
before doing a checkout.

quoted

I currently do not fetch after the initial clone, since
I'm not sure what ref to use for the revision I need to
fetch for the supermodule.

I think fetching inside the subproject can be safely done with
the default (i.e. refs/heads/*:refs/remotes/origin/*) of 1.5.0
or later, as long as we tell the users of the feature that they
should make sure that the commit referenced by superproject tree
entries are available with such a fetch, which is a sane thing
to require anyway.

Seems like a pretty strict requirement, but it's easy to implement,
so I guess I can do that in the fourth version.

The more important issue I think is at what point in the
superproject operation does a recursive checkout in a subproject
should happen, and how we should do the checkout.  Issues I can
think of offhand are (no way exhaustive):

 - Do we checkout a branch? if so which one?

 - Do we detach HEAD if the commit named by the superproject
   tree is not at the tip of the current branch of subproject?
   do we detach always even if the commit is at the tip?

I thought there was a consensus to detach the HEAD.
I don't have a strong opinion on this issue, but a detached
HEAD seems the most appropriate to me.

 - What would we do when the subproject working tree is not
   clean?

I was planning on adding a --dry-run to git-checkout.
The superproject would run this in each subproject before
doing the actual checkout of the superproject.

 - How can a user decide which subproject to descend into and
   which subproject to ignore, and how does git remember the
   earlier decision made by the user without asking the same
   again, and how does a user express "now I want to also track
   that subproject I've ignored so far" and "now I am not
   interested in following that subproject anymore"?

Just twiddle the "submodule.*.skip" option.

So I tend to disagree with not having the indirection we
discussed on the other thread about .gitmodules, but I consider
it a minor detail of cloning, and it is not a major deal to me.

Some form of indirection is definitely required (although
not for my use of submodules) and I'll probably add it in a future round.

skimo