Menu
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.
638
Yes, it's a two-level annotated tag (there's no real limit to how long a tag chain can go, although to make crazy-long ones you'd want to use git mktag in a loop, rather than using git tag -a and then deleting the external refs).
Select and expand the "Tags" tab on the left. Right-Click on the tag you want deleted. Select "Delete YOUR_TAG_NAME" In the verification window, select "Remove Tag From Remotes"
Sharing Tagsgit push <remote> --tags will push both lightweight and annotated tags. There is currently no option to push only lightweight tags, but if you use git push <remote> --follow-tags only annotated tags will be pushed to the remote.
We occasionally have two tags on the same commit. When we use git describe for that commit, git describe always returns the first tag. My reading of the git-describe man page seems to indicate that the second tag should be returned (which makes more sense).
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.
67
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.
20
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
