"Imran M Yousuf" [off-list ref] 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
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