Re: [RFC] On the --depth argument when fetching with submodules

[Fredrik Gustafsson <iveqy@iveqy.com>]

On Fri, Feb 05, 2016 at 04:05:01PM -0800, Junio C Hamano wrote:
> Stefan Beller <sbeller@google.com> writes:
> 
> > Currently when cloning a project, including submodules, the --depth argument
> > is passed on recursively, i.e. when cloning with "--depth 2", both the
> > superproject as well as the submodule will have a depth of 2.  It is not
> > garantueed that the commits as specified by the superproject are included
> > in these 2 commits of the submodule.
> >
> > Illustration:
> > (superproject with depth 2, so A would have more parents, not shown)
> >
> > superproject/master: A <- B
> >                     /      \
> > submodule/master:  C <- D <- E <- F <- G
> >
> > (Current behavior is to fetch G and F)
> 

The --depth option to git submodule is something I've wondered for some
time if it was correct to implement it or not. It's clearly not a
complete feature yet and it has some weaknesses, the most obvious one
stated above.

The reason for implementing --depth in submodules was for people having
huge (or many) submodules, that they aren't interested in developing in,
but need to download to  build their project. So they want to save time
and bandwidth.

My first thought was to implement depth from the sha1 the superproject
refered sha1. However, when implementing this, git didn't support
fetching a sha1 from a remote repository for security reasons (you
should never be allowed to fetch a commit that is not reachable from a
branch or tag).

Waiting for this to be supported (an (expensive) check could be done if
the sha1 asked for exists in any branch or tag), the --depth was added
and it's a guessing game on how deep you should fetch.
-- 
Fredrik Gustafsson

phone: +46 733-608274
e-mail: iveqy@iveqy.com
website: http://www.iveqy.com