{"thread":{"id":"29007","subject":"git fetch overwriting local tags","startedAt":"2011-11-23T09:08:21Z","lastAt":"2011-11-24T07:07:28Z","messageCount":3,"participants":["Uwe Kleine-König","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"179870","messageId":"20111123090821.GL19986@pengutronix.de","threadId":"29007","inReplyTo":null,"subject":"git fetch overwriting local tags","fromName":"Uwe Kleine-König","fromEmail":"u.kleine-koenig@pengutronix.de","sentAt":"2011-11-23T09:08:21Z","receivedAt":"2011-11-23T09:08:21Z","isPatch":false,"sender":{"key":"u.kleine-koenig@pengutronix.de","avatar":"https://gravatar.com/avatar/354b5e3ceb2806a2f1e1e382ac29ddbdad18288654da62b61eb13583a857eee7?d=mp&s=160"},"body":"Hello,\n\nJohn and I wondered about git fetch overwriting local tags. I was sure\nenough to claim that git fetch won't overwrite local tags with remote\ntags having the same name. But after John pointed me to\n\n\thttp://www.pythian.com/news/9067/on-the-perils-of-importing-remote-tags-in-git/\n\nI tested that (using Debian's 1.7.7.3) and really, git does overwrite\nlocal tags.\n\nHere is my test script:\n\n\tmkdir a\n\tcd a\n\techo some content > some_file\n\tgit init \n\tgit add some_file\n\tgit commit -m 'some commit log'\n\tgit tag some_tag\n\n\tcd ..\n\n\tmkdir b\n\tcd b\n\techo some different content > another_file\n\tgit init \n\tgit add another_file\n\tgit commit -m 'another commit log'\n\tgit tag some_tag\n\n\tgit fetch --tags ../a\n\nAfter that I have:\n\n\tgit log -1 --oneline some_tag\n\tc4ad89a some commit log\n\nso b's tag was overwritten.\n\nIs this intended?\n\nBest regards\nUwe\n\n-- \nPengutronix e.K.                           | Uwe Kleine-König            |\nIndustrial Linux Solutions                 | http://www.pengutronix.de/  |\n"},{"id":"179919","messageId":"20111123221658.GA22313@sigill.intra.peff.net","threadId":"29007","inReplyTo":"20111123090821.GL19986@pengutronix.de","subject":"Re: git fetch overwriting local tags","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-11-23T22:16:58Z","receivedAt":"2011-11-23T22:16:58Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Nov 23, 2011 at 10:08:21AM +0100, Uwe Kleine-König wrote:\n\n> John and I wondered about git fetch overwriting local tags. I was sure\n> enough to claim that git fetch won't overwrite local tags with remote\n> tags having the same name. But after John pointed me to\n> \n> \thttp://www.pythian.com/news/9067/on-the-perils-of-importing-remote-tags-in-git/\n> \n> I tested that (using Debian's 1.7.7.3) and really, git does overwrite\n> local tags.\n> \n> Here is my test script:\n> [...]\n> \tgit fetch --tags ../a\n> [...]\n> Is this intended?\n\nSort of.\n\nBy default, \"git fetch\" will \"auto-follow\" tags; if you fetch a commit\nwhich is pointed to by a tag, then git will fetch that tag, too. So\ngenerally, you shouldn't need to specify \"--tags\" at all, because you\nwill already be getting the relevant tags.\n\nThe \"--tags\" option, however, is a short-hand for saying \"fetch all of\nthe tags\", and is equivalent to providing the refspec:\n\n  git fetch ../a refs/tags/*:refs/tags/*\n\nWhich of course will update your local tags with similarly-named ones\nfrom the remote.  So in that sense, there is no bug, and it is working\nas intended; the problem is that the author's intent was not the same as\nyour intent. :)\n\nI'm not sure why you're using \"--tags\" in the first place. That might\nhelp us figure out if there's another way to do what you want that is\nsafer.\n\nThat being said, it would be nice if \"--tags\" wasn't so surprising.\nThree things that I think could help are:\n\n  1. We usually require a \"+\" on the refspec (or \"--force\") to update\n     non-fast-forward branches. But there is no such safety on tags\n     (which generally shouldn't be updated at all). Should we at least\n     be enforcing the same fast-forward rules on tag fetches (or even\n     something more strict, like forbidding tag update at all unless\n     forced)?\n\n  2. We don't keep a reflog on tags. Generally there's no point. But\n     it wouldn't be very expensive (since they don't usually change),\n     and could provide a safety mechanism here.\n\n  3. Keeping tags from remotes in separate namespaces, but collating\n     them at lookup time. This has been discussed, and I think is\n     generally a fine idea, but nobody has moved forward with code.\n\n-Peff\n"},{"id":"179929","messageId":"20111124070728.GR19986@pengutronix.de","threadId":"29007","inReplyTo":"20111123221658.GA22313@sigill.intra.peff.net","subject":"Re: git fetch overwriting local tags","fromName":"Uwe Kleine-König","fromEmail":"u.kleine-koenig@pengutronix.de","sentAt":"2011-11-24T07:07:28Z","receivedAt":"2011-11-24T07:07:28Z","isPatch":false,"sender":{"key":"u.kleine-koenig@pengutronix.de","avatar":"https://gravatar.com/avatar/354b5e3ceb2806a2f1e1e382ac29ddbdad18288654da62b61eb13583a857eee7?d=mp&s=160"},"body":"Hi Jeff,\n\nOn Wed, Nov 23, 2011 at 05:16:58PM -0500, Jeff King wrote:\n> On Wed, Nov 23, 2011 at 10:08:21AM +0100, Uwe Kleine-König wrote:\n> \n> > John and I wondered about git fetch overwriting local tags. I was sure\n> > enough to claim that git fetch won't overwrite local tags with remote\n> > tags having the same name. But after John pointed me to\n> > \n> > \thttp://www.pythian.com/news/9067/on-the-perils-of-importing-remote-tags-in-git/\n> > \n> > I tested that (using Debian's 1.7.7.3) and really, git does overwrite\n> > local tags.\n> > \n> > Here is my test script:\n> > [...]\n> > \tgit fetch --tags ../a\n> > [...]\n> > Is this intended?\n> \n> Sort of.\n> \n> By default, \"git fetch\" will \"auto-follow\" tags; if you fetch a commit\n> which is pointed to by a tag, then git will fetch that tag, too. So\n> generally, you shouldn't need to specify \"--tags\" at all, because you\n> will already be getting the relevant tags.\nHmm, if I do:\n\n        mkdir a\n        cd a\n        echo some content > some_file\n        git init\n        git add some_file\n        git commit -m 'some commit log'\n        git tag some_tag\n\n        cd ..\n\n        mkdir b\n        cd b\n        echo some different content > another_file\n        git init\n        git add another_file\n        git commit -m 'another commit log'\n\n\tgit fetch ../a\n\nI don't get the tag. That's why I added --tags. I guess that's because\nsome_tag is a lightweight tag. Hmm, but even if I change the command to\ncreate the tag to\n\n\tgit tag -a -m 'tag desc' some_tag\n\nI don't get it without --tags?!\n\n> The \"--tags\" option, however, is a short-hand for saying \"fetch all of\n> the tags\", and is equivalent to providing the refspec:\n> \n>   git fetch ../a refs/tags/*:refs/tags/*\n> \n> Which of course will update your local tags with similarly-named ones\n> from the remote.  So in that sense, there is no bug, and it is working\n> as intended; the problem is that the author's intent was not the same as\n> your intent. :)\n> \n> I'm not sure why you're using \"--tags\" in the first place. That might\n> help us figure out if there's another way to do what you want that is\n> safer.\n> \n> That being said, it would be nice if \"--tags\" wasn't so surprising.\n> Three things that I think could help are:\n> \n>   1. We usually require a \"+\" on the refspec (or \"--force\") to update\n>      non-fast-forward branches. But there is no such safety on tags\n>      (which generally shouldn't be updated at all). Should we at least\n>      be enforcing the same fast-forward rules on tag fetches (or even\n>      something more strict, like forbidding tag update at all unless\n>      forced)?\nThat sounds fine for me.\n\n>   2. We don't keep a reflog on tags. Generally there's no point. But\n>      it wouldn't be very expensive (since they don't usually change),\n>      and could provide a safety mechanism here.\nI prefer 1, but that would be better than the current situation at\nleast.\n \n>   3. Keeping tags from remotes in separate namespaces, but collating\n>      them at lookup time. This has been discussed, and I think is\n>      generally a fine idea, but nobody has moved forward with code.\nThat's something that John said in our discussion, too. That's the\nsuggestion I like the most.\n\nBest regards and thanks for your time,\nUwe\n\n-- \nPengutronix e.K.                           | Uwe Kleine-König            |\nIndustrial Linux Solutions                 | http://www.pengutronix.de/  |\n"}]}