RE: [PATCH v3 3/4] gitfaq: shallow cloning a repository
- From
Randall S. Becker <rsbecker@nexbridge.com>
- Date
- Apr 21, 2020, 20:43 UTC
- Message-ID
- <011001d6181d$97301fc0$c5905f40$@nexbridge.com>
- In-Reply-To
- <xmqqy2qomwwl.fsf@gitster.c.googlers.com>
On April 21, 2020 4:01 PM, Junio C Hamano
Show 28 quoted lines
> Subject: Re: [PATCH v3 3/4] gitfaq: shallow cloning a repository > > Shourya Shukla <shouryashukla.oo@gmail.com> 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 <shouryashukla.oo@gmail.com> > > --- > > 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'.
Show 5 quoted lines
> > ... > > 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.