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 <gitster@xxxxxxxxx> wrote: > "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 > -- Imran M Yousuf Entrepreneur & Software Engineer Smart IT Engineering Dhaka, Bangladesh Email: imran@xxxxxxxxxxxxxxxxxxxxxx Mobile: +880-1711402557 - 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
