git/list[1] front-page[2] threads[3] people[4] search[5] about
 

git tag usability issue: Lightweight vs Annotated confusion for the end user (ex. git describe default)

From
Daniele Segato <daniele.segato@gmail.com>
Date
Jul 24, 2013, 10:17 UTC
Message-ID
<51EFA9A9.4010103@gmail.com>
Hi,

I think there is an issue with the documentation of git tag, or with the default being chosen for tags.

the git tag documentation say:
*****
        If one of -a, -s, or -u <key-id> is passed, the command creates 
a tag object, and requires a tag message. Unless -m <msg> or -F <file> 
is given, an editor is started for the user to type in the tag
        message.
        If -m <msg> or -F <file> is given and -a, -s, and -u <key-id> 
are absent, -a is implied.
        Otherwise just a tag reference for the SHA1 object name of the 
commit object is created (i.e. a lightweight tag).
******

And no options below is provided to list annotated tags only or lightweight tags only (is there a way to do so?)

I initially didn't get git cared too much on this difference: I've been using both annotated and lightweight tags without distinctions, annotated when I want to write something about the tag and non-annotated when I do not need it.

Since no option is given to show annotated only tags these made sense to me.

Recently I started using submodules and I noticed that: git submodule status

sometimes gave me the tag name of the submodule between parentesis and sometimes it gave me something like this: +6903774653de52d0206e0e6026ca6914def8a333 submodule (1.0-2-g6903774)

even if the 6903774653de52d0206e0e6026ca6914def8a333 was actually a tag (1.1)

the git help submodule say status use git describe, so I've entered the submodule directory and tried:

$ git describe 1.0-2-g6903774

$ git describe --tags 1.1

reading the git help describe I discovered the git describe made an assumption and default to just show annotated tags.

To me, this assumption should have been documented very clearly in the git tag help page, something like this:

*****
        If one of -a, -s, or -u <key-id> is passed, the command creates 
a tag object, and requires a tag message. Unless -m <msg> or -F <file> 
is given, an editor is started for the user to type in the tag
        message.
        If -m <msg> or -F <file> is given and -a, -s, and -u <key-id> 
are absent, -a is implied.
        Otherwise just a tag reference for the SHA1 object name of the 
commit object is created (i.e. a lightweight tag).
        ANNOTATED vs LIGHTWEIGHT tags
        Some git command (ex. git describe) by default only consider 
annotated tags. Annotated and Lightweight tags are not the same thing 
for git and you shouldn't mix them up. Annotated tags are meant for 
release while lightweight tags are meant to tag random commits.
******

And I think an option in git tag to only show annotated tags (or only show lightweight tags) is needed.

Finally, now that I discovered this I can't replace the lightweights tags with annotated tags without a public announcement requiring all developers to delete their local tags.

I'm not aware of any discussion you did about this matter but I think there's something wrong here that should be fixed.

Regards, Daniele Segato

Next: Junio C Hamano
Message 1 of 23 in “git tag usability issue: Lightweight vs Annotated confusion for the end user (ex. git describe default)”
  1. Daniele SegatoJul 24, 2013
  2. Junio C HamanoJul 24, 2013
  3. git-tag man: when to use lightweight or annotated tagsDaniele Segato, Jul 25, 2013
  4. Marc BranchaudJul 25, 2013
  5. Daniele SegatoJul 26, 2013
  6. Daniele SegatoJul 26, 2013
  7. Marc BranchaudJul 26, 2013
  8. Daniele SegatoJul 26, 2013
  9. Daniele SegatoJul 26, 2013
  10. Jeff KingJul 26, 2013
  11. Jonathan NiederJul 26, 2013
  12. Daniele SegatoJul 29, 2013
  13. Daniele SegatoAug 7, 2013
  14. Marc BranchaudJul 26, 2013
  15. Junio C HamanoJul 29, 2013
  16. Daniele SegatoJul 29, 2013
  17. Daniele SegatoJul 27, 2013
  18. Philip OakleyJul 27, 2013
  19. Stefan BellerJul 27, 2013
  20. Daniele SegatoJul 29, 2013
  21. Marc BranchaudJul 26, 2013
  22. Daniele SegatoJul 29, 2013
  23. Daniele SegatoJul 25, 2013

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.