* Paper cut bug: Why isn't "git clone xxxx" recursive by default? @ 2014-06-03 18:11 Mara Kim 2014-06-03 19:52 ` Junio C Hamano 0 siblings, 1 reply; 21+ messages in thread From: Mara Kim @ 2014-06-03 18:11 UTC (permalink / raw) To: git Hello git devs! I'd like to start off by saying that git is an amazing piece of software and every one of you deserve major kudos for your work on the project. However, I'd like to point out a few "paper cut" bugs (to use the Ubuntu parlance). Apologies if this question has been asked already, but what is the reasoning behind making git clone not recursive (--recursive) by default? I have just recently started splitting my projects into submodules, and I feel like this is a major usability issue, especially for newbies. Wouldn't it be better to have a "--non-recursive" option and clone recursively by default? Similarly, I feel that "git pull" should automatically "git submodule update --recursive --init" as well, with the current behavior able to be specified with a "--non-recursive" option. I feel like these sorts of choices make submodules seem very much like second class citizens in git and make git much less user friendly. I feel that the most common use case that people want is to keep submodules properly in sync. In addition, I feel that power users that really want to make shallow clones, non-recursive clones, etc. could still be served with a simple option. I guess there are problems with changes in submodules being overwritten, so I suppose there would need to be additional warnings or even just refusal to pull into dirty directories, similar to the way git behaves in a regular repository. Thanks for the excellent work, Mara Kim Ph.D. Candidate Computational Biology Vanderbilt University Nashville, TN ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Paper cut bug: Why isn't "git clone xxxx" recursive by default? 2014-06-03 18:11 Paper cut bug: Why isn't "git clone xxxx" recursive by default? Mara Kim @ 2014-06-03 19:52 ` Junio C Hamano 2014-06-03 21:05 ` Junio C Hamano 0 siblings, 1 reply; 21+ messages in thread From: Junio C Hamano @ 2014-06-03 19:52 UTC (permalink / raw) To: Mara Kim; +Cc: git Mara Kim <mara.kim@vanderbilt.edu> writes: > Apologies if this question has been asked already, but what is the > reasoning behind making git clone not recursive (--recursive) by > default? The primary reason why submodules are separate repositories is not to require people to have everything. Some people want recursive, some others don't, and the world is not always "majority wins" (not that I am saying that majority will want recursive). Inertia, aka backward compatibility and not surprising existing users, plays some role when deciding the default. Also, going --recursive when the user did not want is a lot more expensive mistake to fix than not being --recursive when the user wanted to. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Paper cut bug: Why isn't "git clone xxxx" recursive by default? 2014-06-03 19:52 ` Junio C Hamano @ 2014-06-03 21:05 ` Junio C Hamano 2014-06-03 22:24 ` Mara Kim 2014-06-04 9:30 ` [RFC PATCH] clone: add clone.recursesubmodules config option Chris Packham 0 siblings, 2 replies; 21+ messages in thread From: Junio C Hamano @ 2014-06-03 21:05 UTC (permalink / raw) To: Mara Kim; +Cc: git Junio C Hamano <gitster@pobox.com> writes: > Mara Kim <mara.kim@vanderbilt.edu> writes: > >> Apologies if this question has been asked already, but what is the >> reasoning behind making git clone not recursive (--recursive) by >> default? > > The primary reason why submodules are separate repositories is not > to require people to have everything. Some people want recursive, > some others don't, and the world is not always "majority wins" (not > that I am saying that majority will want recursive). > > Inertia, aka backward compatibility and not surprising existing > users, plays some role when deciding the default. > > Also, going --recursive when the user did not want is a lot more > expensive mistake to fix than not being --recursive when the user > wanted to. Having said all that, I do not mean to say that I am opposed to introduce some mechanism to let the users express their preference between recursive and non-recursive better, so that "git clone" without an explicit --recursive (or --no-recursive) can work to their taste. A configuration in $HOME/.gitconfig might be a place to start, even though that has the downside of assuming that the given user would want to use the same settings for all his projects, which may not be the case in practice. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Paper cut bug: Why isn't "git clone xxxx" recursive by default? 2014-06-03 21:05 ` Junio C Hamano @ 2014-06-03 22:24 ` Mara Kim 2014-06-04 9:30 ` [RFC PATCH] clone: add clone.recursesubmodules config option Chris Packham 1 sibling, 0 replies; 21+ messages in thread From: Mara Kim @ 2014-06-03 22:24 UTC (permalink / raw) To: Junio C Hamano; +Cc: git That is good to hear. I would be pretty happy about that. ^.^ Obviously any major changes will need to be done carefully. I was thinking of the way that you guys introduced new defaults for Git 2.0, phasing them in slowly through the 1.x cycle. Maybe I can get my hopes up for Git 3.0 --- 9 years from now :P On Tue, Jun 3, 2014 at 4:05 PM, Junio C Hamano <gitster@pobox.com> wrote: > Junio C Hamano <gitster@pobox.com> writes: > >> Mara Kim <mara.kim@vanderbilt.edu> writes: >> >>> Apologies if this question has been asked already, but what is the >>> reasoning behind making git clone not recursive (--recursive) by >>> default? >> >> The primary reason why submodules are separate repositories is not >> to require people to have everything. Some people want recursive, >> some others don't, and the world is not always "majority wins" (not >> that I am saying that majority will want recursive). >> >> Inertia, aka backward compatibility and not surprising existing >> users, plays some role when deciding the default. >> >> Also, going --recursive when the user did not want is a lot more >> expensive mistake to fix than not being --recursive when the user >> wanted to. > > Having said all that, I do not mean to say that I am opposed to > introduce some mechanism to let the users express their preference > between recursive and non-recursive better, so that "git clone" > without an explicit --recursive (or --no-recursive) can work to > their taste. A configuration in $HOME/.gitconfig might be a place > to start, even though that has the downside of assuming that the > given user would want to use the same settings for all his projects, > which may not be the case in practice. > -- Mara Kim Ph.D. Candidate Computational Biology Vanderbilt University Nashville, TN ^ permalink raw reply [flat|nested] 21+ messages in thread
* [RFC PATCH] clone: add clone.recursesubmodules config option 2014-06-03 21:05 ` Junio C Hamano 2014-06-03 22:24 ` Mara Kim @ 2014-06-04 9:30 ` Chris Packham 2014-06-04 17:24 ` Junio C Hamano 2016-10-03 15:36 ` Jeremy Morton 1 sibling, 2 replies; 21+ messages in thread From: Chris Packham @ 2014-06-04 9:30 UTC (permalink / raw) To: git; +Cc: mara.kim, gitster, Chris Packham Add a config option that will cause clone to recurse into submodules as if the --recurse-submodules option had been specified on the command line. This can be overridden with the --no-recurse-submodules option. Signed-off-by: Chris Packham <judge.packham@gmail.com> --- On 04/06/14 09:05, Junio C Hamano wrote: >> Mara Kim <mara.kim@vanderbilt.edu> writes: >> >>> Apologies if this question has been asked already, but what is the >>> reasoning behind making git clone not recursive (--recursive) by >>> default? >> >> The primary reason why submodules are separate repositories is not >> to require people to have everything. Some people want recursive, >> some others don't, and the world is not always "majority wins" (not >> that I am saying that majority will want recursive). >> >> Inertia, aka backward compatibility and not surprising existing >> users, plays some role when deciding the default. >> >> Also, going --recursive when the user did not want is a lot more >> expensive mistake to fix than not being --recursive when the user >> wanted to. > > Having said all that, I do not mean to say that I am opposed to > introduce some mechanism to let the users express their preference > between recursive and non-recursive better, so that "git clone" > without an explicit --recursive (or --no-recursive) can work to > their taste. A configuration in $HOME/.gitconfig might be a place > to start, even though that has the downside of assuming that the > given user would want to use the same settings for all his projects, > which may not be the case in practice. And here's a quick proof of concept. Not sure about the config variable name and it could probably do with a negative test as well. builtin/clone.c | 9 +++++++++ t/t7407-submodule-foreach.sh | 17 +++++++++++++++++ 2 files changed, 26 insertions(+) diff --git a/builtin/clone.c b/builtin/clone.c index b12989d..92aea81 100644 --- a/builtin/clone.c +++ b/builtin/clone.c @@ -734,6 +734,14 @@ static void write_refspec_config(const char* src_ref_prefix, strbuf_release(&value); } +static int git_clone_config(const char *key, const char *value, void *data) +{ + if (!strcmp(key, "clone.recursesubmodules")) + option_recursive = git_config_bool(key, value); + + return 0; +} + int cmd_clone(int argc, const char **argv, const char *prefix) { int is_bundle = 0, is_local; @@ -759,6 +767,7 @@ int cmd_clone(int argc, const char **argv, const char *prefix) junk_pid = getpid(); packet_trace_identity("clone"); + git_config(git_clone_config, NULL); argc = parse_options(argc, argv, prefix, builtin_clone_options, builtin_clone_usage, 0); diff --git a/t/t7407-submodule-foreach.sh b/t/t7407-submodule-foreach.sh index 7ca10b8..fc2c189 100755 --- a/t/t7407-submodule-foreach.sh +++ b/t/t7407-submodule-foreach.sh @@ -307,6 +307,23 @@ test_expect_success 'use "update --recursive nested1" to checkout all submodules ) ' +test_expect_success 'use "git clone" with clone.recursesubmodules to checkout all submodules' ' + git config --local clone.recursesubmodules true && + git clone super clone7 && + ( + cd clone7 && + git rev-parse --resolve-git-dir .git && + git rev-parse --resolve-git-dir sub1/.git && + git rev-parse --resolve-git-dir sub2/.git && + git rev-parse --resolve-git-dir sub3/.git && + git rev-parse --resolve-git-dir nested1/.git && + git rev-parse --resolve-git-dir nested1/nested2/.git && + git rev-parse --resolve-git-dir nested1/nested2/nested3/.git && + git rev-parse --resolve-git-dir nested1/nested2/nested3/submodule/.git + ) && + git config --local --unset clone.recursesubmodules +' + test_expect_success 'command passed to foreach retains notion of stdin' ' ( cd super && -- 2.0.0.153.g79dcccc ^ permalink raw reply related [flat|nested] 21+ messages in thread
* Re: [RFC PATCH] clone: add clone.recursesubmodules config option 2014-06-04 9:30 ` [RFC PATCH] clone: add clone.recursesubmodules config option Chris Packham @ 2014-06-04 17:24 ` Junio C Hamano 2014-06-04 19:06 ` Jens Lehmann 2014-06-04 19:42 ` Heiko Voigt 2016-10-03 15:36 ` Jeremy Morton 1 sibling, 2 replies; 21+ messages in thread From: Junio C Hamano @ 2014-06-04 17:24 UTC (permalink / raw) To: Chris Packham; +Cc: git, mara.kim, Jonathan Nieder, Jens Lehmann, Heiko Voigt Chris Packham <judge.packham@gmail.com> writes: > On 04/06/14 09:05, Junio C Hamano wrote: >>> Also, going --recursive when the user did not want is a lot more >>> expensive mistake to fix than not being --recursive when the user >>> wanted to. >> >> Having said all that, I do not mean to say that I am opposed to >> introduce some mechanism to let the users express their preference >> between recursive and non-recursive better, so that "git clone" >> without an explicit --recursive (or --no-recursive) can work to >> their taste. A configuration in $HOME/.gitconfig might be a place >> to start, even though that has the downside of assuming that the >> given user would want to use the same settings for all his projects, >> which may not be the case in practice. > > And here's a quick proof of concept. Not sure about the config variable name > and it could probably do with a negative test as well. I would be more worried about the semantics than the name, though; re-read the part you quoted with extra stress on "has the downside". I think I heard the submodule folks (cc'ed) discuss an approach to allow various submodules to be marked with "tags" with a new type of entry in .gitmodules file in the superproject, and use these tags to signal "by default, a new clone will recurse into this submodule". E.g. if projects standardized on "defaultClone" to mark such submodules, then $HOME/.gitconfig could say [clone] recursesubmodules = defaultClone Or the projects may mark platform specific submodules with tags, e.g. a .gitmodules in a typical superproject might say something like this: [submodule "posix"] path = ports/posix tags = linux obsd fbsd osx [submodule "windows"] path = ports/windows tags = win32 [submodule "doc"] path = documentation tags = defaultClone and then the user's $HOME/.gitconfig might say [clone] recursesubmodules = defaultClone win32 to tell a "git clone" of such a superproject to clone the top-level, read its .gitmodules, and choose documentation/ and ports/windows submodules but not ports/posix submodule to be further cloned into the working tree of the superproject. Of course, if this kind of project organization proves to be useful, we should try to standardize the set of tags early before people start coming up with random variations of the same thing, spelling the same concept in different ways only to be different, and if that happens, then we could even give a non-empty default value for the clone.recursesubmodules when $HOME/.gitconfig is missing one. Just a random thought. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [RFC PATCH] clone: add clone.recursesubmodules config option 2014-06-04 17:24 ` Junio C Hamano @ 2014-06-04 19:06 ` Jens Lehmann 2014-06-05 18:18 ` Junio C Hamano 2014-06-04 19:42 ` Heiko Voigt 1 sibling, 1 reply; 21+ messages in thread From: Jens Lehmann @ 2014-06-04 19:06 UTC (permalink / raw) To: Junio C Hamano, Chris Packham; +Cc: git, mara.kim, Jonathan Nieder, Heiko Voigt Am 04.06.2014 19:24, schrieb Junio C Hamano: > Chris Packham <judge.packham@gmail.com> writes: > >> On 04/06/14 09:05, Junio C Hamano wrote: >>>> Also, going --recursive when the user did not want is a lot more >>>> expensive mistake to fix than not being --recursive when the user >>>> wanted to. >>> >>> Having said all that, I do not mean to say that I am opposed to >>> introduce some mechanism to let the users express their preference >>> between recursive and non-recursive better, so that "git clone" >>> without an explicit --recursive (or --no-recursive) can work to >>> their taste. A configuration in $HOME/.gitconfig might be a place >>> to start, even though that has the downside of assuming that the >>> given user would want to use the same settings for all his projects, >>> which may not be the case in practice. >> >> And here's a quick proof of concept. Not sure about the config variable name >> and it could probably do with a negative test as well. > > I would be more worried about the semantics than the name, though; > re-read the part you quoted with extra stress on "has the downside". > > I think I heard the submodule folks (cc'ed) discuss an approach to > allow various submodules to be marked with "tags" with a new type of > entry in .gitmodules file in the superproject, and use these tags to > signal "by default, a new clone will recurse into this submodule". > > E.g. if projects standardized on "defaultClone" to mark such > submodules, then $HOME/.gitconfig could say > > [clone] > recursesubmodules = defaultClone > > Or the projects may mark platform specific submodules with tags, > e.g. a .gitmodules in a typical superproject might say something > like this: > > [submodule "posix"] > path = ports/posix > tags = linux obsd fbsd osx > [submodule "windows"] > path = ports/windows > tags = win32 > [submodule "doc"] > path = documentation > tags = defaultClone > > and then the user's $HOME/.gitconfig might say > > [clone] > recursesubmodules = defaultClone win32 > > to tell a "git clone" of such a superproject to clone the top-level, > read its .gitmodules, and choose documentation/ and ports/windows > submodules but not ports/posix submodule to be further cloned into > the working tree of the superproject. > > Of course, if this kind of project organization proves to be useful, > we should try to standardize the set of tags early before people > start coming up with random variations of the same thing, spelling > the same concept in different ways only to be different, and if that > happens, then we could even give a non-empty default value for the > clone.recursesubmodules when $HOME/.gitconfig is missing one. Yes, but maybe we can define how the user wants to set the global or per-repo default (that is honored as long as upstream or local config doesn't provide more specific settings, e.g. via tags) and implement that for clone as a first step, even when we do not now how e.g. the tags setting might look like in the end. I believe we should have one or two switches telling Git "I want my submodules be updated without having to use the 'git submodule' command". And after that submodule specific overrides can kick in, e.g. when "submodule.<name>.update" is set to "none" the submodule won't be updated no matter how the default is. We had two settings in mind, first "submodule.autoinit" (which would automate the "git submodule --init" step and also control that a new submodule is fetched into .git/modules; it'd be fetched there soon as the fetch in the superproject sees a commit introducing it). That would kick in on clone, fetch and pull, as the underlying fetch honors it. And the "submodule.autoupdate" setting which will make running "git submodule update" obsolete by updating all init'ed submodules on each clone, checkout, merge, reset etc.. Together they'd achieve for all relevant commands what Chris' proposed option would only do for clone. So what if clone would just do an "git submodule init" for now when "submodule.autoinit" is set but "submodule.autoupdate" isn't (and as soon as fetch learns to honor autoinit we could remove that one again). And if both are set it'd do a "git submodule update --init --recursive", just like it does when the --recurse-submodules option is used. As soon as we also have recursive submodule update, we could remove the latter from clone. But maybe we are to close to the implementation side of things (where fetch and checkout just like init and update are two separate things) and a single "submodule.auto" setting would be what users really want? Comments welcome. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [RFC PATCH] clone: add clone.recursesubmodules config option 2014-06-04 19:06 ` Jens Lehmann @ 2014-06-05 18:18 ` Junio C Hamano 2014-06-05 18:43 ` W. Trevor King 2014-06-06 5:26 ` Heiko Voigt 0 siblings, 2 replies; 21+ messages in thread From: Junio C Hamano @ 2014-06-05 18:18 UTC (permalink / raw) To: Jens Lehmann; +Cc: Chris Packham, git, mara.kim, Jonathan Nieder, Heiko Voigt Jens Lehmann <Jens.Lehmann@web.de> writes: > ... I believe we > should have one or two switches telling Git "I want my submodules be > updated without having to use the 'git submodule' command". And > after that submodule specific overrides can kick in, e.g. when > "submodule.<name>.update" is set to "none" the submodule won't be > updated no matter how the default is. OK, so submodule.*.update for each submodule, and a default value for submodules that do not have submodule.*.update set to anything. Sounds workable. > We had two settings in mind,... > So what if clone would just do an "git submodule init" for now when > "submodule.autoinit" is set but "submodule.autoupdate" isn't [?] > ... and a single "submodule.auto" setting would be what users really want? I do not offhand think of a sensible scenario where you want to init a submodule once but do not want to update it when the superproject changes. Even if the user uses the mode to detach the submodule HEAD, i.e. the branches in submodules do not matter and the whole tree is described by the superproject's commit and gitlinks recorded in it, the user would want the new objects necessary for the updated superproject, which means a submodule that is init'ed (whether it is via "git submodule init" or the submodule.autoinit variable) must be updated. So I am not sure why a user wants to disable autoupdate in the first place. For the same reason, setting submodule.*.update to none would not make much sense, either. Perhaps I am missing something. Unless the user is very conservative and suspects that these recursive behaviour we are going to bolt on to various commands could be buggy and untrustworthy, in which case the user might want to manually run "git submodule update", or even run "git fetch" after going there while bypassing the whole "git submodule". But I do not think that is healthy in the longer run. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Re: [RFC PATCH] clone: add clone.recursesubmodules config option 2014-06-05 18:18 ` Junio C Hamano @ 2014-06-05 18:43 ` W. Trevor King 2014-06-06 5:26 ` Heiko Voigt 1 sibling, 0 replies; 21+ messages in thread From: W. Trevor King @ 2014-06-05 18:43 UTC (permalink / raw) To: Junio C Hamano Cc: Jens Lehmann, Chris Packham, git, mara.kim, Jonathan Nieder, Heiko Voigt [-- Attachment #1: Type: text/plain, Size: 1456 bytes --] On Thu, Jun 05, 2014 at 11:18:28AM -0700, Junio C Hamano wrote: > Jens Lehmann <Jens.Lehmann@web.de> writes: > > We had two settings in mind,... > > So what if clone would just do an "git submodule init" for now when > > "submodule.autoinit" is set but "submodule.autoupdate" isn't [?] > > ... and a single "submodule.auto" setting would be what users really want? > > I do not offhand think of a sensible scenario where you want to init > a submodule once but do not want to update it when the superproject > changes. Even if the user uses the mode to detach the submodule > HEAD, i.e. the branches in submodules do not matter and the whole > tree is described by the superproject's commit and gitlinks recorded > in it, the user would want the new objects necessary for the updated > superproject, which means a submodule that is init'ed (whether it is > via "git submodule init" or the submodule.autoinit variable) must be > updated. I agreed that once we have the ability to do so, autoupdating any initialized submodules should be automatic and non-optional. However, making it optional during a transition period while the ability gets fleshed out would make sense too (so checkout-mode folks can opt in before we clobber the local-branch folks ;). Ceers, Trevor -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 836 bytes --] ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Re: [RFC PATCH] clone: add clone.recursesubmodules config option 2014-06-05 18:18 ` Junio C Hamano 2014-06-05 18:43 ` W. Trevor King @ 2014-06-06 5:26 ` Heiko Voigt 2017-08-02 18:11 ` Jeremy Morton 1 sibling, 1 reply; 21+ messages in thread From: Heiko Voigt @ 2014-06-06 5:26 UTC (permalink / raw) To: Junio C Hamano Cc: Jens Lehmann, Chris Packham, git, mara.kim, Jonathan Nieder On Thu, Jun 05, 2014 at 11:18:28AM -0700, Junio C Hamano wrote: > Jens Lehmann <Jens.Lehmann@web.de> writes: > > We had two settings in mind,... > > So what if clone would just do an "git submodule init" for now when > > "submodule.autoinit" is set but "submodule.autoupdate" isn't [?] > > ... and a single "submodule.auto" setting would be what users really want? > > I do not offhand think of a sensible scenario where you want to init > a submodule once but do not want to update it when the superproject > changes. Even if the user uses the mode to detach the submodule > HEAD, i.e. the branches in submodules do not matter and the whole > tree is described by the superproject's commit and gitlinks recorded > in it, the user would want the new objects necessary for the updated > superproject, which means a submodule that is init'ed (whether it is > via "git submodule init" or the submodule.autoinit variable) must be > updated. > > So I am not sure why a user wants to disable autoupdate in the first > place. For the same reason, setting submodule.*.update to none > would not make much sense, either. Perhaps I am missing something. > > Unless the user is very conservative and suspects that these > recursive behaviour we are going to bolt on to various commands > could be buggy and untrustworthy, in which case the user might want > to manually run "git submodule update", or even run "git fetch" > after going there while bypassing the whole "git submodule". But I > do not think that is healthy in the longer run. I think autoupdate is mainly there for the transition phase. Since submodule can e.g. contain a lot of files a checkout would take much longer. Similar to when Jens implemented the recursive diff, many people were annoyed by the new files showing up and some with the impact on performance (thats why we have the --ignore-submodules option). In case of very big submodules and people already ignore their diff it might even be necessary that the update is only done manually. E.g. for a big media repository. Cheers Heiko ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [RFC PATCH] clone: add clone.recursesubmodules config option 2014-06-06 5:26 ` Heiko Voigt @ 2017-08-02 18:11 ` Jeremy Morton 2017-08-02 20:34 ` Stefan Beller 0 siblings, 1 reply; 21+ messages in thread From: Jeremy Morton @ 2017-08-02 18:11 UTC (permalink / raw) To: Heiko Voigt Cc: Junio C Hamano, Jens Lehmann, Chris Packham, git, mara.kim, Jonathan Nieder Did this ever get anywhere? If not why not? It would be very useful to me to be able to clone recursively by default, especially considering you can't use 'alias' to override the existing 'clone' command. -- Best regards, Jeremy Morton (Jez) On 06/06/2014 06:26, Heiko Voigt wrote: > On Thu, Jun 05, 2014 at 11:18:28AM -0700, Junio C Hamano wrote: >> Jens Lehmann<Jens.Lehmann@web.de> writes: >>> We had two settings in mind,... >>> So what if clone would just do an "git submodule init" for now when >>> "submodule.autoinit" is set but "submodule.autoupdate" isn't [?] >>> ... and a single "submodule.auto" setting would be what users really want? >> >> I do not offhand think of a sensible scenario where you want to init >> a submodule once but do not want to update it when the superproject >> changes. Even if the user uses the mode to detach the submodule >> HEAD, i.e. the branches in submodules do not matter and the whole >> tree is described by the superproject's commit and gitlinks recorded >> in it, the user would want the new objects necessary for the updated >> superproject, which means a submodule that is init'ed (whether it is >> via "git submodule init" or the submodule.autoinit variable) must be >> updated. >> >> So I am not sure why a user wants to disable autoupdate in the first >> place. For the same reason, setting submodule.*.update to none >> would not make much sense, either. Perhaps I am missing something. >> >> Unless the user is very conservative and suspects that these >> recursive behaviour we are going to bolt on to various commands >> could be buggy and untrustworthy, in which case the user might want >> to manually run "git submodule update", or even run "git fetch" >> after going there while bypassing the whole "git submodule". But I >> do not think that is healthy in the longer run. > > I think autoupdate is mainly there for the transition phase. Since > submodule can e.g. contain a lot of files a checkout would take much > longer. Similar to when Jens implemented the recursive diff, many people > were annoyed by the new files showing up and some with the impact on > performance (thats why we have the --ignore-submodules option). > > In case of very big submodules and people already ignore their diff it > might even be necessary that the update is only done manually. E.g. for > a big media repository. > > Cheers Heiko > -- > To unsubscribe from this list: send the line "unsubscribe git" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [RFC PATCH] clone: add clone.recursesubmodules config option 2017-08-02 18:11 ` Jeremy Morton @ 2017-08-02 20:34 ` Stefan Beller 0 siblings, 0 replies; 21+ messages in thread From: Stefan Beller @ 2017-08-02 20:34 UTC (permalink / raw) To: Jeremy Morton Cc: Heiko Voigt, Junio C Hamano, Jens Lehmann, Chris Packham, git@vger.kernel.org, mara.kim, Jonathan Nieder On Wed, Aug 2, 2017 at 11:11 AM, Jeremy Morton <admin@game-point.net> wrote: > Did this ever get anywhere? If not why not? It would be very useful to me > to be able to clone recursively by default, especially considering you can't > use 'alias' to override the existing 'clone' command. > Note that there is 3c548de378 (Merge branch 'sb/submodule-blanket-recursive', 2017-06-13), which adds recursing into submodules to a couple of commands. clone is not one of them, because at that time I thought you'd want to select explicitly at clone time which submodules you want. Unlike most other commands that can recurse into submodules, clone supports a pathspec for the recurse parameter, such that you can express a fine grained selection of submodules that you are interested in. I wonder if submodule.recurse is set if we'd just want to recurse into all submodules for clone? That may have negative consequences though as people may have forgotten that they set that config a long time ago and then are surprised to get so many submodules. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Re: [RFC PATCH] clone: add clone.recursesubmodules config option 2014-06-04 17:24 ` Junio C Hamano 2014-06-04 19:06 ` Jens Lehmann @ 2014-06-04 19:42 ` Heiko Voigt 2014-06-05 7:48 ` Chris Packham 1 sibling, 1 reply; 21+ messages in thread From: Heiko Voigt @ 2014-06-04 19:42 UTC (permalink / raw) To: Junio C Hamano Cc: Chris Packham, git, mara.kim, Jonathan Nieder, Jens Lehmann On Wed, Jun 04, 2014 at 10:24:06AM -0700, Junio C Hamano wrote: > Chris Packham <judge.packham@gmail.com> writes: > > > On 04/06/14 09:05, Junio C Hamano wrote: > >>> Also, going --recursive when the user did not want is a lot more > >>> expensive mistake to fix than not being --recursive when the user > >>> wanted to. > >> > >> Having said all that, I do not mean to say that I am opposed to > >> introduce some mechanism to let the users express their preference > >> between recursive and non-recursive better, so that "git clone" > >> without an explicit --recursive (or --no-recursive) can work to > >> their taste. A configuration in $HOME/.gitconfig might be a place > >> to start, even though that has the downside of assuming that the > >> given user would want to use the same settings for all his projects, > >> which may not be the case in practice. > > > > And here's a quick proof of concept. Not sure about the config variable name > > and it could probably do with a negative test as well. > > I would be more worried about the semantics than the name, though; > re-read the part you quoted with extra stress on "has the downside". > > I think I heard the submodule folks (cc'ed) discuss an approach to > allow various submodules to be marked with "tags" with a new type of > entry in .gitmodules file in the superproject, and use these tags to > signal "by default, a new clone will recurse into this submodule". > > E.g. if projects standardized on "defaultClone" to mark such > submodules, then $HOME/.gitconfig could say > > [clone] > recursesubmodules = defaultClone > > Or the projects may mark platform specific submodules with tags, > e.g. a .gitmodules in a typical superproject might say something > like this: > > [submodule "posix"] > path = ports/posix > tags = linux obsd fbsd osx > [submodule "windows"] > path = ports/windows > tags = win32 > [submodule "doc"] > path = documentation > tags = defaultClone > > and then the user's $HOME/.gitconfig might say > > [clone] > recursesubmodules = defaultClone win32 > > to tell a "git clone" of such a superproject to clone the top-level, > read its .gitmodules, and choose documentation/ and ports/windows > submodules but not ports/posix submodule to be further cloned into > the working tree of the superproject. > > Of course, if this kind of project organization proves to be useful, > we should try to standardize the set of tags early before people > start coming up with random variations of the same thing, spelling > the same concept in different ways only to be different, and if that > happens, then we could even give a non-empty default value for the > clone.recursesubmodules when $HOME/.gitconfig is missing one. > > Just a random thought. I like this idea of specifying different "views" by giving tags. But does it rule out a boolean clone.recursesubmodules? For the simple case some people might not want to worry about specifying tags but just want to configure: "Yes give me everything". So if we were to do this I would like it if we could have both. Also because the option for clone is --recurse-submodules and our typical schema is that a configuration option is named similar so clone.recursesubmodules would fit here. So either we do this "magically" and all valid boolean values are forbidden as tags or we would need a different config option. Further thinking about it: Maybe a general option that does not only apply to clone would suit the "views" use-case more. E.g. "submodule.tags" or similar. Also please note: We have been talking about adding two configurations for submodules: submodule."name".autoclone (IIRC) I am not sure whether that was the correct name, but this option should tell recursive fetch / clone whether to automatically clone a submodule when it appears on a fetch in the history. submodule."name".autoinit And this one is for recursive checkout and tells whether an appearing submodule should automatically be initialized. These options fullfill a similar use-case and are planned for the future when recursive fetch/clone and checkout are in place (which is not that far away). We might need to rethink these to incoporate the "views from tags" idea nicely and since we do not want a configuration nightmare. Cheers Heiko ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [RFC PATCH] clone: add clone.recursesubmodules config option 2014-06-04 19:42 ` Heiko Voigt @ 2014-06-05 7:48 ` Chris Packham 2014-06-06 5:54 ` Heiko Voigt 0 siblings, 1 reply; 21+ messages in thread From: Chris Packham @ 2014-06-05 7:48 UTC (permalink / raw) To: Heiko Voigt, Junio C Hamano; +Cc: git, mara.kim, Jonathan Nieder, Jens Lehmann On 05/06/14 07:42, Heiko Voigt wrote: > On Wed, Jun 04, 2014 at 10:24:06AM -0700, Junio C Hamano wrote: >> Chris Packham <judge.packham@gmail.com> writes: >> >>> On 04/06/14 09:05, Junio C Hamano wrote: >>>>> Also, going --recursive when the user did not want is a lot more >>>>> expensive mistake to fix than not being --recursive when the user >>>>> wanted to. >>>> >>>> Having said all that, I do not mean to say that I am opposed to >>>> introduce some mechanism to let the users express their preference >>>> between recursive and non-recursive better, so that "git clone" >>>> without an explicit --recursive (or --no-recursive) can work to >>>> their taste. A configuration in $HOME/.gitconfig might be a place >>>> to start, even though that has the downside of assuming that the >>>> given user would want to use the same settings for all his projects, >>>> which may not be the case in practice. >>> >>> And here's a quick proof of concept. Not sure about the config variable name >>> and it could probably do with a negative test as well. >> >> I would be more worried about the semantics than the name, though; >> re-read the part you quoted with extra stress on "has the downside". >> >> I think I heard the submodule folks (cc'ed) discuss an approach to >> allow various submodules to be marked with "tags" with a new type of >> entry in .gitmodules file in the superproject, and use these tags to >> signal "by default, a new clone will recurse into this submodule". >> >> E.g. if projects standardized on "defaultClone" to mark such >> submodules, then $HOME/.gitconfig could say >> >> [clone] >> recursesubmodules = defaultClone >> >> Or the projects may mark platform specific submodules with tags, >> e.g. a .gitmodules in a typical superproject might say something >> like this: >> >> [submodule "posix"] >> path = ports/posix >> tags = linux obsd fbsd osx >> [submodule "windows"] >> path = ports/windows >> tags = win32 >> [submodule "doc"] >> path = documentation >> tags = defaultClone >> >> and then the user's $HOME/.gitconfig might say >> >> [clone] >> recursesubmodules = defaultClone win32 >> >> to tell a "git clone" of such a superproject to clone the top-level, >> read its .gitmodules, and choose documentation/ and ports/windows >> submodules but not ports/posix submodule to be further cloned into >> the working tree of the superproject. >> >> Of course, if this kind of project organization proves to be useful, >> we should try to standardize the set of tags early before people >> start coming up with random variations of the same thing, spelling >> the same concept in different ways only to be different, and if that >> happens, then we could even give a non-empty default value for the >> clone.recursesubmodules when $HOME/.gitconfig is missing one. >> >> Just a random thought. > > I like this idea of specifying different "views" by giving tags. But > does it rule out a boolean clone.recursesubmodules? For the simple case > some people might not want to worry about specifying tags but just want > to configure: "Yes give me everything". So if we were to do this I would > like it if we could have both. Also because the option for clone is > --recurse-submodules and our typical schema is that a configuration > option is named similar so clone.recursesubmodules would fit here. Maybe using a glob pattern would work. The user might say [clone] recursesubmodules = x86* And .gitmodules might say [submodule "foo"] tags = x86_64 [submodule "bar"] tags = x86 [submodule "frotz"] tags = powerpc For the "Yes give me everything" case the user could say [clone] recursesubmodules = * > > So either we do this "magically" and all valid boolean values are > forbidden as tags or we would need a different config option. Further > thinking about it: Maybe a general option that does not only apply to > clone would suit the "views" use-case more. E.g. "submodule.tags" or > similar. > > Also please note: We have been talking about adding two configurations > for submodules: > > submodule."name".autoclone (IIRC) > > I am not sure whether that was the correct name, but this option should > tell recursive fetch / clone whether to automatically clone a submodule > when it appears on a fetch in the history. > > submodule."name".autoinit > > And this one is for recursive checkout and tells whether an appearing > submodule should automatically be initialized. > > These options fullfill a similar use-case and are planned for the future > when recursive fetch/clone and checkout are in place (which is not that > far away). We might need to rethink these to incoporate the "views from > tags" idea nicely and since we do not want a configuration nightmare. > > Cheers Heiko > I'm a little confused at how autoclone and autoinit differ. Aren't they the same? i.e. when this module appears grab it by default. I see autoupdate as a little different meaning update it if it's been initialised. Also does autoinit imply autoupdate? At $dayjob we have a superproject which devs clone this has submodules for the important and/or high touch repositories. We have other repositories that are normally build from a tarball (or not built at all) but we can build them from external repositories if needed. The latter case is painfully manual. If autoinit/autoupdate existed we'd probably setup out projects with. [submodule "linux"] autoinit = true autoupdate = true [submodule "userland"] autoinit = true autoupdate = true [submodule "not-used-that-much"] autoupdate = true We probably wouldn't make use of tags because we're building complete embedded systems and generally want everything, even if we are doing most of our work on a particular target we need to do builds for other targets for sanity checks. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Re: [RFC PATCH] clone: add clone.recursesubmodules config option 2014-06-05 7:48 ` Chris Packham @ 2014-06-06 5:54 ` Heiko Voigt 2014-06-06 16:35 ` Junio C Hamano 2014-06-09 13:17 ` Jens Lehmann 0 siblings, 2 replies; 21+ messages in thread From: Heiko Voigt @ 2014-06-06 5:54 UTC (permalink / raw) To: Chris Packham Cc: Junio C Hamano, git, mara.kim, Jonathan Nieder, Jens Lehmann On Thu, Jun 05, 2014 at 07:48:33PM +1200, Chris Packham wrote: > On 05/06/14 07:42, Heiko Voigt wrote: > > I like this idea of specifying different "views" by giving tags. But > > does it rule out a boolean clone.recursesubmodules? For the simple case > > some people might not want to worry about specifying tags but just want > > to configure: "Yes give me everything". So if we were to do this I would > > like it if we could have both. Also because the option for clone is > > --recurse-submodules and our typical schema is that a configuration > > option is named similar so clone.recursesubmodules would fit here. > > Maybe using a glob pattern would work. > > The user might say > > [clone] > recursesubmodules = x86* > > And .gitmodules might say > > [submodule "foo"] > tags = x86_64 > [submodule "bar"] > tags = x86 > [submodule "frotz"] > tags = powerpc > > For the "Yes give me everything" case the user could say > > [clone] > recursesubmodules = * Thats interesting. Lets me/us think about that a little more. > > So either we do this "magically" and all valid boolean values are > > forbidden as tags or we would need a different config option. Further > > thinking about it: Maybe a general option that does not only apply to > > clone would suit the "views" use-case more. E.g. "submodule.tags" or > > similar. > > > > Also please note: We have been talking about adding two configurations > > for submodules: > > > > submodule."name".autoclone (IIRC) > > > > I am not sure whether that was the correct name, but this option should > > tell recursive fetch / clone whether to automatically clone a submodule > > when it appears on a fetch in the history. > > > > submodule."name".autoinit > > > > And this one is for recursive checkout and tells whether an appearing > > submodule should automatically be initialized. > > > > These options fullfill a similar use-case and are planned for the future > > when recursive fetch/clone and checkout are in place (which is not that > > far away). We might need to rethink these to incoporate the "views from > > tags" idea nicely and since we do not want a configuration nightmare. > > I'm a little confused at how autoclone and autoinit differ. Aren't they > the same? i.e. when this module appears grab it by default. I see > autoupdate as a little different meaning update it if it's been > initialised. Also does autoinit imply autoupdate? autoclone is about cloning the history of submodules. So e.g. when a submodule first appears in the superprojects history whether it should automatically be cloned to .git/modules. autoinit is all about the checkout phase. When a commit with a new submodule is checked out: Should that new submodule be automatically initialised? As far as autoupdate is concerned: Maybe autoinit can imply that it is enabled, yes. But I guess we still need autoupdate for the case of big submodules that cause to much performance trouble if updated by every checkout. So its actually three values: autoclone, autoinit, autoupdate. Damn, these configurations become more complicated everytime. Maybe we should try to clean them, up once we have everything, with Git 3.0 ;-) If anyone has an idea how to get rid of some right now... Radically different thinking: How about just one: submodule.auto = true/false configuration and that means you opt in to doing everything as automatic as possible. Since we are still implementing we could stick a prominent warning in the documentation that the user should be prepared for behavioral changes. Once everybody is happy with that we could switch the default from false to true. > At $dayjob we have a superproject which devs clone this has submodules > for the important and/or high touch repositories. We have other > repositories that are normally build from a tarball (or not built at > all) but we can build them from external repositories if needed. The > latter case is painfully manual. If autoinit/autoupdate existed we'd > probably setup out projects with. > > [submodule "linux"] > autoinit = true > autoupdate = true > [submodule "userland"] > autoinit = true > autoupdate = true > [submodule "not-used-that-much"] > autoupdate = true > > We probably wouldn't make use of tags because we're building complete > embedded systems and generally want everything, even if we are doing > most of our work on a particular target we need to do builds for other > targets for sanity checks. Yep thats exactly what we already do at $dayjob but with submodule.*.update=none. Since that conveniently also disables the initialisation, developers only get the basic code and not everyone needs to have the media and some big external libs. I would reuse 'update' in the long run. But I guess for the transition we will need the extra autoupdate one to keep annoyance levels low. We currently also do not have real use cases for the tags/views scenario, but as repositories grow I can see that it could be useful so I would like it if we could keep the configuration open to that. Cheers Heiko ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [RFC PATCH] clone: add clone.recursesubmodules config option 2014-06-06 5:54 ` Heiko Voigt @ 2014-06-06 16:35 ` Junio C Hamano 2014-06-09 13:17 ` Jens Lehmann 1 sibling, 0 replies; 21+ messages in thread From: Junio C Hamano @ 2014-06-06 16:35 UTC (permalink / raw) To: Heiko Voigt; +Cc: Chris Packham, git, mara.kim, Jonathan Nieder, Jens Lehmann Heiko Voigt <hvoigt@hvoigt.net> writes: > On Thu, Jun 05, 2014 at 07:48:33PM +1200, Chris Packham wrote: > ... >> I'm a little confused at how autoclone and autoinit differ. Aren't they >> the same? i.e. when this module appears grab it by default. I see >> autoupdate as a little different meaning update it if it's been >> initialised. Also does autoinit imply autoupdate? > > autoclone is about cloning the history of submodules. So e.g. when a > submodule first appears in the superprojects history whether it should > automatically be cloned to .git/modules. > > autoinit is all about the checkout phase. When a commit with a new > submodule is checked out: Should that new submodule be automatically > initialised? > > As far as autoupdate is concerned: Maybe autoinit can imply that it is > enabled, yes. But I guess we still need autoupdate for the case of big > submodules that cause to much performance trouble if updated by every > checkout. > So its actually three values: autoclone, autoinit, autoupdate. Damn, > these configurations become more complicated everytime. I suspect that as an end-user you do not need to set all three in most cases. Just like an unspecified autoupdate can default to whatever autoinit setting for the submodule is, because it is less likely that a user wants to have a submodule checked out *and* leave it stale, an unspecified autoinit can default to the autoclone setting, because it is less likely that a user who does not want to have a checkout would want to spend network bandwidth to clone it. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [RFC PATCH] clone: add clone.recursesubmodules config option 2014-06-06 5:54 ` Heiko Voigt 2014-06-06 16:35 ` Junio C Hamano @ 2014-06-09 13:17 ` Jens Lehmann 2014-06-09 23:27 ` W. Trevor King 1 sibling, 1 reply; 21+ messages in thread From: Jens Lehmann @ 2014-06-09 13:17 UTC (permalink / raw) To: Heiko Voigt, Chris Packham; +Cc: Junio C Hamano, git, mara.kim, Jonathan Nieder Am 06.06.2014 07:54, schrieb Heiko Voigt: > On Thu, Jun 05, 2014 at 07:48:33PM +1200, Chris Packham wrote: >> On 05/06/14 07:42, Heiko Voigt wrote: >>> So either we do this "magically" and all valid boolean values are >>> forbidden as tags or we would need a different config option. Further >>> thinking about it: Maybe a general option that does not only apply to >>> clone would suit the "views" use-case more. E.g. "submodule.tags" or >>> similar. >>> >>> Also please note: We have been talking about adding two configurations >>> for submodules: >>> >>> submodule."name".autoclone (IIRC) >>> >>> I am not sure whether that was the correct name, but this option should >>> tell recursive fetch / clone whether to automatically clone a submodule >>> when it appears on a fetch in the history. >>> >>> submodule."name".autoinit >>> >>> And this one is for recursive checkout and tells whether an appearing >>> submodule should automatically be initialized. >>> >>> These options fullfill a similar use-case and are planned for the future >>> when recursive fetch/clone and checkout are in place (which is not that >>> far away). We might need to rethink these to incoporate the "views from >>> tags" idea nicely and since we do not want a configuration nightmare. >> >> I'm a little confused at how autoclone and autoinit differ. Aren't they >> the same? i.e. when this module appears grab it by default. I see >> autoupdate as a little different meaning update it if it's been >> initialised. Also does autoinit imply autoupdate? > > autoclone is about cloning the history of submodules. So e.g. when a > submodule first appears in the superprojects history whether it should > automatically be cloned to .git/modules. > > autoinit is all about the checkout phase. When a commit with a new > submodule is checked out: Should that new submodule be automatically > initialised? To me those two only make sense together, so I see them as a single option. But then maybe some developers would like to clone everything so they are plane-safe in case they intend to do "git submodule update --init" later at 30.000 feet without internet access ... so yes, technically we have three distinct steps: clone, init & update. > As far as autoupdate is concerned: Maybe autoinit can imply that it is > enabled, yes. But I guess we still need autoupdate for the case of big > submodules that cause to much performance trouble if updated by every > checkout. > > So its actually three values: autoclone, autoinit, autoupdate. Damn, > these configurations become more complicated everytime. Maybe we should > try to clean them, up once we have everything, with Git 3.0 ;-) If > anyone has an idea how to get rid of some right now... I suspect that once they are introduced we'll never be able to get rid of them again ;-) > Radically different thinking: How about just one: submodule.auto = > true/false configuration and that means you opt in to doing everything > as automatic as possible. Since we are still implementing we could stick > a prominent warning in the documentation that the user should be > prepared for behavioral changes. > > Once everybody is happy with that we could switch the default from false > to true. I like that. (And if we really need /clone-but-no-init-or-update/ or /clone-and-init-but-no-update/ settings later we could add two new values additionally to true/false to make that work with a single setting too). So I'm convinced that a single option is the way to go. >> At $dayjob we have a superproject which devs clone this has submodules >> for the important and/or high touch repositories. We have other >> repositories that are normally build from a tarball (or not built at >> all) but we can build them from external repositories if needed. The >> latter case is painfully manual. If autoinit/autoupdate existed we'd >> probably setup out projects with. >> >> [submodule "linux"] >> autoinit = true >> autoupdate = true >> [submodule "userland"] >> autoinit = true >> autoupdate = true >> [submodule "not-used-that-much"] >> autoupdate = true >> >> We probably wouldn't make use of tags because we're building complete >> embedded systems and generally want everything, even if we are doing >> most of our work on a particular target we need to do builds for other >> targets for sanity checks. > > Yep thats exactly what we already do at $dayjob but with > submodule.*.update=none. Since that conveniently also disables the > initialisation, developers only get the basic code and not everyone > needs to have the media and some big external libs. > > I would reuse 'update' in the long run. But I guess for the transition > we will need the extra autoupdate one to keep annoyance levels low. I'm not sure reusing 'update' is going to work: 'update' currently controls what "git submodule update" will do: nothing, checkout, merge or rebase (and we shouldn't change that because of backwards compatibility). We're talking about a new setting telling regular git commands to do the submodule work tree update without having to manually call "git submodule update". And I believe we'll always need 'update' as it is for people who'll want to do a manual "git submodule update", especially when we change the default of 'submodule.auto' to true in 3.0. And by the way: wouldn't it make more sense to tell the user /what/ we do automatically? So maybe 'submodule.autoupdate' is a better name for the new switch? The fact that it also does clone and init under the hood looks more like a technical detail to the user, no? And I'd like to avoid users uttering "auto-what?" when they hear about this setting ;-) And it would make clear that 'update' is what we do and 'autoupdate' makes it happen without having to call "git submodule update". ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Re: [RFC PATCH] clone: add clone.recursesubmodules config option 2014-06-09 13:17 ` Jens Lehmann @ 2014-06-09 23:27 ` W. Trevor King 0 siblings, 0 replies; 21+ messages in thread From: W. Trevor King @ 2014-06-09 23:27 UTC (permalink / raw) To: Jens Lehmann Cc: Heiko Voigt, Chris Packham, Junio C Hamano, git, mara.kim, Jonathan Nieder [-- Attachment #1: Type: text/plain, Size: 550 bytes --] On Mon, Jun 09, 2014 at 03:17:07PM +0200, Jens Lehmann wrote: > And by the way: wouldn't it make more sense to tell the user /what/ > we do automatically? So maybe 'submodule.autoupdate' is a better > name for the new switch? Or autocheckout? No need to preserve submodule-specific jargon when we have a perfectly acceptable word for this in the core interface ;). Cheers, Trevor -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 836 bytes --] ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [RFC PATCH] clone: add clone.recursesubmodules config option 2014-06-04 9:30 ` [RFC PATCH] clone: add clone.recursesubmodules config option Chris Packham 2014-06-04 17:24 ` Junio C Hamano @ 2016-10-03 15:36 ` Jeremy Morton 2016-10-03 17:18 ` Stefan Beller 1 sibling, 1 reply; 21+ messages in thread From: Jeremy Morton @ 2016-10-03 15:36 UTC (permalink / raw) To: Chris Packham; +Cc: git, mara.kim, gitster Did this ever get anywhere? Can we recursively update submodules with "git pull" in the supermodule now? -- Best regards, Jeremy Morton (Jez) On 04/06/2014 10:30, Chris Packham wrote: > Add a config option that will cause clone to recurse into submodules as > if the --recurse-submodules option had been specified on the command > line. This can be overridden with the --no-recurse-submodules option. > > Signed-off-by: Chris Packham<judge.packham@gmail.com> > --- > On 04/06/14 09:05, Junio C Hamano wrote: >>> Mara Kim<mara.kim@vanderbilt.edu> writes: >>> >>>> Apologies if this question has been asked already, but what is the >>>> reasoning behind making git clone not recursive (--recursive) by >>>> default? >>> >>> The primary reason why submodules are separate repositories is not >>> to require people to have everything. Some people want recursive, >>> some others don't, and the world is not always "majority wins" (not >>> that I am saying that majority will want recursive). >>> >>> Inertia, aka backward compatibility and not surprising existing >>> users, plays some role when deciding the default. >>> >>> Also, going --recursive when the user did not want is a lot more >>> expensive mistake to fix than not being --recursive when the user >>> wanted to. >> >> Having said all that, I do not mean to say that I am opposed to >> introduce some mechanism to let the users express their preference >> between recursive and non-recursive better, so that "git clone" >> without an explicit --recursive (or --no-recursive) can work to >> their taste. A configuration in $HOME/.gitconfig might be a place >> to start, even though that has the downside of assuming that the >> given user would want to use the same settings for all his projects, >> which may not be the case in practice. > > And here's a quick proof of concept. Not sure about the config variable name > and it could probably do with a negative test as well. > > builtin/clone.c | 9 +++++++++ > t/t7407-submodule-foreach.sh | 17 +++++++++++++++++ > 2 files changed, 26 insertions(+) > > diff --git a/builtin/clone.c b/builtin/clone.c > index b12989d..92aea81 100644 > --- a/builtin/clone.c > +++ b/builtin/clone.c > @@ -734,6 +734,14 @@ static void write_refspec_config(const char* src_ref_prefix, > strbuf_release(&value); > } > > +static int git_clone_config(const char *key, const char *value, void *data) > +{ > + if (!strcmp(key, "clone.recursesubmodules")) > + option_recursive = git_config_bool(key, value); > + > + return 0; > +} > + > int cmd_clone(int argc, const char **argv, const char *prefix) > { > int is_bundle = 0, is_local; > @@ -759,6 +767,7 @@ int cmd_clone(int argc, const char **argv, const char *prefix) > junk_pid = getpid(); > > packet_trace_identity("clone"); > + git_config(git_clone_config, NULL); > argc = parse_options(argc, argv, prefix, builtin_clone_options, > builtin_clone_usage, 0); > > diff --git a/t/t7407-submodule-foreach.sh b/t/t7407-submodule-foreach.sh > index 7ca10b8..fc2c189 100755 > --- a/t/t7407-submodule-foreach.sh > +++ b/t/t7407-submodule-foreach.sh > @@ -307,6 +307,23 @@ test_expect_success 'use "update --recursive nested1" to checkout all submodules > ) > ' > > +test_expect_success 'use "git clone" with clone.recursesubmodules to checkout all submodules' ' > + git config --local clone.recursesubmodules true&& > + git clone super clone7&& > + ( > + cd clone7&& > + git rev-parse --resolve-git-dir .git&& > + git rev-parse --resolve-git-dir sub1/.git&& > + git rev-parse --resolve-git-dir sub2/.git&& > + git rev-parse --resolve-git-dir sub3/.git&& > + git rev-parse --resolve-git-dir nested1/.git&& > + git rev-parse --resolve-git-dir nested1/nested2/.git&& > + git rev-parse --resolve-git-dir nested1/nested2/nested3/.git&& > + git rev-parse --resolve-git-dir nested1/nested2/nested3/submodule/.git > + )&& > + git config --local --unset clone.recursesubmodules > +' > + > test_expect_success 'command passed to foreach retains notion of stdin' ' > ( > cd super&& ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [RFC PATCH] clone: add clone.recursesubmodules config option 2016-10-03 15:36 ` Jeremy Morton @ 2016-10-03 17:18 ` Stefan Beller 2016-10-04 11:41 ` Heiko Voigt 0 siblings, 1 reply; 21+ messages in thread From: Stefan Beller @ 2016-10-03 17:18 UTC (permalink / raw) To: Jeremy Morton Cc: Chris Packham, git@vger.kernel.org, mara.kim, Junio C Hamano On Mon, Oct 3, 2016 at 8:36 AM, Jeremy Morton <admin@game-point.net> wrote: > Did this ever get anywhere? Can we recursively update submodules with "git > pull" in the supermodule now? I think the idea is sound. >> diff --git a/t/t7407-submodule-foreach.sh b/t/t7407-submodule-foreach.sh >> index 7ca10b8..fc2c189 100755 >> --- a/t/t7407-submodule-foreach.sh >> +++ b/t/t7407-submodule-foreach.sh Not sure if t7407-submodule-foreach.sh is the best place to put these tests, as it is not `submodule foreach`, maybe put it into 7400 (though that is larger already) >> +test_expect_success 'use "git clone" with clone.recursesubmodules to >> checkout all submodules' ' >> + git config --local clone.recursesubmodules true&& Nit of the day: I think we prefer a single white space between the line and the ending &&. No need for --local as that is the default. However I'd propose to use test_config here, as then the option is cleaned up after the test automatically. >> + git clone super clone7&& >> + ( >> + cd clone7&& >> + git rev-parse --resolve-git-dir .git&& >> + git rev-parse --resolve-git-dir sub1/.git&& >> + git rev-parse --resolve-git-dir sub2/.git&& >> + git rev-parse --resolve-git-dir sub3/.git&& >> + git rev-parse --resolve-git-dir nested1/.git&& >> + git rev-parse --resolve-git-dir nested1/nested2/.git&& >> + git rev-parse --resolve-git-dir >> nested1/nested2/nested3/.git&& >> + git rev-parse --resolve-git-dir >> nested1/nested2/nested3/submodule/.git >> + )&& >> + git config --local --unset clone.recursesubmodules No need to unset it here when test_config is used. We'd maybe would want to also test that git -c clone.recursesubmodules clone --no-recursive ... works as expected (the --no-recursive taking precedence over the config option) ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [RFC PATCH] clone: add clone.recursesubmodules config option 2016-10-03 17:18 ` Stefan Beller @ 2016-10-04 11:41 ` Heiko Voigt 0 siblings, 0 replies; 21+ messages in thread From: Heiko Voigt @ 2016-10-04 11:41 UTC (permalink / raw) To: Stefan Beller Cc: Jeremy Morton, Chris Packham, git@vger.kernel.org, mara.kim, Junio C Hamano On Mon, Oct 03, 2016 at 10:18:32AM -0700, Stefan Beller wrote: > On Mon, Oct 3, 2016 at 8:36 AM, Jeremy Morton <admin@game-point.net> wrote: > > Did this ever get anywhere? Can we recursively update submodules with "git > > pull" in the supermodule now? > > I think the idea is sound. I am confused there is nothing handling *pull* here? This patch was about clone. Handling 'pull' is a much bigger topic[1]. Cheers Heiko [1] https://github.com/jlehmann/git-submod-enhancements/wiki/Recursive-submodule-checkout ^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2017-08-02 20:35 UTC | newest] Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-06-03 18:11 Paper cut bug: Why isn't "git clone xxxx" recursive by default? Mara Kim 2014-06-03 19:52 ` Junio C Hamano 2014-06-03 21:05 ` Junio C Hamano 2014-06-03 22:24 ` Mara Kim 2014-06-04 9:30 ` [RFC PATCH] clone: add clone.recursesubmodules config option Chris Packham 2014-06-04 17:24 ` Junio C Hamano 2014-06-04 19:06 ` Jens Lehmann 2014-06-05 18:18 ` Junio C Hamano 2014-06-05 18:43 ` W. Trevor King 2014-06-06 5:26 ` Heiko Voigt 2017-08-02 18:11 ` Jeremy Morton 2017-08-02 20:34 ` Stefan Beller 2014-06-04 19:42 ` Heiko Voigt 2014-06-05 7:48 ` Chris Packham 2014-06-06 5:54 ` Heiko Voigt 2014-06-06 16:35 ` Junio C Hamano 2014-06-09 13:17 ` Jens Lehmann 2014-06-09 23:27 ` W. Trevor King 2016-10-03 15:36 ` Jeremy Morton 2016-10-03 17:18 ` Stefan Beller 2016-10-04 11:41 ` Heiko Voigt
Code repositories for project(s) associated with this public inbox https://80x24.org/mirrors/git.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).