Re: [PATCH] Added initialize and update support for submodule in git clone
From: Imran M Yousuf <hidden>
Date: 2016-06-15 22:44:03
Thanks again Junio. I will resend the patch with the latest code base. After implementing I also felt that it is not logical to go all way down, so I was thinking of adding -l | --level with -w or use --depth already in use; that will add some flexibility; what do you thing about this? I will make the similar changes you mentioned in the earlier email in this as well. I was actually concerned about unsetting and re-setting the environment variables. Is there a alternate to it? Thank you, Imran On Jan 8, 2008 12:19 PM, Junio C Hamano [off-list ref] wrote:
"Imran M Yousuf" [off-list ref] writes:quoted
This patch adds support for initializing and updating submodules when a repo is cloned. The advantage it adds is, the user actually does not have to know whether it has a module or not and if it does to what depth and path. For this I added a option -w or --with-submodule for initializing and updating during clone stage.For everything else, I strongly agree [*1*] that the notion that all subprojects are populated is a bug. I am not convinced the all-or-nothing approach you implemented in "git clone" is useful outside small toy projects where all of your users are almost always interested in everything (which inevitably invites a very valid question: why use submodule at all then?), but in the very narrow special case of "clone", all-or-nothing is the best you can do without giving additional hints somewhere in-tree (perhaps enhanced .gitmodules entries), and it certainly is better than "you do not have any choice --- you only get the toplevel".quoted
Following is the diff with git-clone 1.5.3.7; I also attached the diff and modified file in the attachment.The same comment as diff plus attachment applies to this patch as the other message. Also please do not base new development on 4-digit maintenance releases, which are meant to contain only bugfixes and no new features. A patch like this, primarily for discussion and not for immediate inclusion, is Ok, but it is better to get into the habit of producing applicable patches earlier rather than later. I'll step aside and let others discuss code and design of the patch. [Reference] *1* http://thread.gmane.org/gmane.comp.version-control.git/44106/focus=44308
-- Imran M Yousuf Entrepreneur & Software Engineer Smart IT Engineering Dhaka, Bangladesh Email: imran@smartitengineering.com Mobile: +880-1711402557