Fredrik Gustafsson <> writes:

> On Wed, Jun 26, 2013 at 12:11:32AM +0200, Heiko Voigt wrote:
>> On Tue, Jun 25, 2013 at 12:49:25AM +0200, Fredrik Gustafsson wrote:
>> > Used only when a clone is initialized. This is useful when the submodule(s)
>> > are huge and you're not really interested in anything but the latest 
>> > commit.
>> > 
>> > Signed-off-by: Fredrik Gustafsson <>
>> I this is a valid use case. But this option only makes sense when a
>> submodule is newly cloned so I am not sure whether submodule update is
>> the correct place. Let me think about this a little more. Since we do
>> not have any extra command that initiates the clone this is probably the
>> only place we can put this option. But at the moment it does not feel
>> completely right.
>> Apart from that the code looks good. If the user does a checkout of a
>> revision that was not fetched submodule update will error out the same
>> way as if someone forgot to push his submodule changes. So that should
>> not be a problem.
> I agree and would love to say that I've a more beautiful solution, but
> I haven't.
> The only other solution I can think about is to add a git
> submodule clone that will do only clones of non-cloned submodules.

The "update" subcommand already has "--init" to do "init && update",
and it would not complain if a given submodule is what you already
have shown interest in, so in that sense, I do not think what the
posted patch does is too bad---if it is already cloned, it just
ignores the depth altogether and makes sure the repository is there.
A separate "submodule clone" would only make it more cumbersome to
use, I suspect.

So let's queue the patch posted as-is for now; we can replace it
when/if somebody smarter than those who have spoken so far comes up
a more elegant approach.

The patch seems to lack any test on its own, by the way.

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to