Quantcast

[PATCH 0/3] Submodules: have a depth field in the .gitmodules file

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[PATCH 0/3] Submodules: have a depth field in the .gitmodules file

Stefan Beller-4
Sometimes the history of a submodule is not considered important by
the projects upstream. To make it easier for downstream users, allow
a field 'submodule.<name>.depth' in .gitmodules, which can be used
to indicate the recommended depth.

Stefan Beller (3):
  submodule update: make use of the existing fetch_in_submodule function
  submodule-config: keep `depth` around
  submodule update: learn `--recommended-depth` option

 Documentation/git-submodule.txt | 10 ++++++++--
 builtin/submodule--helper.c     |  8 +++++++-
 git-submodule.sh                | 11 +++++++++--
 submodule-config.c              | 16 ++++++++++++++++
 submodule-config.h              |  1 +
 t/t5614-clone-submodules.sh     | 34 ++++++++++++++++++++++++++++++++++
 6 files changed, 75 insertions(+), 5 deletions(-)

--
2.9.0.rc0.3.g892bdd0.dirty

base-commit: 3a0f269e7c82aa3a87323cb7ae04ac5f129f036b
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[PATCH 1/3] submodule update: make use of the existing fetch_in_submodule function

Stefan Beller-4
Signed-off-by: Stefan Beller <[hidden email]>
---
 git-submodule.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/git-submodule.sh b/git-submodule.sh
index 5a4dec0..7698102 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -640,7 +640,7 @@ cmd_update()
  if test -z "$nofetch"
  then
  # Fetch remote before determining tracking $sha1
- (sanitize_submodule_env; cd "$sm_path" && git-fetch) ||
+ fetch_in_submodule "$sm_path" ||
  die "$(eval_gettext "Unable to fetch in submodule path '\$sm_path'")"
  fi
  remote_name=$(sanitize_submodule_env; cd "$sm_path" && get_default_remote)
--
2.9.0.rc0.3.g892bdd0.dirty

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[PATCH 2/3] submodule-config: keep `depth` around

Stefan Beller-4
In reply to this post by Stefan Beller-4
The depth field will be used in a later patch by `submodule update`.
To differentiate between the actual depth (which may be different),
we name it recommended depth as the field in the .gitmodules file
is only a recommendation by the project.

Signed-off-by: Stefan Beller <[hidden email]>
---
 submodule-config.c | 16 ++++++++++++++++
 submodule-config.h |  1 +
 2 files changed, 17 insertions(+)

diff --git a/submodule-config.c b/submodule-config.c
index debab29..e65a171 100644
--- a/submodule-config.c
+++ b/submodule-config.c
@@ -199,6 +199,7 @@ static struct submodule *lookup_or_create_by_name(struct submodule_cache *cache,
  submodule->update_strategy.command = NULL;
  submodule->fetch_recurse = RECURSE_SUBMODULES_NONE;
  submodule->ignore = NULL;
+ submodule->recommended_depth = -1;
 
  hashcpy(submodule->gitmodules_sha1, gitmodules_sha1);
 
@@ -353,6 +354,21 @@ static int parse_config(const char *var, const char *value, void *data)
  else if (parse_submodule_update_strategy(value,
  &submodule->update_strategy) < 0)
  die(_("invalid value for %s"), var);
+ } else if (!strcmp(item.buf, "depth")) {
+ if (!value)
+ ret = config_error_nonbool(var);
+ else if (!me->overwrite &&
+ submodule->recommended_depth != -1)
+ warn_multiple_config(me->commit_sha1, submodule->name,
+     "depth");
+ else {
+ int d = strtol(value, NULL, 0);
+ if (d < 0)
+ warning("Invalid parameter '%s' for config option "
+ "'submodule.%s.depth'", value, var);
+ else
+ submodule->recommended_depth = d;
+ }
  }
 
  strbuf_release(&name);
diff --git a/submodule-config.h b/submodule-config.h
index e4857f5..5635b6c 100644
--- a/submodule-config.h
+++ b/submodule-config.h
@@ -15,6 +15,7 @@ struct submodule {
  const char *url;
  int fetch_recurse;
  const char *ignore;
+ int recommended_depth;
  struct submodule_update_strategy update_strategy;
  /* the sha1 blob id of the responsible .gitmodules file */
  unsigned char gitmodules_sha1[20];
--
2.9.0.rc0.3.g892bdd0.dirty

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[PATCH 3/3] submodule update: learn `--recommended-depth` option

Stefan Beller-4
In reply to this post by Stefan Beller-4
Sometimes the history of a submodule is not considered important by
the projects upstream. To make it easier for downstream users, allow
a field 'submodule.<name>.depth' in .gitmodules, which can be used
to indicate the recommended depth.

This field is honored in the initial clone by default, it can be
ignored by giving the `--no-recommended-depth` option.

Signed-off-by: Stefan Beller <[hidden email]>
---
 Documentation/git-submodule.txt | 10 ++++++++--
 builtin/submodule--helper.c     |  8 +++++++-
 git-submodule.sh                |  9 ++++++++-
 t/t5614-clone-submodules.sh     | 34 ++++++++++++++++++++++++++++++++++
 4 files changed, 57 insertions(+), 4 deletions(-)

diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index 9226c43..c928c0d 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -15,8 +15,9 @@ SYNOPSIS
 'git submodule' [--quiet] init [--] [<path>...]
 'git submodule' [--quiet] deinit [-f|--force] (--all|[--] <path>...)
 'git submodule' [--quiet] update [--init] [--remote] [-N|--no-fetch]
-      [-f|--force] [--rebase|--merge] [--reference <repository>]
-      [--depth <depth>] [--recursive] [--jobs <n>] [--] [<path>...]
+      [--[no-]recommended-depth] [-f|--force] [--rebase|--merge]
+      [--reference <repository>] [--depth <depth>] [--recursive]
+      [--jobs <n>] [--] [<path>...]
 'git submodule' [--quiet] summary [--cached|--files] [(-n|--summary-limit) <n>]
       [commit] [--] [<path>...]
 'git submodule' [--quiet] foreach [--recursive] <command>
@@ -384,6 +385,11 @@ for linkgit:git-clone[1]'s `--reference` and `--shared` options carefully.
  clone with a history truncated to the specified number of revisions.
  See linkgit:git-clone[1]
 
+--[no-]recommended-depth::
+ This option is only valid for the update command.
+ The initial clone of a submodule will use the recommended
+ `submodule.<name>.depth` as provided by the .gitmodules file.
+
 -j <n>::
 --jobs <n>::
  This option is only valid for the update command.
diff --git a/builtin/submodule--helper.c b/builtin/submodule--helper.c
index 8da263f..70bf2f2 100644
--- a/builtin/submodule--helper.c
+++ b/builtin/submodule--helper.c
@@ -581,6 +581,7 @@ struct submodule_update_clone {
 
  /* configuration parameters which are passed on to the children */
  int quiet;
+ int use_recommended_depth;
  const char *reference;
  const char *depth;
  const char *recursive_prefix;
@@ -593,7 +594,7 @@ struct submodule_update_clone {
  unsigned quickstop : 1;
 };
 #define SUBMODULE_UPDATE_CLONE_INIT {0, MODULE_LIST_INIT, 0, \
- SUBMODULE_UPDATE_STRATEGY_INIT, 0, NULL, NULL, NULL, NULL, \
+ SUBMODULE_UPDATE_STRATEGY_INIT, 0, -1, NULL, NULL, NULL, NULL, \
  STRING_LIST_INIT_DUP, 0}
 
 
@@ -698,6 +699,9 @@ static int prepare_to_clone_next_submodule(const struct cache_entry *ce,
  argv_array_push(&child->args, "--quiet");
  if (suc->prefix)
  argv_array_pushl(&child->args, "--prefix", suc->prefix, NULL);
+ if (suc->use_recommended_depth && sub->recommended_depth > 0)
+ argv_array_pushf(&child->args, "--depth=%d",
+ sub->recommended_depth);
  argv_array_pushl(&child->args, "--path", sub->path, NULL);
  argv_array_pushl(&child->args, "--name", sub->name, NULL);
  argv_array_pushl(&child->args, "--url", url, NULL);
@@ -780,6 +784,8 @@ static int update_clone(int argc, const char **argv, const char *prefix)
       "specified number of revisions")),
  OPT_INTEGER('j', "jobs", &max_jobs,
     N_("parallel jobs")),
+ OPT_BOOL(0, "recommended-depth", &suc.use_recommended_depth,
+    N_("whether the initial clone should follow the depth recommendation")),
  OPT__QUIET(&suc.quiet, N_("don't print cloning progress")),
  OPT_END()
  };
diff --git a/git-submodule.sh b/git-submodule.sh
index 7698102..794d98a 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -9,7 +9,7 @@ USAGE="[--quiet] add [-b <branch>] [-f|--force] [--name <name>] [--reference <re
    or: $dashless [--quiet] status [--cached] [--recursive] [--] [<path>...]
    or: $dashless [--quiet] init [--] [<path>...]
    or: $dashless [--quiet] deinit [-f|--force] (--all| [--] <path>...)
-   or: $dashless [--quiet] update [--init] [--remote] [-N|--no-fetch] [-f|--force] [--checkout|--merge|--rebase] [--reference <repository>] [--recursive] [--] [<path>...]
+   or: $dashless [--quiet] update [--init] [--remote] [-N|--no-fetch] [-f|--force] [--checkout|--merge|--rebase] [--[no-]recommended-depth] [--reference <repository>] [--recursive] [--] [<path>...]
    or: $dashless [--quiet] summary [--cached|--files] [--summary-limit <n>] [commit] [--] [<path>...]
    or: $dashless [--quiet] foreach [--recursive] <command>
    or: $dashless [--quiet] sync [--recursive] [--] [<path>...]"
@@ -559,6 +559,12 @@ cmd_update()
  --checkout)
  update="checkout"
  ;;
+ --recommended-depth)
+ recommended_depth="--recommended-depth"
+ ;;
+ --no-recommended-depth)
+ recommended_depth="--no-recommended-depth"
+ ;;
  --depth)
  case "$2" in '') usage ;; esac
  depth="--depth=$2"
@@ -601,6 +607,7 @@ cmd_update()
  ${update:+--update "$update"} \
  ${reference:+--reference "$reference"} \
  ${depth:+--depth "$depth"} \
+ ${recommended_depth:+"$recommended_depth"} \
  ${jobs:+$jobs} \
  "$@" || echo "#unmatched"
  } | {
diff --git a/t/t5614-clone-submodules.sh b/t/t5614-clone-submodules.sh
index 62044c5..c25eac0 100755
--- a/t/t5614-clone-submodules.sh
+++ b/t/t5614-clone-submodules.sh
@@ -82,4 +82,38 @@ test_expect_success 'non shallow clone with shallow submodule' '
  )
 '
 
+test_expect_success 'clone follows recommended depth' '
+ test_when_finished "rm -rf super_clone" &&
+ git config -f .gitmodules submodule.sub.depth 1 &&
+ git add .gitmodules &&
+ git commit -m "recommed depth for sub" &&
+ git clone --recurse-submodules --no-local "file://$pwd/." super_clone &&
+ (
+ cd super_clone &&
+ git log --oneline >lines &&
+ test_line_count = 4 lines
+ ) &&
+ (
+ cd super_clone/sub &&
+ git log --oneline >lines &&
+ test_line_count = 1 lines
+ )
+'
+
+test_expect_success 'get unshallow recommended shallow submodule' '
+ test_when_finished "rm -rf super_clone" &&
+ git clone --no-local "file://$pwd/." super_clone &&
+ (
+ cd super_clone &&
+ git submodule update --init --no-recommended-depth &&
+ git log --oneline >lines &&
+ test_line_count = 4 lines
+ ) &&
+ (
+ cd super_clone/sub &&
+ git log --oneline >lines &&
+ test_line_count = 3 lines
+ )
+'
+
 test_done
--
2.9.0.rc0.3.g892bdd0.dirty

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [PATCH 0/3] Submodules: have a depth field in the .gitmodules file

Junio C Hamano
In reply to this post by Stefan Beller-4
Stefan Beller <[hidden email]> writes:

> Sometimes the history of a submodule is not considered important by
> the projects upstream. To make it easier for downstream users, allow
> a field 'submodule.<name>.depth' in .gitmodules, which can be used
> to indicate the recommended depth.

Hmph.  I can understand and certainly agree with the first sentence,
but I am not sure if "depth", if it is anything other than "1" or
"infinity", is a reasonable value.

I'd understand if a project wants to say something like "at this
moment, history before v2.0 tag does not matter", though.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [PATCH 1/3] submodule update: make use of the existing fetch_in_submodule function

Junio C Hamano
In reply to this post by Stefan Beller-4
Stefan Beller <[hidden email]> writes:

> Signed-off-by: Stefan Beller <[hidden email]>
> ---
>  git-submodule.sh | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/git-submodule.sh b/git-submodule.sh
> index 5a4dec0..7698102 100755
> --- a/git-submodule.sh
> +++ b/git-submodule.sh
> @@ -640,7 +640,7 @@ cmd_update()
>   if test -z "$nofetch"
>   then
>   # Fetch remote before determining tracking $sha1
> - (sanitize_submodule_env; cd "$sm_path" && git-fetch) ||
> + fetch_in_submodule "$sm_path" ||
>   die "$(eval_gettext "Unable to fetch in submodule path '\$sm_path'")"
>   fi
>   remote_name=$(sanitize_submodule_env; cd "$sm_path" && get_default_remote)

Makes sense.  The main topic does not depend on this change, I hope,
as I think it is OK to queue this separately and have it graduate
before 2.9-rc1.

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [PATCH 0/3] Submodules: have a depth field in the .gitmodules file

Stefan Beller-4
In reply to this post by Junio C Hamano
On Wed, May 25, 2016 at 3:38 PM, Junio C Hamano <[hidden email]> wrote:

> Stefan Beller <[hidden email]> writes:
>
>> Sometimes the history of a submodule is not considered important by
>> the projects upstream. To make it easier for downstream users, allow
>> a field 'submodule.<name>.depth' in .gitmodules, which can be used
>> to indicate the recommended depth.
>
> Hmph.  I can understand and certainly agree with the first sentence,
> but I am not sure if "depth", if it is anything other than "1" or
> "infinity", is a reasonable value.
>
> I'd understand if a project wants to say something like "at this
> moment, history before v2.0 tag does not matter", though.

I fell for the trap, like all depth related problems fall into.
I came up with the easiest solution to be implemented into Git,
not what the user actually wants.

Background for this change is trying to get a similar thing like the
"clone-depth"
field from repo manifests implemented into Git.
And looking at e.g. [1], this is either non existent (infinity) or 1.
So maybe instead of giving a depth recommendation in the .gitmodules,
we only fill in a boolean config "[non]shallow" which defaults to non shallow
in case of not giving the field.

Thanks,
Stefan



[1] https://android.googlesource.com/platform/manifest/+/master/default.xml
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [PATCH 1/3] submodule update: make use of the existing fetch_in_submodule function

Stefan Beller-4
In reply to this post by Junio C Hamano
On Wed, May 25, 2016 at 3:41 PM, Junio C Hamano <[hidden email]> wrote:

> Stefan Beller <[hidden email]> writes:
>
>> Signed-off-by: Stefan Beller <[hidden email]>
>> ---
>>  git-submodule.sh | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/git-submodule.sh b/git-submodule.sh
>> index 5a4dec0..7698102 100755
>> --- a/git-submodule.sh
>> +++ b/git-submodule.sh
>> @@ -640,7 +640,7 @@ cmd_update()
>>                       if test -z "$nofetch"
>>                       then
>>                               # Fetch remote before determining tracking $sha1
>> -                             (sanitize_submodule_env; cd "$sm_path" && git-fetch) ||
>> +                             fetch_in_submodule "$sm_path" ||
>>                               die "$(eval_gettext "Unable to fetch in submodule path '\$sm_path'")"
>>                       fi
>>                       remote_name=$(sanitize_submodule_env; cd "$sm_path" && get_default_remote)
>
> Makes sense.  The main topic does not depend on this change, I hope,
> as I think it is OK to queue this separately and have it graduate
> before 2.9-rc1.


It doesn't, I should have send this as an independent series/patch.

Thanks,
Stefan
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Loading...