Fetching single tag in shallow clone almost unshallow the clone

Fetching single tag in shallow clone almost unshallow the clone

[Bagas Sanjaya]

Hi,

I have a copy of Golang repository [1] on my local Git server on my 
computer. I'm experimenting with fetching single tags in shallow
clone.

I begin with shallow clone the repo:

$ git clone https://<myhost>/path/to/go.git --depth 200 golang
$ cd golang

Because only one, default branch (master) is checked out on shallow 
clone, I fetch latest release branch shallowly:

$ git remote set-branches --add origin release-branch.go1.16
$ git fetch origin release-branch.go1.16 --depth 25

Then I fetch single tag only, that is latest tagged release:

$ git fetch origin tag go1.16.4 --no-tags
> From https://<myhost>/path/to/go
>  * [new tag]           go1.16.4   -> go1.16.4

That above worked, because the commit the tag refers to is already on 
the clone.

But when I fetch a single tag which the commit the tag refers to isn't 
already on the clone, Git fetched almost the entire history (thus almost 
unshallow the clone):

$ git fetch origin tag go1.16.1 --no-tags
> remote: Enumerating objects: 436644, done.
> remote: Counting objects: 100% (427655/427655), done.
> remote: Compressing objects: 100% (75334/75334), done.
> remote: Total 419698 (delta 343975), reused 416121 (delta 341201), pack-reused 0
> Receiving objects: 100% (419698/419698), 146.94 MiB | 16.06 MiB/s, done.
> Resolving deltas: 100% (343975/343975), completed with 4892 local objects.
> From https://gitnode.io/bagas/go
>  * [new tag]           go1.16.1   -> go1.16.1

I expect that instead Git will deepen the shallow clone until the 
specified tag.

Note that I used "almost unshallow" phrase, because although almost the 
whole history had been fetched, `.git/shallow` still exists, meant that 
the clone was still shallow. To convert to full clone, I did `git fetch 
--unshallow`, which also fetched tags referenced on either master or 
already configured released branches.

Thanks.

[1]: https://github.com/golang/go
-- 
An old man doll... just what I always wanted! - Clara

Re: Fetching single tag in shallow clone almost unshallow the clone

[Derrick Stolee]

On 5/28/2021 3:03 AM, Bagas Sanjaya wrote:> But when I fetch a single tag which the commit the tag refers to isn't already on the clone, Git fetched almost the entire history (thus almost unshallow the clone):
> 
> $ git fetch origin tag go1.16.1 --no-tags

You should add a --depth here, too. Git doesn't remember that you want
a certain depth, because that doesn't work in perpetuity.

You are hitting the issue I documented in my comparison between partial
and shallow clones [1]: The commit history for go1.16.1 goes "around"
your shallow boundary. See the image immediately above the "Comparing
Clone Options" section.

[1] https://github.blog/2020-12-21-get-up-to-speed-with-partial-clone-and-shallow-clone/#user-content-shallow-clones

Thanks,
-Stolee

Re: Fetching single tag in shallow clone almost unshallow the clone

[Bagas Sanjaya]

Hi,

> You should add a --depth here, too. Git doesn't remember that you want
> a certain depth, because that doesn't work in perpetuity.
> 

OK. I can specify --depth that I want, but often I forget how deep my 
clone when fetching tag with --depth, so that it has the same depth as 
before fetching tag. What should I do?

> You are hitting the issue I documented in my comparison between partial
> and shallow clones [1]: The commit history for go1.16.1 goes "around"
> your shallow boundary. See the image immediately above the "Comparing
> Clone Options" section.
> 
> [1] https://github.blog/2020-12-21-get-up-to-speed-with-partial-clone-and-shallow-clone/#user-content-shallow-clones

So basically when I request fetching something out of shallow boundary, 
Git "unshallow" by fetching the whole remaining history (but not implies 
--unshallow).

I found out that shallow clones perform on repos that have linear 
history policy (that is no merge commits). For example, on linear 
history repo, deepening shallow clone with `git fetch --deepen <n>` 
deepens the shallow boundary by <n> commits, whereas on repo with merge 
commits, doing the same may drastically zig-zag number of commits on the 
clone (at one instance can be more commits, at the other can be fewer).

-- 
An old man doll... just what I always wanted! - Clara