Re: [PATCH] [submodule] Add depth to submodule update
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Jun 26, 2013, 16:16 UTC
- Message-ID
- <7vli5wyhi7.fsf@alter.siamese.dyndns.org>
- In-Reply-To
- <20130625221132.GB4161@sandbox-ub>
Heiko Voigt <hvoigt@hvoigt.net> writes:
Show 12 quoted lines
> 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 <iveqy@iveqy.com> > > 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.
I could imagine why people would not want to truncate the history when they "submodule update" a submodule that has been already initialized and cloned long time ago, but the new option is ignored in the patch for an already cloned module, so that is not a problem.
The only possible confusion factor I can see is that the option is ignored silently, but I do not think it is a grave enough offence to error out when the user says "git submodule update --depth=N $path" for a submodule at $path that has already been cloned. It may not even deserve a wraning, so in that sense the patch may be fine as-is.
> 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.
True.
Thanks.