Re: [PATCH] Added initialize and update support for submodule in git clone

["Imran M Yousuf" <imyousuf@gmail.com>]

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@pobox.com> wrote:
> "Imran M Yousuf" <imyousuf@gmail.com> 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@smartitengineering.com
Mobile: +880-1711402557