Re: [RFC] submodule+shallow clone feature request

Schuyler Duveen [off-list ref] writes:

My use case is deploying from a git repository, which would be even more
graceful with the following features:

1. When 'git clone' has both --recursive and --depth, then submodules
are also checked out shallow (for speed/bandwidth).

2. Some way to specify an override on .gitmodules sources.  This is
because our .gitmodules includes public, read-only sources (github),
rather than our local repos we would prefer to deploy from (for the
purpose of reliability).

These should be doable if you do not use --recursive, so I don't think
they are insurmountable issues.  I suspect many people would welcome such
enhancements to the "git submodule" potty.

I think the current implementation of "--recursive" is an attempt to help
people with a particular view (all submodules are interesting and the user
needs an access to them immediately) while not trying to help others with
different needs.  Contribution from the latter class of users to change
the situation would be good.

Hi,

On Wed, 10 Feb 2010, Junio C Hamano wrote:

Schuyler Duveen [off-list ref] writes:

quoted

My use case is deploying from a git repository, which would be even more
graceful with the following features:

1. When 'git clone' has both --recursive and --depth, then submodules
are also checked out shallow (for speed/bandwidth).

2. Some way to specify an override on .gitmodules sources.  This is
because our .gitmodules includes public, read-only sources (github),
rather than our local repos we would prefer to deploy from (for the
purpose of reliability).

These should be doable if you do not use --recursive, so I don't think 
they are insurmountable issues.  I suspect many people would welcome 
such enhancements to the "git submodule" potty.

Yes. Note, though, that the problems of enhancing git-submodule are not 
technical, as we can learn from the recent history, including the lack of 
support for rebasing submodules (there _were_ patches!).

Ciao,
Dscho