{"thread":{"id":"50551","subject":"Fetching master branch with tags associated with it","startedAt":"2019-02-21T17:03:14Z","lastAt":"2019-02-22T16:35:30Z","messageCount":3,"participants":["Dominik Salvet","Jeff King","Randall S. Becker"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"369819","messageId":"CAEXP2g92_pnbh4_V8VOgzzdUv6w5eDhCsXf=+NOdsRwyjQUb5A@mail.gmail.com","threadId":"50551","inReplyTo":null,"subject":"Fetching master branch with tags associated with it","fromName":"Dominik Salvet","fromEmail":"dominik.salvet@gmail.com","sentAt":"2019-02-21T17:02:54Z","receivedAt":"2019-02-21T17:03:14Z","isPatch":false,"sender":{"key":"dominik.salvet@gmail.com","avatar":null},"body":"Dear Git community,\nFor quite some time I am trying to solve a problem with fetching the\nmaster branch from a remote with tags that are pointing only to the\nmaster branch.\n\nCloning the master branch of a repository with tags only pointing to\nthat branch is working, though. In this case, the following command\nwill do the work: `git clone --branch master --single-branch <url> .`\n\nNow, I want to refresh the repository the same way - fetching only\ncommits from the master branch and tags that are pointing to the\nmaster branch and also refresh those tags as well in case of their\ntarget commit change at the remote (you can expect that it always\npoints to a master commit). Nevertheless, I don't really know how to\ndo it. The closest I got, are the following commands:\n\n```sh\ngit fetch --tags origin master &&\ngit merge FETCH_HEAD\n```\n\nHowever, there obviously are some problems with this solution. The\n`--tags` flag will cause to fetch tags from all branches. Furthermore,\nit will fetch also their commits, which is absolutely what I don't\nwant to.\n\nI have Git 2.17.1 (on Ubuntu 18.04.2) and in its `git fetch --help` is\nstated, if I understood it correctly, that without passing neither\n`--tags` nor `--no-tags`, it will do exactly what I want.\nNevertheless, without using any of the mentioned flags, it behaves\nmore like using `--no-tags`.\n\nAm I missing something? Do you want any additional information? I\nwould really appreciate your help.\n\nThank you for all your effort\n-- \nDominik Salvet\n"},{"id":"369954","messageId":"20190222160722.GA22531@sigill.intra.peff.net","threadId":"50551","inReplyTo":"CAEXP2g92_pnbh4_V8VOgzzdUv6w5eDhCsXf=+NOdsRwyjQUb5A@mail.gmail.com","subject":"Re: Fetching master branch with tags associated with it","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2019-02-22T16:07:22Z","receivedAt":"2019-02-22T16:07:25Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Feb 21, 2019 at 06:02:54PM +0100, Dominik Salvet wrote:\n\n> Now, I want to refresh the repository the same way - fetching only\n> commits from the master branch and tags that are pointing to the\n> master branch and also refresh those tags as well in case of their\n> target commit change at the remote (you can expect that it always\n> points to a master commit). Nevertheless, I don't really know how to\n> do it. The closest I got, are the following commands:\n> \n> ```sh\n> git fetch --tags origin master &&\n> git merge FETCH_HEAD\n> ```\n> \n> However, there obviously are some problems with this solution. The\n> `--tags` flag will cause to fetch tags from all branches. Furthermore,\n> it will fetch also their commits, which is absolutely what I don't\n> want to.\n> \n> I have Git 2.17.1 (on Ubuntu 18.04.2) and in its `git fetch --help` is\n> stated, if I understood it correctly, that without passing neither\n> `--tags` nor `--no-tags`, it will do exactly what I want.\n> Nevertheless, without using any of the mentioned flags, it behaves\n> more like using `--no-tags`.\n\nGenerally yes, that's how it's supposed to work. However, I think\ntag-following does not kick in when you've given a specific refspec.\n\nSo take this toy setup for example:\n\n-- >8 --\ngit init repo\ncd repo\n\n# one tags accessible from master\ngit commit --allow-empty -m one\ngit tag one\n\n# one tag accessible only from \"other\"\ngit checkout -b other\ngit commit --allow-empty -m two\ngit tag two\n\n# now fetch into another repository\ngit init child\ncd child\ngit remote add origin ..\ngit fetch origin master\n-- 8< --\n\nThat won't pick up the \"one\" tag in that final fetch. But if you use the\nnormal configured refspec (but tell it only to grab \"master\"):\n\n  git config remote.origin.fetch refs/heads/master:refs/remotes/origin/master\n  git fetch origin\n\nthen it works. I don't know if there's a less-awkward way to get what\nyou want, though. It really seems like there should be a \"--tags=follow\"\nor similar.\n\n-Peff\n"},{"id":"369957","messageId":"000801d4cacc$981e2ac0$c85a8040$@nexbridge.com","threadId":"50551","inReplyTo":"20190222160722.GA22531@sigill.intra.peff.net","subject":"RE: Fetching master branch with tags associated with it","fromName":"Randall S. Becker","fromEmail":"rsbecker@nexbridge.com","sentAt":"2019-02-22T16:35:11Z","receivedAt":"2019-02-22T16:35:30Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On February 22, 2019 11:07, Jeff King wrote:\n> To: Dominik Salvet <dominik.salvet@gmail.com>\n> Cc: git@vger.kernel.org\n> Subject: Re: Fetching master branch with tags associated with it\n> \n> On Thu, Feb 21, 2019 at 06:02:54PM +0100, Dominik Salvet wrote:\n> \n> > Now, I want to refresh the repository the same way - fetching only\n> > commits from the master branch and tags that are pointing to the\n> > master branch and also refresh those tags as well in case of their\n> > target commit change at the remote (you can expect that it always\n> > points to a master commit). Nevertheless, I don't really know how to\n> > do it. The closest I got, are the following commands:\n> >\n> > ```sh\n> > git fetch --tags origin master &&\n> > git merge FETCH_HEAD\n> > ```\n> >\n> > However, there obviously are some problems with this solution. The\n> > `--tags` flag will cause to fetch tags from all branches. Furthermore,\n> > it will fetch also their commits, which is absolutely what I don't\n> > want to.\n> >\n> > I have Git 2.17.1 (on Ubuntu 18.04.2) and in its `git fetch --help` is\n> > stated, if I understood it correctly, that without passing neither\n> > `--tags` nor `--no-tags`, it will do exactly what I want.\n> > Nevertheless, without using any of the mentioned flags, it behaves\n> > more like using `--no-tags`.\n> \n> Generally yes, that's how it's supposed to work. However, I think tag-\n> following does not kick in when you've given a specific refspec.\n> \n> So take this toy setup for example:\n> \n> -- >8 --\n> git init repo\n> cd repo\n> \n> # one tags accessible from master\n> git commit --allow-empty -m one\n> git tag one\n> \n> # one tag accessible only from \"other\"\n> git checkout -b other\n> git commit --allow-empty -m two\n> git tag two\n> \n> # now fetch into another repository\n> git init child\n> cd child\n> git remote add origin ..\n> git fetch origin master\n> -- 8< --\n> \n> That won't pick up the \"one\" tag in that final fetch. But if you use the normal\n> configured refspec (but tell it only to grab \"master\"):\n> \n>   git config remote.origin.fetch\n> refs/heads/master:refs/remotes/origin/master\n>   git fetch origin\n> \n> then it works. I don't know if there's a less-awkward way to get what you\n> want, though. It really seems like there should be a \"--tags=follow\"\n> or similar.\n\nThis may be restating, but I had a received request a while back to fetch only tags commits known to the repository. The scenario here is as follows:\n\ngit clone --depth=1 url-ish\ngit fetch --depth=1 --tags\n\nThis actually fetches all tags and expands the depth of the repository to the whole history to provide the basis for all of the tags. What I would have anticipated is that the HEAD commit from the depth=1, if it had a tag, would fetch that tag, and then expand the history of the tag in support of it, but only if the tag were signed. If the tag is not signed, I'm not sure that the history to build it is required, since the same argument could be made for the HEAD commit itself. If there was no tag on the HEAD commit, there would be no tag fetched in this situation.\n\nSo to further the request above, a fetch of tags of known unsigned tags seems reasonable, in a depth restricted situation or a branch limited situation. In an island of sparceness situation, with gaps in the history, I can see how git describe would give wildly wrong answers, but having those gaps could break the validation of signed tags anyway.\n\nOf course, my expectations may be completely wrong here.\n\nRegards,\nRandall \n\n"}]}