[RFC] [submodule] Add depth to submodule update

[RFC] [submodule] Add depth to submodule update

[Fredrik Gustafsson]

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>
---
 git-submodule.sh | 13 +++++++++++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/git-submodule.sh b/git-submodule.sh
index 79bfaac..b102fa8 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -211,12 +211,18 @@ module_clone()
 	name=$2
 	url=$3
 	reference="$4"
+	depth=$5
 	quiet=
 	if test -n "$GIT_QUIET"
 	then
 		quiet=-q
 	fi
 
+	if test -n "$depth"
+	then
+		depth="--depth=$depth"
+	fi
+
 	gitdir=
 	gitdir_base=
 	base_name=$(dirname "$name")
@@ -233,7 +239,7 @@ module_clone()
 		mkdir -p "$gitdir_base"
 		(
 			clear_local_git_env
-			git clone $quiet -n ${reference:+"$reference"} \
+			git clone $quiet $depth -n ${reference:+"$reference"} \
 				--separate-git-dir "$gitdir" "$url" "$sm_path"
 		) ||
 		die "$(eval_gettext "Clone of '\$url' into submodule path '\$sm_path' failed")"
@@ -676,6 +682,9 @@ cmd_update()
 		--checkout)
 			update="checkout"
 			;;
+		--depth)
+			depth=$2
+			;;
 		--)
 			shift
 			break
@@ -735,7 +744,7 @@ Maybe you want to use 'update --init'?")"
 
 		if ! test -d "$sm_path"/.git -o -f "$sm_path"/.git
 		then
-			module_clone "$sm_path" "$name" "$url" "$reference" || exit
+			module_clone "$sm_path" "$name" "$url" "$reference" "$depth" || exit
 			cloned_modules="$cloned_modules;$name"
 			subsha1=
 		else
-- 
1.8.0

[PATCH] [submodule] Add depth to submodule update

[Fredrik Gustafsson]

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>
---
 git-submodule.sh | 13 +++++++++++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/git-submodule.sh b/git-submodule.sh
index 79bfaac..b102fa8 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -211,12 +211,18 @@ module_clone()
 	name=$2
 	url=$3
 	reference="$4"
+	depth=$5
 	quiet=
 	if test -n "$GIT_QUIET"
 	then
 		quiet=-q
 	fi

+	if test -n "$depth"
+	then
+		depth="--depth=$depth"
+	fi
+
 	gitdir=
 	gitdir_base=
 	base_name=$(dirname "$name")
@@ -233,7 +239,7 @@ module_clone()
 		mkdir -p "$gitdir_base"
 		(
 			clear_local_git_env
-			git clone $quiet -n ${reference:+"$reference"} \
+			git clone $quiet $depth -n ${reference:+"$reference"} \
 				--separate-git-dir "$gitdir" "$url" "$sm_path"
 		) ||
 		die "$(eval_gettext "Clone of '\$url' into submodule path '\$sm_path' failed")"
@@ -676,6 +682,9 @@ cmd_update()
 		--checkout)
 			update="checkout"
 			;;
+		--depth)
+			depth=$2
+			;;
 		--)
 			shift
 			break
@@ -735,7 +744,7 @@ Maybe you want to use 'update --init'?")"

 		if ! test -d "$sm_path"/.git -o -f "$sm_path"/.git
 		then
-			module_clone "$sm_path" "$name" "$url" "$reference" || exit
+			module_clone "$sm_path" "$name" "$url" "$reference" "$depth" || exit
 			cloned_modules="$cloned_modules;$name"
 			subsha1=
 		else
--
1.8.0


-- 
Med vänliga hälsningar
Fredrik Gustafsson

tel: 0733-608274
e-post: iveqy@iveqy.com

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

[Junio C Hamano]

Summoning area experts ;-)

Thanks.

Fredrik Gustafsson <iveqy@iveqy.com> writes:

> 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>
> ---
>  git-submodule.sh | 13 +++++++++++--
>  1 file changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/git-submodule.sh b/git-submodule.sh
> index 79bfaac..b102fa8 100755
> --- a/git-submodule.sh
> +++ b/git-submodule.sh
> @@ -211,12 +211,18 @@ module_clone()
>  	name=$2
>  	url=$3
>  	reference="$4"
> +	depth=$5
>  	quiet=
>  	if test -n "$GIT_QUIET"
>  	then
>  		quiet=-q
>  	fi
>
> +	if test -n "$depth"
> +	then
> +		depth="--depth=$depth"
> +	fi
> +
>  	gitdir=
>  	gitdir_base=
>  	base_name=$(dirname "$name")
> @@ -233,7 +239,7 @@ module_clone()
>  		mkdir -p "$gitdir_base"
>  		(
>  			clear_local_git_env
> -			git clone $quiet -n ${reference:+"$reference"} \
> +			git clone $quiet $depth -n ${reference:+"$reference"} \
>  				--separate-git-dir "$gitdir" "$url" "$sm_path"
>  		) ||
>  		die "$(eval_gettext "Clone of '\$url' into submodule path '\$sm_path' failed")"
> @@ -676,6 +682,9 @@ cmd_update()
>  		--checkout)
>  			update="checkout"
>  			;;
> +		--depth)
> +			depth=$2
> +			;;
>  		--)
>  			shift
>  			break
> @@ -735,7 +744,7 @@ Maybe you want to use 'update --init'?")"
>
>  		if ! test -d "$sm_path"/.git -o -f "$sm_path"/.git
>  		then
> -			module_clone "$sm_path" "$name" "$url" "$reference" || exit
> +			module_clone "$sm_path" "$name" "$url" "$reference" "$depth" || exit
>  			cloned_modules="$cloned_modules;$name"
>  			subsha1=
>  		else
> --
> 1.8.0

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

[Heiko Voigt]

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.

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.

Cheers Heiko

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

[Fredrik Gustafsson]

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 <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.
> 
> 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.

I'm no UI expert so I don't know what's best. Maybe that's more
intuitive.

-- 
Med vänliga hälsningar
Fredrik Gustafsson

tel: 0733-608274
e-post: iveqy@iveqy.com

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

[Junio C Hamano]

Fredrik Gustafsson <iveqy@iveqy.com> 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 <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.
>> 
>> 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.

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

[Jens Lehmann]

Am 26.06.2013 23:03, schrieb Junio C Hamano:
> Fredrik Gustafsson <iveqy@iveqy.com> 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 <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.
>>>
>>> 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.

Yup, I see no need for a new command either.

Me too thinks adding "--depth" to "update" makes sense (and I don't
think that this pretty generic name will become a problem later in
case someone wants to add a maximum recursion depth, as grep already
uses "--max-depth" for the same purpose).

But "--depth" should also be added to the "submodule add" command.
As an example we already have the "--reference" option, which is
passed to clone on add and update. Additionally that one supports
the form with and without '=', so I'd prefer the new update option
to basically re-use the same code the reference option uses. And
at least two tests, of course ;-)

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

[Heiko Voigt]

On Thu, Jun 27, 2013 at 04:54:45PM +0200, Jens Lehmann wrote:
> Am 26.06.2013 23:03, schrieb Junio C Hamano:
> > Fredrik Gustafsson <iveqy@iveqy.com> 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 <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.
> >>>
> >>> 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.
> 
> Yup, I see no need for a new command either.

I agree there is no reason for that.

> Me too thinks adding "--depth" to "update" makes sense (and I don't
> think that this pretty generic name will become a problem later in
> case someone wants to add a maximum recursion depth, as grep already
> uses "--max-depth" for the same purpose).

Hmm, but does it have a --depth option for revisions? Maybe we should
call it --clone-depth or --rev-depth to make it clear? --depth and
--max-depth would be completely orthogonal but the name does not allow
to distinguish them properly.

> But "--depth" should also be added to the "submodule add" command.
> As an example we already have the "--reference" option, which is
> passed to clone on add and update. Additionally that one supports
> the form with and without '=', so I'd prefer the new update option
> to basically re-use the same code the reference option uses. And
> at least two tests, of course ;-)

And add documentation, please :-)

Cheers Heiko

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

[Junio C Hamano]

Heiko Voigt <hvoigt@hvoigt.net> writes:

> On Thu, Jun 27, 2013 at 04:54:45PM +0200, Jens Lehmann wrote:
> ...
>> Me too thinks adding "--depth" to "update" makes sense (and I don't
>> think that this pretty generic name will become a problem later in
>> case someone wants to add a maximum recursion depth, as grep already
>> uses "--max-depth" for the same purpose).
>
> Hmm, but does it have a --depth option for revisions? Maybe we should
> call it --clone-depth or --rev-depth to make it clear? --depth and
> --max-depth would be completely orthogonal but the name does not allow
> to distinguish them properly.

I do not have a strong opinion either way, but as you suggest, it
might be a good idea to call this new option --clone-depth to be
more specific.

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

[Jens Lehmann]

Am 28.06.2013 20:44, schrieb Junio C Hamano:
> Heiko Voigt <hvoigt@hvoigt.net> writes:
> 
>> On Thu, Jun 27, 2013 at 04:54:45PM +0200, Jens Lehmann wrote:
>> ...
>>> Me too thinks adding "--depth" to "update" makes sense (and I don't
>>> think that this pretty generic name will become a problem later in
>>> case someone wants to add a maximum recursion depth, as grep already
>>> uses "--max-depth" for the same purpose).
>>
>> Hmm, but does it have a --depth option for revisions? Maybe we should
>> call it --clone-depth or --rev-depth to make it clear? --depth and
>> --max-depth would be completely orthogonal but the name does not allow
>> to distinguish them properly.
> 
> I do not have a strong opinion either way, but as you suggest, it
> might be a good idea to call this new option --clone-depth to be
> more specific.

No strong opinion here either, but I'm leaning towards "--depth"
because on one hand we already have the "--reference" option which
is passed on to the clone command (and not "--clone-reference") and
on the other hand I cannot see the need for yet another depth option
(even my "--max-depth" example doesn't seem to be terribly useful).
But I might be wrong on the last one ;-)

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

[Junio C Hamano]

Jens Lehmann <Jens.Lehmann@web.de> writes:

> Am 28.06.2013 20:44, schrieb Junio C Hamano:
>> Heiko Voigt <hvoigt@hvoigt.net> writes:
>> ... 
>>> Hmm, but does it have a --depth option for revisions? Maybe we should
>>> call it --clone-depth or --rev-depth to make it clear? --depth and
>>> --max-depth would be completely orthogonal but the name does not allow
>>> to distinguish them properly.
>> 
>> I do not have a strong opinion either way, but as you suggest, it
>> might be a good idea to call this new option --clone-depth to be
>> more specific.
>
> No strong opinion here either, but I'm leaning towards "--depth"
> because on one hand we already have the "--reference" option which
> is passed on to the clone command (and not "--clone-reference")...

OK, then "--depth" it is.

The points in your review on the last version with "--depth" (which
I picked up and parked on 'pu') still need to be addressed, I think?

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

[Fredrik Gustafsson]

On Fri, Jun 28, 2013 at 03:51:41PM -0700, Junio C Hamano wrote:
> Jens Lehmann <Jens.Lehmann@web.de> writes:
> 
> > Am 28.06.2013 20:44, schrieb Junio C Hamano:
> >> Heiko Voigt <hvoigt@hvoigt.net> writes:
> >> ... 
> >>> Hmm, but does it have a --depth option for revisions? Maybe we should
> >>> call it --clone-depth or --rev-depth to make it clear? --depth and
> >>> --max-depth would be completely orthogonal but the name does not allow
> >>> to distinguish them properly.
> >> 
> >> I do not have a strong opinion either way, but as you suggest, it
> >> might be a good idea to call this new option --clone-depth to be
> >> more specific.
> >
> > No strong opinion here either, but I'm leaning towards "--depth"
> > because on one hand we already have the "--reference" option which
> > is passed on to the clone command (and not "--clone-reference")...
> 
> OK, then "--depth" it is.
> 
> The points in your review on the last version with "--depth" (which
> I picked up and parked on 'pu') still need to be addressed, I think?

I agree, I'm on it

-- 
Med vänliga hälsningar
Fredrik Gustafsson

tel: 0733-608274
e-post: iveqy@iveqy.com

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

[Junio C Hamano]

Fredrik Gustafsson <iveqy@iveqy.com> writes:

>> OK, then "--depth" it is.
>> 
>> The points in your review on the last version with "--depth" (which
>> I picked up and parked on 'pu') still need to be addressed, I think?
>
> I agree, I'm on it

Thanks.

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

[Junio C Hamano]

Heiko Voigt <hvoigt@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 <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.