On Wed, Mar 23, 2016 at 11:21 PM, Jared Davison <jared@xxxxxxxxxxxxxxxxxxxxxx> wrote: > > > I've had a go at patching the git-submodule.sh code further to achieve > the result I'm seeking and it seems to work for me. Can you see a > problem with this? Welcome to Git development :) I think the code looks fine, as it solves your problem. A few thoughts: Currently the depth argument is only passed on if we're cloning from scratch, the depth argument is not passed on when fetching. I think this is because the depth argument in fetch allows to deepen or shorten the history. Shortening the history throws away data, so it's worth a second thought if the user really means that and is aware of it. So for now "git submodule update --depth 1" would mean: "keep all data I have and clone additional submodules with depth 1". With this patch it would mean: "If a submodule is missing, fetch it; make sure all submodules are shortened to depth 1". A few lines before (in 744 when using origin/master version), we still have "(clear_local_git_env; cd "$sm_path" && git-fetch) ||" which would also want to learn about the depth argument, such that all fetches are affected by the depth argument. (We can replace that line by a call to fetch_in_submodule; it should have been part of fb43e31f2b4, 2016-02-23, submodule: try harder to fetch needed sha1 by direct fetching sha1) Some thoughts unrelated to the code: Please read/skim over Documentation/SubmittingPatches, specially (5) (0) Decide what to base your work on. As this patch is based on fb43e31f2b4, we'd aim for master (1) Make separate commits for logically separate changes. This is all one logical step, so it will be one patch. (2) Describe your changes well. How about: When passing the depth argument to "git submodule update", the user is aware of shallow clones and asks Git deliberately to reduce size of the submodules; Make sure the existing submodules are also fetched with the depth parameter, such that all shallow submodules are shortened to the relevant part. (3) Generate your patch using Git tools out of your commits. (4) Sending your patches. This is only necessary if you plan on sending the patch via email, (which is most conveniant when sending lots of patches; for a one off you may want to try https://submitgit.herokuapp.com/ as it saves you the hassle of setting up getting your mailclient to do what you need, e.g. sending patches without white space breakage) (5) Sign your work Legal reasons. We want to use your code, but can only do so, if we can trust you are legally allowed to send that patch. By signing off your patch we trust you know what you are doing. ;) Thanks, Stefan > > diff --git a/git-submodule.sh b/git-submodule.sh > index cd749f4..2e5c918 100755 > --- a/git-submodule.sh > +++ b/git-submodule.sh > @@ -610,12 +610,13 @@ is_tip_reachable () ( > > fetch_in_submodule () ( > sanitize_submodule_env && > + depth=$3 > cd "$1" && > case "$2" in > '') > - git fetch ;; > + git fetch $depth ;; > *) > - git fetch $(get_default_remote) "$2" ;; > + git fetch $depth $(get_default_remote) "$2" ;; > esac > ) > > @@ -769,13 +770,13 @@ cmd_update() > # Run fetch only if $sha1 isn't present or it > # is not reachable from a ref. > is_tip_reachable "$sm_path" "$sha1" || > - fetch_in_submodule "$sm_path" || > + fetch_in_submodule "$sm_path" "" "$depth" || > die "$(eval_gettext "Unable to fetch in submodule path '\$displaypath'")" > > # Now we tried the usual fetch, but $sha1 may > # not be reachable from any of the refs > is_tip_reachable "$sm_path" "$sha1" || > - fetch_in_submodule "$sm_path" "$sha1" || > + fetch_in_submodule "$sm_path" "$sha1" "$depth" || > die "$(eval_gettext "Fetched in submodule path '\$displaypath', but > it did not contain $sha1. Direct fetching of that commit failed.")" > fi > -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html