Re: [PATCH v3 3/4] gitfaq: shallow cloning a repository
- From
Derrick Stolee <stolee@gmail.com>
- Date
- Apr 22, 2020, 01:30 UTC
- Message-ID
- <9142ccdb-6359-4936-e621-55eab980b7cd@gmail.com>
- In-Reply-To
- <011001d6181d$97301fc0$c5905f40$@nexbridge.com>
On 4/21/2020 4:43 PM, Randall S. Becker wrote:
Show 42 quoted lines
> On April 21, 2020 4:01 PM, Junio C Hamano >> 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'. >>> ... >> >> 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.
It is important, then, to mention what the _real_ uses for shallow clones.
They are great for getting just the working directory at tip for a throwaway action (like building an artifact, or just taking a static copy of something) but it is a _terrible_ way to start working on source code for a project that you intend to use for daily work.
The way this is worded in the FAQ will lead users to have a bad experience and we should recommend partial clone (--filter=blob:none) instead.
Of course, with the speedups from reachability bitmaps, it is sometimes _faster_ to do a partial clone than a shallow clone. (It definitely takes less time in the "counting objects" phase, and the cost of downloading all commits and trees might be small enough on top of the necessary blob data to keep the total cost under a shallow clone. Your mileage may vary.) Because the cost of a partial clone is "comparable" to shallow clone, I would almost recommend partial clone over shallow clones 95% of the time, even in scenarios like automated builds on cloud-hosted VMs.
Thanks, -Stolee