{"thread":{"id":"55790","subject":"Fetching single tag in shallow clone almost unshallow the clone","startedAt":"2021-05-28T07:03:37Z","lastAt":"2021-05-28T12:46:51Z","messageCount":3,"participants":["Bagas Sanjaya","Derrick Stolee"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"425745","messageId":"304633fd-e677-7956-6787-f60f195db9b5@gmail.com","threadId":"55790","inReplyTo":null,"subject":"Fetching single tag in shallow clone almost unshallow the clone","fromName":"Bagas Sanjaya","fromEmail":"bagasdotme@gmail.com","sentAt":"2021-05-28T07:03:05Z","receivedAt":"2021-05-28T07:03:37Z","isPatch":false,"sender":{"key":"bagasdotme@gmail.com","avatar":"https://avatars.githubusercontent.com/u/40219486?v=4"},"body":"Hi,\n\nI have a copy of Golang repository [1] on my local Git server on my \ncomputer. I'm experimenting with fetching single tags in shallow\nclone.\n\nI begin with shallow clone the repo:\n\n$ git clone https://<myhost>/path/to/go.git --depth 200 golang\n$ cd golang\n\nBecause only one, default branch (master) is checked out on shallow \nclone, I fetch latest release branch shallowly:\n\n$ git remote set-branches --add origin release-branch.go1.16\n$ git fetch origin release-branch.go1.16 --depth 25\n\nThen I fetch single tag only, that is latest tagged release:\n\n$ git fetch origin tag go1.16.4 --no-tags\n> From https://<myhost>/path/to/go\n>  * [new tag]           go1.16.4   -> go1.16.4\n\nThat above worked, because the commit the tag refers to is already on \nthe clone.\n\nBut when I fetch a single tag which the commit the tag refers to isn't \nalready on the clone, Git fetched almost the entire history (thus almost \nunshallow the clone):\n\n$ git fetch origin tag go1.16.1 --no-tags\n> remote: Enumerating objects: 436644, done.\n> remote: Counting objects: 100% (427655/427655), done.\n> remote: Compressing objects: 100% (75334/75334), done.\n> remote: Total 419698 (delta 343975), reused 416121 (delta 341201), pack-reused 0\n> Receiving objects: 100% (419698/419698), 146.94 MiB | 16.06 MiB/s, done.\n> Resolving deltas: 100% (343975/343975), completed with 4892 local objects.\n> From https://gitnode.io/bagas/go\n>  * [new tag]           go1.16.1   -> go1.16.1\n\nI expect that instead Git will deepen the shallow clone until the \nspecified tag.\n\nNote that I used \"almost unshallow\" phrase, because although almost the \nwhole history had been fetched, `.git/shallow` still exists, meant that \nthe clone was still shallow. To convert to full clone, I did `git fetch \n--unshallow`, which also fetched tags referenced on either master or \nalready configured released branches.\n\nThanks.\n\n[1]: https://github.com/golang/go\n-- \nAn old man doll... just what I always wanted! - Clara\n"},{"id":"425765","messageId":"d641512e-657f-6dfc-adf4-1b1889439553@gmail.com","threadId":"55790","inReplyTo":"304633fd-e677-7956-6787-f60f195db9b5@gmail.com","subject":"Re: Fetching single tag in shallow clone almost unshallow the clone","fromName":"Derrick Stolee","fromEmail":"stolee@gmail.com","sentAt":"2021-05-28T11:40:54Z","receivedAt":"2021-05-28T11:41:11Z","isPatch":false,"sender":{"key":"stolee@gmail.com","avatar":"https://avatars.githubusercontent.com/u/570044?v=4"},"body":"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):\n> \n> $ git fetch origin tag go1.16.1 --no-tags\n\nYou should add a --depth here, too. Git doesn't remember that you want\na certain depth, because that doesn't work in perpetuity.\n\nYou are hitting the issue I documented in my comparison between partial\nand shallow clones [1]: The commit history for go1.16.1 goes \"around\"\nyour shallow boundary. See the image immediately above the \"Comparing\nClone Options\" section.\n\n[1] https://github.blog/2020-12-21-get-up-to-speed-with-partial-clone-and-shallow-clone/#user-content-shallow-clones\n\nThanks,\n-Stolee\n"},{"id":"425798","messageId":"524c529d-e2f3-3432-55c5-cb05fe8ecf02@gmail.com","threadId":"55790","inReplyTo":"d641512e-657f-6dfc-adf4-1b1889439553@gmail.com","subject":"Re: Fetching single tag in shallow clone almost unshallow the clone","fromName":"Bagas Sanjaya","fromEmail":"bagasdotme@gmail.com","sentAt":"2021-05-28T12:46:44Z","receivedAt":"2021-05-28T12:46:51Z","isPatch":false,"sender":{"key":"bagasdotme@gmail.com","avatar":"https://avatars.githubusercontent.com/u/40219486?v=4"},"body":"Hi,\n\n> You should add a --depth here, too. Git doesn't remember that you want\n> a certain depth, because that doesn't work in perpetuity.\n> \n\nOK. I can specify --depth that I want, but often I forget how deep my \nclone when fetching tag with --depth, so that it has the same depth as \nbefore fetching tag. What should I do?\n\n> You are hitting the issue I documented in my comparison between partial\n> and shallow clones [1]: The commit history for go1.16.1 goes \"around\"\n> your shallow boundary. See the image immediately above the \"Comparing\n> Clone Options\" section.\n> \n> [1] https://github.blog/2020-12-21-get-up-to-speed-with-partial-clone-and-shallow-clone/#user-content-shallow-clones\n\nSo basically when I request fetching something out of shallow boundary, \nGit \"unshallow\" by fetching the whole remaining history (but not implies \n--unshallow).\n\nI found out that shallow clones perform on repos that have linear \nhistory policy (that is no merge commits). For example, on linear \nhistory repo, deepening shallow clone with `git fetch --deepen <n>` \ndeepens the shallow boundary by <n> commits, whereas on repo with merge \ncommits, doing the same may drastically zig-zag number of commits on the \nclone (at one instance can be more commits, at the other can be fewer).\n\n-- \nAn old man doll... just what I always wanted! - Clara\n"}]}