Heiko Voigt <hvo...@hvoigt.net> writes:
> 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 <iv...@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.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html