26
30bd19ef190cf664356c715b56044ce739f07468        refs/tags/Prod_Release_2.3
4ae15ee04c2c41bfc7945e66f4effc746d52baec        refs/tags/Prod_Release_2.3^{}

Above is the output from git ls-remote --tags listing tags in my centralized repository (bare).

For Prod_Release_2.3 I only expect 1 tag, I have no idea where this Prod_Release_2.3^{} came from.

In centralrepo1 the id of Prod_Release_2.3 is same as centralrepo2's id of Prod_Release_2.3^{}, and vice-versa.

In my local repository there is just one tag Prod_Release_2.3.

Is something wrong? Or is this by design?

Central repository is hosted on Ubuntu and I use msysgit in my dev machine.

eebbesen
  • 5,070
  • 8
  • 48
  • 70
mamu
  • 12,184
  • 19
  • 69
  • 92

2 Answers2

33

There are two types of tags in Git: “lightweight” and “annotated”.

Lightweight tags are simply refs in the refs/tags/ namespace that point to some other object. They are created by using git tag <tagname> [object] without -a, -m, -F, -s, or -u.

Annotated tags are actually a separate kind of Git object (a tag object) that point to some other object. Tag objects store committer information, author information, a message (similar to commit objects) and they point to any single other object (different from commit objects in that commits point to exactly one tree object and zero or more other commit objects).

When you have an annotated tag, you usually also have a ref that points to it. Technically this ref is itself a “lightweight” tag, but we usually do not describe them separately.

Normally, both kinds of tags point to commits, but they can point to any kind of Git object (tag, commit, tree, or blob). The git.git repository has refs/tags/junio-gpg-pub that points to a blob that contains the maintainer’s GPG public key. Also, torvalds/linux-2.6.git has refs/tags/v2.6.11 that points to a tree. Although tags that point to non-commit objects are technically allowed, they may break or confuse some tools, so they should be avoided, if possible.

The syntax ^{} suffix (described in gitrevisions(7)) is the tag dereferencing syntax (sometimes called the “peeled tag” syntax). For tag objects, it evaluates to the first non-tag object to which the tag object points (it will recursively deference a chain of tag objects until it finds a non-tag object). For non-tag objects, it means the same thing as without the ^{} suffix.

The refs/tags/Prod_Release_2.3 ref in your central repository points to the tag object named 30bd19ef190cf664356c715b56044ce739f07468.
That tag objects ultimately points to some other non-tag object named 4ae15ee04c2c41bfc7945e66f4effc746d52baec (probably a commit).

Thus, refs/tags/Prod_Release_2.3^{} resolves to 4ae15ee04c2c41bfc7945e66f4effc746d52baec.

Chris Johnsen
  • 214,407
  • 26
  • 209
  • 186
  • 1
    In short, each _annotated tag_ you push creates an initial tag reference and a second reference with the ^{} syntax that points to the first one. Lightweight tags only create a single reference. – bryanbraun Dec 21 '13 at 17:36
  • 1
    @bryanbraun: The `whatever^{}` name does not exist as a *ref* (an entry under the `refs/` namespace); `^{}` is simply a suffix that can be appended to any revision name (*ref* name, (abbreviated) *object* hash, or other computed revision name, etc.) to “peel” *tag objects* until a non-tag *object* is found. Assuming the *commit* to be tagged, **C**, has already been pushed, then pushing a new annotated tag would push one *tag object* (pointing to **C**) and a new *ref* (pointing to the new *tag object*), while a lightweight tag would push only the new *ref* (pointing to **C**). – Chris Johnsen Dec 21 '13 at 20:23
  • 1
    Although `ls-remote` shows these `^{}` psuedo-*refs*, they do not actually exist as *refs*; you can verify this by (e.g.) comparing the output of `git show-ref --tags` (actual tag *refs*) to that of `git ls-remote --tags .` (what the “wire protocol” reports). The “peeled tags” are included in the “wire protocol” for technical reasons, but they do not exists as actual *refs*. But yes, you can think of the `^{}` ones as “references” (since it is a way of naming a particular object) as long as you do not use that term to mean “an entry under the `/refs` namespace”. – Chris Johnsen Dec 21 '13 at 20:36
  • Can you have two tags with the same name and description pointing to the same commit? – Ogen Mar 20 '17 at 21:22
6

That isn't a tag, it's a pointer to the commit that the tag points to. You can read more about this in the git show-ref man page.

Dustin
  • 89,080
  • 21
  • 111
  • 133
  • it would be that if you entered it on the command line. Looks like you have a badly named tag. – Adam Dymitruk Mar 17 '11 at 23:08
  • @adymitruk: `git ls-remote --tags origin` in my git.git repository prints the tag and pointed-to-commit for every tag (since they're all bona fide tag objects). – Cascabel Mar 17 '11 at 23:43
  • 1
    Another good place to learn is [The Git Object Model](http://book.git-scm.com/1_the_git_object_model.html) from the Git Community Book - tag objects are described, along with the others. – Cascabel Mar 17 '11 at 23:49