{"thread":{"id":"2593","subject":"git fetch --tags doesn't quite do what I expect","startedAt":"2005-11-18T19:14:16Z","lastAt":"2005-11-18T22:04:58Z","messageCount":3,"participants":["Tony Luck","Junio C Hamano","Luck, Tony"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"12239","messageId":"12c511ca0511181114jf4ca3c0p195a128fa541b8f2@mail.gmail.com","threadId":"2593","inReplyTo":null,"subject":"git fetch --tags doesn't quite do what I expect","fromName":"Tony Luck","fromEmail":"tony.luck@gmail.com","sentAt":"2005-11-18T19:14:16Z","receivedAt":"2005-11-18T19:14:16Z","isPatch":false,"sender":{"key":"tony.luck@gmail.com","avatar":null},"body":"I've been doing some updating on my git scripts to make use of the features\nthat you have been working hard to put in (thank you). My script to update\nmy local \"linus\" branch from Linus' master branch at kernel.org had a simple\n\"git fetch linus\" (with the appropriate[1] URL and Pull lines in\n.git/refs/remotes/linus)\nfollowed by an unholy piece of script that parsed the output from\n\"git-ls-remote --tags linus\" to see if I had all the latest tags, and\nget them if\nI didn't.\n\nLooking at the manual, I thought that I could just change the \"git\nfetch linus\" to\nbe \"git fetch --tags linus\" and drop the script. But it appears that\nwith the \"--tags\"\nargument the \"fetch\" will not fetch anything beyond the tagged commits (i.e.\nat the moment v2.6.15-rc1) ... so I need both:\n git fetch --tags linus\nand\n git fetch linus\n\none to get any new tags, and the other to fetch all the way up to \"master\".\n\nIs this intended behaivour? If so, the \"--tags\" entry on the git-fetch(1) man\npage needs a little extra text to say that --tags limits the fetch to only\ncommits reachable from the tags.\n\n\n-Tony\n\n[1] Contents:\nURL: master.kernel.org:/pub/scm/linux/kernel/git/torvalds/linux-2.6.git\nPull: master:linus\n"},{"id":"12241","messageId":"7v1x1diuuy.fsf@assigned-by-dhcp.cox.net","threadId":"2593","inReplyTo":"12c511ca0511181114jf4ca3c0p195a128fa541b8f2@mail.gmail.com","subject":"Re: git fetch --tags doesn't quite do what I expect","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-11-18T20:06:29Z","receivedAt":"2005-11-18T20:06:29Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Tony Luck writes:\n\n> Is this intended behaivour? If so, the \"--tags\" entry on the\n> git-fetch(1) man page needs a little extra text to say that\n> --tags limits the fetch to only commits reachable from the\n> tags.\n\nI think both Linus (who did the initial implementation of \"git\nfetch --tags\") and I are in \"tags do not matter until you care\"\ncamp, and the expected usage pattern is that you frequently do\n\"git fetch\" or \"git pull\", but \"git fetch --tags\" is done only\nevery once in a while, just to give you known anchors to compare\nagainst or specify a known bottom for log, whatchanged and\nfriends. The branch heads are necessary for your day to day\nwork, the tags are less essential. That is what I mean by \"tags\ndo not matter until you care\".\n\nA tag usually points at somewhere in the commit chain leading to\nbranch heads [*1*], and if your branch heads are up to date,\n\"git fetch --tags\" does not download anything other than the\ntags themselves, finds the commits they point at are already\navailable and complete, and stops there.\n\nNow it happens that \"git fetch --tags\" slurps commits you do not\nyet have _if_ your branch heads are behind, because git barebone\nPorcelain is designed to keep your object database complete\n(i.e. it does not just fetch and store tags under refs/tags/\nwithout making sure you have everything they connect to). What\nyou saw that is a side effect of the above design assumption.\n\nI am not good at documenting things, so I'd appreciate if\nsomebody paraphrased the above and send it back to me in a patch\nform to update the document ;-).\n\n\n[Footnote]\n\n*1* This is not necessarily true; tags can point at anything,\nand indeed v1.0rc3 tag point at another tag and junio-gpg-tag\npoints at a freestanding blob. Even a tag pointing at a commit,\nas Daniel suggested in\n\n\t\n\nI could do the \"pu\" branch as a tag without exposing the actual\nbranch. Then that tag would point at a chain of commits not\nconnected to any branch head.\n"},{"id":"12259","messageId":"20051118220458.GA5665@agluck-lia64.sc.intel.com","threadId":"2593","inReplyTo":"7v1x1diuuy.fsf@assigned-by-dhcp.cox.net","subject":"Re: git fetch --tags doesn't quite do what I expect","fromName":"Luck, Tony","fromEmail":"tony.luck@intel.com","sentAt":"2005-11-18T22:04:58Z","receivedAt":"2005-11-18T22:04:58Z","isPatch":false,"sender":{"key":"tony.luck@intel.com","avatar":"https://avatars.githubusercontent.com/u/5446021?v=4"},"body":"On Fri, Nov 18, 2005 at 12:06:29PM -0800, Junio C Hamano wrote:\n> I am not good at documenting things, so I'd appreciate if\n> somebody paraphrased the above and send it back to me in a patch\n> form to update the document ;-).\n\n\nHow about this:\n\n[PATCH] Update pull/fetch --tags documentation\n\nWhen fetching/pulling from a remote repository the \"--tags\" option\ncan be used to pull tags too. Document that it will limit the pull\nto only commits reachable from the tags.\n\nSigned-off-by: Tony Luck \n\n---\n\ndiff --git a/Documentation/fetch-options.txt b/Documentation/fetch-options.txt\nindex 0e502ae..a25d04a 100644\n--- a/Documentation/fetch-options.txt\n+++ b/Documentation/fetch-options.txt\n@@ -8,7 +8,9 @@\n -t, \\--tags::\n \tBy default, the git core utilities will not fetch and store\n \ttags under the same name as the remote repository; ask it\n-\tto do so using `--tags`.\n+\tto do so using `--tags`. Using this option will bound the\n+\tlist of objects pulled to the remote tags. Commits in branches\n+\tbeyond the tags will be ignored.\n \n -u, \\--update-head-ok::\n \tBy default `git-fetch` refuses to update the head which\n"}]}