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
