Re: Git pull doesn't get the tags

Rico Secada [off-list ref] writes:

On Fri, 22 Oct 2010 11:04:32 +0200
Mathias Lafeldt [off-list ref] wrote:

quoted

From git-pull's manpage:

-t
--tags
        Most of the tags are fetched automatically as branch
        heads are downloaded, but tags that do not point at
        objects reachable from the branch heads that are being
        tracked will not be fetched by this mechanism.  This
        flag lets all tags and their associated objects be
        downloaded. [...]

[jc: please do not top post, because people tend to read from top to
bottom not the other way around]

I managed to overlook the info from the man page, sorry.

But what does "but tags that do not point at objects reachable from the
branch heads that are being tracked will not be fetched by this
mechanism" mean?

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

On Fri, 22 Oct 2010 15:25:52 -0700
Junio C Hamano [off-list ref] 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!