Subject: RE: [PATCH v3 3/4] gitfaq: shallow cloning a repository

From: "Randall S. Becker" <[email-masked]>
Date: Tue, 21 Apr 2020 16:43:55 -0400

On April 21, 2020 4:01 PM, Junio C Hamano
> Subject: Re: [PATCH v3 3/4] gitfaq: shallow cloning a repository
> 
> Shourya Shukla <[email-masked]> writes:
> 
> > Add issue in 'Common issue' section which covers issues with cloning
> > large repositories. Use shallow cloning to clone the repository in a
> > smaller size.
> >
> > Signed-off-by: Shourya Shukla <[email-masked]>
> > ---
> >  Documentation/gitfaq.txt | 14 ++++++++++++++
> >  1 file changed, 14 insertions(+)
> >
> > diff --git a/Documentation/gitfaq.txt b/Documentation/gitfaq.txt index
> > 13d37f96af..cea293cf07 100644
> > --- a/Documentation/gitfaq.txt
> > +++ b/Documentation/gitfaq.txt
> > @@ -275,6 +275,20 @@ I want to change the remote of my repository.
> How do I do that?::
> >  One can list the remotes of a repository using `git remote -v` command.
> >  The default name of a remote is 'origin'.
> >
> > +[[shallow-cloning]]
> > +The repository I am trying to clone is too big. Is there an
> > +alternative way of cloning it in lesser space?::
> > +	One can clone a repository having a truncated history, meaning the
> > +	history	will span upto a specified number of commits instead of
> > +	the whole history of the repository. This is called 'Shallow
Cloning'.
> > ...
> 
> The question is worth keeping but the answer is questionable.
> 
> I have a feeling that --depth/shallow is deprecated/frowned upon these
days
> and more people recommend partial/blob-less clones instead (a few random
> people added to Cc: to see if they want to say something here).

I rather hate to chime in as a dissenting opinion, but the --depth/shallow
clone is very useful when git is being used as an artifact repository for
production. The shallow clone allows only the production branch HEAD to be
cloned into production/staging areas and limits the visible history for
staff who do not want to go through a potentially long trail during
time-sensitive operations (a.k.a. production installs). There are also space
and policy constraints in some of these environments where they do not want
to have ongoing visibility to non-production commit paths. When the *stuff*
hits the fan, then it's good to be able to fetch everything (or a limited
set). I would be very disappointed to see --depth frowned upon.

Regards,
Randall

-- Brief whoami:
 NonStop developer since approximately 211288444200000000
 UNIX developer since approximately 421664400
-- In my real life, I talk too much.