"Imran M Yousuf" <imyousuf@xxxxxxxxx> writes: > 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". > 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 - 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
