On Fri, 22 Oct 2010 15:25:52 -0700 Junio C Hamano <gitster@xxxxxxxxx> wrote: > The above passage in the manual page may be stated rather poorly. > > When "git fetch" is run, unless told otherwise by an explicit > --no-tags, it automatically fetches tags that point at new commits on > branches you fetch. For example, I just tagged v1.7.3.2 last night, > so if you fetch from me to get 'maint', 'master' or other integration > branches of mine that includes 8a90438 (Git 1.7.3.2, 2010-10-21), > "git fetch" would also copy v1.7.3.2 tag from me to your repository. > > In the above example, 'maint', 'master', etc. are the branch heads > that are being tracked (i.e. you will copy them to the > refs/remotes/origin hierarchy in your repository) and v1.7.3.2 is a > tag that does point at an object 8a90438 reachable from these branch > heads. So you will get the tag without giving the --tags option from > the command line. > > If you were fetching only 'html' or 'man' branches from me, on the > other hand, you would not have gotten v1.7.3.2 tag, as they are > separate histories and that particular tag does not live in their > ancestry. > > Also tags that point at non-commits (e.g. in git.git, junio-gpg-pub > and spearce-gpg-pub are pointing at blob objects, and v2.6.11 and > v2.6.11-tree tags in the kernel repository are pointing at tree > objects) will not be fetched automatically either. You would need to > explicitly ask for them if you want them by either (1) find them via > ls-remote and name them on the command line, or (2) use --tags option A nice and meaningful explanation. Thanks for the details! -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html