{"thread":{"id":"46611","subject":"git fetch with refspec does not include tags?","startedAt":"2017-08-17T09:03:07Z","lastAt":"2017-08-20T15:52:03Z","messageCount":12,"participants":["Carlsson, Magnus","Jeff King","Junio C Hamano","Kevin Daudt"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"326590","messageId":"1502960572292.1402@arris.com","threadId":"46611","inReplyTo":"1502960406180.9006@arris.com","subject":"git fetch with refspec does not include tags?","fromName":"Carlsson, Magnus","fromEmail":"magnus.carlsson@arris.com","sentAt":"2017-08-17T09:02:52Z","receivedAt":"2017-08-17T09:03:07Z","isPatch":false,"sender":{"key":"magnus.carlsson@arris.com","avatar":null},"body":"Hi​\n\nIn the git fetch documentation it states that by default you will fetch all tags that point into the history to the branches fetched.\n\n\"By default, any tag that points into the histories being fetched is also fetched; the effect is to fetch tags that point at branches that you are interested in. This default behavior can be changed by using the --tags or --no-tags options or by configuring remote..tagOpt. By using a refspec that fetches tags explicitly, you can fetch tags that do not point into branches you are interested in as well.\"\n\nBut for me I get tags if I do \"git fetch\" or \"git fetch origin\" but if I do \"git fetch origin master\" I don't get tags related to the master branch.\n\nI understand that this might be due to me specifying a refspec and then it will only get that exact refspec, but for me it's not that clear from the documentation what I should expect. I read it as when I fetch something all related tags will come along.\n\nUsing: git version 2.13.0.rc1.15.gd2bbb7c\n\n-- Magnus\n\nMAGNUS CARLSSON\nStaff Software Engineer\nARRIS\n\no: +46 13 36 75 92\ne: magnus.carlsson@arris.com\nw: www.arris.com\n\nARRIS:  Legal entity: Arris Sweden AB - Registered Office: Teknikringen 2, 583 30 Linkoping, Sweden - Reg No:556518-5831 - VAT No:SE 556518-583\n\nThis electronic transmission (and any attached document) is for the sole use of the individual or entity to whom it is addressed.  It is confidential and may be attorney-client privileged.  In any event the Sender reserves, to the fullest extent, any \"legal advice privilege\".  Any further distribution or copying of this message is strictly prohibited.  If you received this message in error, please notify the Sender immediately and destroy the attached message (and all attached documents).\n "},{"id":"326593","messageId":"20170817092853.hteuzni5lxia4ejf@sigill.intra.peff.net","threadId":"46611","inReplyTo":"1502960572292.1402@arris.com","subject":"Re: git fetch with refspec does not include tags?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2017-08-17T09:28:54Z","receivedAt":"2017-08-17T09:29:03Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Aug 17, 2017 at 09:02:52AM +0000, Carlsson, Magnus wrote:\n\n> In the git fetch documentation it states that by default you will\n> fetch all tags that point into the history to the branches fetched.\n> \n> \"By default, any tag that points into the histories being fetched is\n> also fetched; the effect is to fetch tags that point at branches that\n> you are interested in. This default behavior can be changed by using\n> the --tags or --no-tags options or by configuring\n> remote..tagOpt. By using a refspec that fetches tags explicitly,\n> you can fetch tags that do not point into branches you are interested\n> in as well.\"\n> \n> But for me I get tags if I do \"git fetch\" or \"git fetch origin\" but if\n> I do \"git fetch origin master\" I don't get tags related to the master\n> branch.\n> \n> I understand that this might be due to me specifying a refspec and\n> then it will only get that exact refspec, but for me it's not that\n> clear from the documentation what I should expect. I read it as when I\n> fetch something all related tags will come along.\n\nI'll admit that our tag-autofollow behavior has often confused me. So\nI'll try to untangle what's happening at least if not the reasoning. :)\n\nI think the problem is not that you have a refspec, but that your\nrefspec has no destination. Looking at the fetch code, we seem to turn\non autotags only when the destination is a \"real\" ref and not just the\ndefault FETCH_HEAD. Which sort-of makes sense. If you're doing a one-off\ninto FETCH_HEAD, you probably don't want to create tags, even if you\nhave the objects they point to.\n\nBut this is further complicated by the opportunistic tracking-ref\nupdates. You can see some interesting behavior with a setup like this:\n\n git init parent\n git -C parent commit --allow-empty -m one &&\n git -C parent tag -m foo mytag\n\n git init child\n cd child\n git remote add origin ../parent\n\nand then:\n\n # no tags, we just populate FETCH_HEAD because of the bare URL\n git fetch ../parent\n\n # this does fetch tags, because we're storing the result according to\n # the configured refspec (\"refs/heads/*:refs/remotes/origin/*\").\n git fetch origin\n\n # this doesn't fetch tags, as the main command is \"just\" populating\n # FETCH_HEAD. But then our logic for \"hey, we fetched the ref for\n # refs/remotes/origin/master, so let's update it on the side\" kicks\n # in. And we end up updating FETCH_HEAD _and_ the tracking branch, but\n # not the tags. Weird.\n git fetch origin master\n\n # and this one does fetch tags, because we have a real destination.\n git fetch origin master:foo\n\nSo what I'd say is:\n\n 1. Definitely these defaults are under-documented. I couldn't find\n them anywhere in git-fetch(1).\n\n 2. If we continue to follow the \"are we storing any refs\" rule for the\n default, possibly it should expand to \"did we store anything,\n including opportunistic tracking-ref updates\".\n\n-Peff\n"},{"id":"326602","messageId":"1502969387926.66865@arris.com","threadId":"46611","inReplyTo":"20170817092853.hteuzni5lxia4ejf@sigill.intra.peff.net","subject":"Re: git fetch with refspec does not include tags?","fromName":"Carlsson, Magnus","fromEmail":"magnus.carlsson@arris.com","sentAt":"2017-08-17T11:29:48Z","receivedAt":"2017-08-17T11:30:00Z","isPatch":false,"sender":{"key":"magnus.carlsson@arris.com","avatar":null},"body":"Thanks for your quick answer!\n\n> 1. Definitely these defaults are under-documented. I couldn't find\n> them anywhere in git-fetch(1).\n\nYes, some sort of explanation would be good, especially since one of the first sentences state that you always get relevant tags.\n\n> 2. If we continue to follow the \"are we storing any refs\" rule for the\n> default, possibly it should expand to \"did we store anything,\n> including opportunistic tracking-ref updates\".\n\nPersonally I think that I would prefer to always fetch relevant tags. If I don't want tags I can simply use the \"--no-tags\"\n\n-- Magnus\n\n\nMAGNUS CARLSSON\nStaff Software Engineer\nARRIS\n\no: +46 13 36 75 92\ne: magnus.carlsson@arris.com\nw: www.arris.com\n\nARRIS: Legal entity: Arris Sweden AB - Registered Office: Teknikringen 2, 583 30 Linkoping, Sweden - Reg No:556518-5831 - VAT No:SE 556518-583\n\nThis electronic transmission (and any attached document) is for the sole use of the individual or entity to whom it is addressed. It is confidential and may be attorney-client privileged. In any event the Sender reserves, to the fullest extent, any \"legal advice privilege\". Any further distribution or copying of this message is strictly prohibited. If you received this message in error, please notify the Sender immediately and destroy the attached message (and all attached documents).\n\n________________________________________\nFrom: Jeff King \nSent: Thursday, August 17, 2017 11:28\nTo: Carlsson, Magnus\nCc: git@vger.kernel.org\nSubject: Re: git fetch with refspec does not include tags?\n\nOn Thu, Aug 17, 2017 at 09:02:52AM +0000, Carlsson, Magnus wrote:\n\n> In the git fetch documentation it states that by default you will\n> fetch all tags that point into the history to the branches fetched.\n>\n> \"By default, any tag that points into the histories being fetched is\n> also fetched; the effect is to fetch tags that point at branches that\n> you are interested in. This default behavior can be changed by using\n> the --tags or --no-tags options or by configuring\n> remote..tagOpt. By using a refspec that fetches tags explicitly,\n> you can fetch tags that do not point into branches you are interested\n> in as well.\"\n>\n> But for me I get tags if I do \"git fetch\" or \"git fetch origin\" but if\n> I do \"git fetch origin master\" I don't get tags related to the master\n> branch.\n>\n> I understand that this might be due to me specifying a refspec and\n> then it will only get that exact refspec, but for me it's not that\n> clear from the documentation what I should expect. I read it as when I\n> fetch something all related tags will come along.\n\nI'll admit that our tag-autofollow behavior has often confused me. So\nI'll try to untangle what's happening at least if not the reasoning. :)\n\nI think the problem is not that you have a refspec, but that your\nrefspec has no destination. Looking at the fetch code, we seem to turn\non autotags only when the destination is a \"real\" ref and not just the\ndefault FETCH_HEAD. Which sort-of makes sense. If you're doing a one-off\ninto FETCH_HEAD, you probably don't want to create tags, even if you\nhave the objects they point to.\n\nBut this is further complicated by the opportunistic tracking-ref\nupdates. You can see some interesting behavior with a setup like this:\n\n git init parent\n git -C parent commit --allow-empty -m one &&\n git -C parent tag -m foo mytag\n\n git init child\n cd child\n git remote add origin ../parent\n\nand then:\n\n # no tags, we just populate FETCH_HEAD because of the bare URL\n git fetch ../parent\n\n # this does fetch tags, because we're storing the result according to\n # the configured refspec (\"refs/heads/*:refs/remotes/origin/*\").\n git fetch origin\n\n # this doesn't fetch tags, as the main command is \"just\" populating\n # FETCH_HEAD. But then our logic for \"hey, we fetched the ref for\n # refs/remotes/origin/master, so let's update it on the side\" kicks\n # in. And we end up updating FETCH_HEAD _and_ the tracking branch, but\n # not the tags. Weird.\n git fetch origin master\n\n # and this one does fetch tags, because we have a real destination.\n git fetch origin master:foo\n\nSo what I'd say is:\n\n 1. Definitely these defaults are under-documented. I couldn't find\n them anywhere in git-fetch(1).\n\n 2. If we continue to follow the \"are we storing any refs\" rule for the\n default, possibly it should expand to \"did we store anything,\n including opportunistic tracking-ref updates\".\n\n-Peff\n"},{"id":"326604","messageId":"20170817142233.v2c534zh6wv7ttei@sigill.intra.peff.net","threadId":"46611","inReplyTo":"1502969387926.66865@arris.com","subject":"Re: git fetch with refspec does not include tags?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2017-08-17T14:22:33Z","receivedAt":"2017-08-17T14:22:40Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Aug 17, 2017 at 11:29:48AM +0000, Carlsson, Magnus wrote:\n\n> > 2. If we continue to follow the \"are we storing any refs\" rule for the\n> > default, possibly it should expand to \"did we store anything,\n> > including opportunistic tracking-ref updates\".\n> \n> Personally I think that I would prefer to always fetch relevant tags.\n> If I don't want tags I can simply use the \"--no-tags\"\n\nI think it's a bit more complex because \"git pull\" uses \"git fetch\"\nunder the hood. In fact, your \"git fetch origin master\" is exactly what\ngets run when you do:\n\n git pull origin master\n\nThat's maybe OK. But I think one-off pulls like:\n\n git pull https://example.com/repo.git master\n\nprobably wouldn't want it. I'd have to give it some thought.\n\n-Peff\n"},{"id":"326628","messageId":"xmqq1soagf1p.fsf@gitster.mtv.corp.google.com","threadId":"46611","inReplyTo":"20170817092853.hteuzni5lxia4ejf@sigill.intra.peff.net","subject":"Re: git fetch with refspec does not include tags?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-08-17T19:38:58Z","receivedAt":"2017-08-17T19:39:12Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> # no tags, we just populate FETCH_HEAD because of the bare URL\n> git fetch ../parent\n>\n> # this does fetch tags, because we're storing the result according to\n> # the configured refspec (\"refs/heads/*:refs/remotes/origin/*\").\n> git fetch origin\n\nThe above two look good.\n\n> # this doesn't fetch tags, as the main command is \"just\" populating\n> # FETCH_HEAD. But then our logic for \"hey, we fetched the ref for\n> # refs/remotes/origin/master, so let's update it on the side\" kicks\n> # in. And we end up updating FETCH_HEAD _and_ the tracking branch, but\n> # not the tags. Weird.\n> git fetch origin master\n\nYes, it looks weird, but I suspect that it is probably more correct\nnot to fetch tags in this case. I wonder if it would be a solution\nnot to do the \"on the side\" thing---after all the user didn't tell\nus to update refs/remotes/origin/master with this command line.\n\nThen not following tags will be in line with all of the above\nreasoning above.\n\n> # and this one does fetch tags, because we have a real destination.\n> git fetch origin master:foo\n\nYup, that is expected.\n\n> So what I'd say is:\n>\n> 1. Definitely these defaults are under-documented. I couldn't find\n> them anywhere in git-fetch(1).\n\nYup.\n\n> 2. If we continue to follow the \"are we storing any refs\" rule for the\n> default, possibly it should expand to \"did we store anything,\n> including opportunistic tracking-ref updates\".\n\nThat also is a workable way to make things consistent.\n"},{"id":"326629","messageId":"xmqqwp62f0dm.fsf@gitster.mtv.corp.google.com","threadId":"46611","inReplyTo":"20170817142233.v2c534zh6wv7ttei@sigill.intra.peff.net","subject":"Re: git fetch with refspec does not include tags?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-08-17T19:41:09Z","receivedAt":"2017-08-17T19:41:22Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> I think it's a bit more complex because \"git pull\" uses \"git fetch\"\n> under the hood. In fact, your \"git fetch origin master\" is exactly what\n> gets run when you do:\n>\n> git pull origin master\n>\n> That's maybe OK. But I think one-off pulls like:\n>\n> git pull https://example.com/repo.git master\n>\n> probably wouldn't want it. I'd have to give it some thought.\n\nI agree with both. If you have named remote, you presumably are\nkeeping copies of their branches as remote-tracking branches, and it\nmay be fine to follow tags. An explicit URL used for one-off should\nnot grab anything but the named thing, I would think.\n"},{"id":"326634","messageId":"20170817202257.GC3839@alpha.vpn.ikke.info","threadId":"46611","inReplyTo":"xmqq1soagf1p.fsf@gitster.mtv.corp.google.com","subject":"Re: git fetch with refspec does not include tags?","fromName":"Kevin Daudt","fromEmail":"me@ikke.info","sentAt":"2017-08-17T20:22:57Z","receivedAt":"2017-08-17T20:23:51Z","isPatch":false,"sender":{"key":"me@ikke.info","avatar":"https://avatars.githubusercontent.com/u/135698?v=4"},"body":"On Thu, Aug 17, 2017 at 12:38:58PM -0700, Junio C Hamano wrote:\n> Jeff King writes:\n> \n> > # no tags, we just populate FETCH_HEAD because of the bare URL\n> > git fetch ../parent\n> >\n> > # this does fetch tags, because we're storing the result according to\n> > # the configured refspec (\"refs/heads/*:refs/remotes/origin/*\").\n> > git fetch origin\n> \n> The above two look good.\n> \n> > # this doesn't fetch tags, as the main command is \"just\" populating\n> > # FETCH_HEAD. But then our logic for \"hey, we fetched the ref for\n> > # refs/remotes/origin/master, so let's update it on the side\" kicks\n> > # in. And we end up updating FETCH_HEAD _and_ the tracking branch, but\n> > # not the tags. Weird.\n> > git fetch origin master\n> \n> Yes, it looks weird, but I suspect that it is probably more correct\n> not to fetch tags in this case. I wonder if it would be a solution\n> not to do the \"on the side\" thing---after all the user didn't tell\n> us to update refs/remotes/origin/master with this command line.\n\nIsn't that how git fetch used to behave, or am I misunderstanding what\nyou mean? It used to be that git fetch would not\nupdate any remote tracking branches.\n\nFrom the 1.8.4 release notes:\n\n> \"git fetch origin master\" unlike \"git fetch origin\" or \"git fetch\"\n> did not update \"refs/remotes/origin/master\"; this was an early\n> design decision to keep the update of remote tracking branches\n> predictable, but in practice it turns out that people find it more\n> convenient to opportunistically update them whenever we have a\n> chance, and we have been updating them when we run \"git push\" which\n> already breaks the original \"predictability\" anyway.\n\n"},{"id":"326637","messageId":"xmqqk222expv.fsf@gitster.mtv.corp.google.com","threadId":"46611","inReplyTo":"20170817202257.GC3839@alpha.vpn.ikke.info","subject":"Re: git fetch with refspec does not include tags?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-08-17T20:38:36Z","receivedAt":"2017-08-17T20:38:49Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Kevin Daudt writes:\n\n> On Thu, Aug 17, 2017 at 12:38:58PM -0700, Junio C Hamano wrote:\n>> Jeff King writes:\n>> \n>> > # no tags, we just populate FETCH_HEAD because of the bare URL\n>> > git fetch ../parent\n>> >\n>> > # this does fetch tags, because we're storing the result according to\n>> > # the configured refspec (\"refs/heads/*:refs/remotes/origin/*\").\n>> > git fetch origin\n>> \n>> The above two look good.\n>> \n>> > # this doesn't fetch tags, as the main command is \"just\" populating\n>> > # FETCH_HEAD. But then our logic for \"hey, we fetched the ref for\n>> > # refs/remotes/origin/master, so let's update it on the side\" kicks\n>> > # in. And we end up updating FETCH_HEAD _and_ the tracking branch, but\n>> > # not the tags. Weird.\n>> > git fetch origin master\n>> \n>> Yes, it looks weird, but I suspect that it is probably more correct\n>> not to fetch tags in this case. I wonder if it would be a solution\n>> not to do the \"on the side\" thing---after all the user didn't tell\n>> us to update refs/remotes/origin/master with this command line.\n>\n> Isn't that how git fetch used to behave, or am I misunderstanding what\n> you mean? It used to be that git fetch would not\n> update any remote tracking branches.\n>\n> From the 1.8.4 release notes:\n>\n>> \"git fetch origin master\" unlike \"git fetch origin\" or \"git fetch\"\n>> did not update \"refs/remotes/origin/master\"; this was an early\n>> design decision to keep the update of remote tracking branches\n>> predictable, but in practice it turns out that people find it more\n>> convenient to opportunistically update them whenever we have a\n>> chance, and we have been updating them when we run \"git push\" which\n>> already breaks the original \"predictability\" anyway.\n\nNo, you are not misunderstanding anything. The \"pretend that we\nimmediately turned around and fetched\" done by \"git push\" was\nalready breaking the predictability, but the change in 1.8.4 made it\neven worse. I am saying that going back to the old behaviour may be\none option to address the issue being discussed in this thread.\n\n"},{"id":"326638","messageId":"20170817204312.GD3839@alpha.vpn.ikke.info","threadId":"46611","inReplyTo":"xmqqk222expv.fsf@gitster.mtv.corp.google.com","subject":"Re: git fetch with refspec does not include tags?","fromName":"Kevin Daudt","fromEmail":"me@ikke.info","sentAt":"2017-08-17T20:43:12Z","receivedAt":"2017-08-17T20:44:04Z","isPatch":false,"sender":{"key":"me@ikke.info","avatar":"https://avatars.githubusercontent.com/u/135698?v=4"},"body":"On Thu, Aug 17, 2017 at 01:38:36PM -0700, Junio C Hamano wrote:\n> Kevin Daudt writes:\n> \n> > On Thu, Aug 17, 2017 at 12:38:58PM -0700, Junio C Hamano wrote:\n> >> Jeff King writes:\n> >> \n> >> > # no tags, we just populate FETCH_HEAD because of the bare URL\n> >> > git fetch ../parent\n> >> >\n> >> > # this does fetch tags, because we're storing the result according to\n> >> > # the configured refspec (\"refs/heads/*:refs/remotes/origin/*\").\n> >> > git fetch origin\n> >> \n> >> The above two look good.\n> >> \n> >> > # this doesn't fetch tags, as the main command is \"just\" populating\n> >> > # FETCH_HEAD. But then our logic for \"hey, we fetched the ref for\n> >> > # refs/remotes/origin/master, so let's update it on the side\" kicks\n> >> > # in. And we end up updating FETCH_HEAD _and_ the tracking branch, but\n> >> > # not the tags. Weird.\n> >> > git fetch origin master\n> >> \n> >> Yes, it looks weird, but I suspect that it is probably more correct\n> >> not to fetch tags in this case. I wonder if it would be a solution\n> >> not to do the \"on the side\" thing---after all the user didn't tell\n> >> us to update refs/remotes/origin/master with this command line.\n> >\n> > Isn't that how git fetch used to behave, or am I misunderstanding what\n> > you mean? It used to be that git fetch would not\n> > update any remote tracking branches.\n> >\n> > From the 1.8.4 release notes:\n> >\n> >> \"git fetch origin master\" unlike \"git fetch origin\" or \"git fetch\"\n> >> did not update \"refs/remotes/origin/master\"; this was an early\n> >> design decision to keep the update of remote tracking branches\n> >> predictable, but in practice it turns out that people find it more\n> >> convenient to opportunistically update them whenever we have a\n> >> chance, and we have been updating them when we run \"git push\" which\n> >> already breaks the original \"predictability\" anyway.\n> \n> No, you are not misunderstanding anything. The \"pretend that we\n> immediately turned around and fetched\" done by \"git push\" was\n> already breaking the predictability, but the change in 1.8.4 made it\n> even worse. I am saying that going back to the old behaviour may be\n> one option to address the issue being discussed in this thread.\n> \n\nOk. The reason I'm bring this up is because we often had to tell users\nin the irc channel that git fetch did not update the\nremote tracking branches, which confused them, so reverting back might\nreintroduce this confusion again.\n"},{"id":"326796","messageId":"20170820074728.4dawjlnaufjdf4j5@sigill.intra.peff.net","threadId":"46611","inReplyTo":"20170817204312.GD3839@alpha.vpn.ikke.info","subject":"Re: git fetch with refspec does not include tags?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2017-08-20T07:47:28Z","receivedAt":"2017-08-20T07:47:35Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Aug 17, 2017 at 10:43:12PM +0200, Kevin Daudt wrote:\n\n> > No, you are not misunderstanding anything. The \"pretend that we\n> > immediately turned around and fetched\" done by \"git push\" was\n> > already breaking the predictability, but the change in 1.8.4 made it\n> > even worse. I am saying that going back to the old behaviour may be\n> > one option to address the issue being discussed in this thread.\n> \n> Ok. The reason I'm bring this up is because we often had to tell users\n> in the irc channel that git fetch did not update the\n> remote tracking branches, which confused them, so reverting back might\n> reintroduce this confusion again.\n\nYeah, I don't think we want to go back to the original behavior. I agree\nthat it is partially to blame for the inconsistency that started this\nthread, but I think on balance it has saved much more confusion than it\nhas started. And we can address that inconsistency with better tag rules\n(like the \"autofollow if we wrote any real refs\" thing).\n\nI don't have a patch for that yet, so if anybody feels like taking a\nlook, it would be much appreciated.\n\n-Peff\n"},{"id":"326797","messageId":"20170820075001.gmsxeh3fh4f2topg@sigill.intra.peff.net","threadId":"46611","inReplyTo":"20170820074728.4dawjlnaufjdf4j5@sigill.intra.peff.net","subject":"Re: git fetch with refspec does not include tags?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2017-08-20T07:50:02Z","receivedAt":"2017-08-20T07:50:08Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Aug 20, 2017 at 03:47:28AM -0400, Jeff King wrote:\n\n> Yeah, I don't think we want to go back to the original behavior. I agree\n> that it is partially to blame for the inconsistency that started this\n> thread, but I think on balance it has saved much more confusion than it\n> has started. And we can address that inconsistency with better tag rules\n> (like the \"autofollow if we wrote any real refs\" thing).\n> \n> I don't have a patch for that yet, so if anybody feels like taking a\n> look, it would be much appreciated.\n\nAlso: I don't think we've seen a patch yet for documenting the current\nauto-follow behavior. Even if we don't make a behavior change, let's\nnot forget to improve that, which should be much less work. :)\n\n-Peff\n"},{"id":"326819","messageId":"xmqq8tie8cfc.fsf@gitster.mtv.corp.google.com","threadId":"46611","inReplyTo":"20170820075001.gmsxeh3fh4f2topg@sigill.intra.peff.net","subject":"Re: git fetch with refspec does not include tags?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-08-20T15:51:51Z","receivedAt":"2017-08-20T15:52:03Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> On Sun, Aug 20, 2017 at 03:47:28AM -0400, Jeff King wrote:\n>\n>> Yeah, I don't think we want to go back to the original behavior. I agree\n>> that it is partially to blame for the inconsistency that started this\n>> thread, but I think on balance it has saved much more confusion than it\n>> has started. And we can address that inconsistency with better tag rules\n>> (like the \"autofollow if we wrote any real refs\" thing).\n>> \n>> I don't have a patch for that yet, so if anybody feels like taking a\n>> look, it would be much appreciated.\n>\n> Also: I don't think we've seen a patch yet for documenting the current\n> auto-follow behavior. Even if we don't make a behavior change, let's\n> not forget to improve that, which should be much less work. :)\n\nThanks for two thoughtful follow-ups.\n"}]}