Thread (1 message) 1 message, 1 author, 2016-06-15

Re: [PATCH] [submodule] Add depth to submodule update

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:57:55

Heiko Voigt [off-list ref] writes:
On Tue, Jun 25, 2013 at 12:49:25AM +0200, Fredrik Gustafsson wrote:
quoted
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 <redacted>
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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help