Comments on: Git Tag Mini Cheat Sheet Revisited http://ariejan.net/2009/09/05/git-tag-mini-cheat-sheet-revisited/ Code Monkey Thu, 11 Mar 2010 04:50:50 +0000 http://wordpress.org/?v=2.9.2 hourly 1 By: Ariejan de Vroomhttp://ariejan.net/2009/09/05/git-tag-mini-cheat-sheet-revisited/comment-page-1/#comment-11145 Ariejan de Vroom Fri, 06 Nov 2009 08:36:32 +0000 http://ariejan.net/?p=515#comment-11145 You can view an Spanish translation at http://www.jcastaneyra.com/2009/11/05/etiquetando-codigo-en-gittagging-code-in-git/Thanks to José. You can view an Spanish translation at http://www.jcastaneyra.com/2009/11/05/etiquetando-codigo-en-gittagging-code-in-git/

Thanks to José.

]]> By: Etiquetando código en git/Tagging code in git | Blog de Joséhttp://ariejan.net/2009/09/05/git-tag-mini-cheat-sheet-revisited/comment-page-1/#comment-11143 Etiquetando código en git/Tagging code in git | Blog de José Thu, 05 Nov 2009 22:07:25 +0000 http://ariejan.net/?p=515#comment-11143 [...] http://ariejan.net/2009/09/05/git-tag-mini-cheat-sheet-revisited/?doing_wp_cron http://polywww.in2p3.fr/~gaycken/Calice/Software/my_git_workflow.html [...] [...] http://ariejan.net/2009/09/05/git-tag-mini-cheat-sheet-revisited/?doing_wp_cron http://polywww.in2p3.fr/~gaycken/Calice/Software/my_git_workflow.html [...]

]]> By: Ed Spencerhttp://ariejan.net/2009/09/05/git-tag-mini-cheat-sheet-revisited/comment-page-1/#comment-10882 Ed Spencer Tue, 08 Sep 2009 15:37:23 +0000 http://ariejan.net/?p=515#comment-10882 Thanks for this, most useful. Once change I had to make when pushing tags to Github is to omit the 'origin', e.g.:git push --tagsEverything else works as advertised :) Thanks for this, most useful. Once change I had to make when pushing tags to Github is to omit the ‘origin’, e.g.:git push –tagsEverything else works as advertised :)

]]> By: Jörg W Mittaghttp://ariejan.net/2009/09/05/git-tag-mini-cheat-sheet-revisited/comment-page-1/#comment-10878 Jörg W Mittag Sun, 06 Sep 2009 12:18:44 +0000 http://ariejan.net/?p=515#comment-10878 I think I got a little bit confused wrt the pushing and pulling stuff. I wrote my comment basically from memory. After your reply to my comment I started to research it, and now I'm completely lost :-)Basically, tags are just refs (like branches), which live in .git/refs/tags (as opposed to branches which live in .git/refs/heads). If you have a push/pull refspec that includes refs/tags/* (or just refs/*), then new and/or deleted tags will be pushed/pulled just like new/deleted branches. (The whole refspec stuff is still more than a little unclear to me.) According to the git-pull manpage, tags that point to objects that are reachable from the heads that you are pulling, are automatically fetched, this can be overriden with the --tags (fetch *all* tags, not just the ones that are reachable) and --no-tags (do not fetch *any* tags) options. The reason why this is all so complicated is that all tags share a global namespace (unlike branches, whose names are namespaced by the remote they belong to). So, automatic following of tags only makes sense *within* a closed network of developers that have agreed on naming standards for tags. I believe that there are a few heuristics built into Git as to when a transaction crosses such network boundaries (e.g. when you clone a repository or add it as a remote, it is considered to be part of your network, but if you just do a one-shot git pull, giving it a full URI to pull from, then it's not. But, I am not sure about that.)BTW: a quick interesting tidbit: if you look at the tag refs in .git/refs/tags, you can see the difference between lightweight tags and annotated tags: lightweight tags point to *commit* objects, annotated tags point to *tag* objects (which in turn contain a reference to the commit object). IOW, lightweight tags aren't objects of their own, whereas annotated tags *are* proper Git objects, which means they are part of the repository, they have a SHA1 and so on. (This also means that you can modify a lightweight tag, but not an annotated tag, because then its SHA1 would change.) I think I got a little bit confused wrt the pushing and pulling stuff. I wrote my comment basically from memory. After your reply to my comment I started to research it, and now I’m completely lost :-)

Basically, tags are just refs (like branches), which live in .git/refs/tags (as opposed to branches which live in .git/refs/heads). If you have a push/pull refspec that includes refs/tags/* (or just refs/*), then new and/or deleted tags will be pushed/pulled just like new/deleted branches. (The whole refspec stuff is still more than a little unclear to me.) According to the git-pull manpage, tags that point to objects that are reachable from the heads that you are pulling, are automatically fetched, this can be overriden with the –tags (fetch *all* tags, not just the ones that are reachable) and –no-tags (do not fetch *any* tags) options. The reason why this is all so complicated is that all tags share a global namespace (unlike branches, whose names are namespaced by the remote they belong to). So, automatic following of tags only makes sense *within* a closed network of developers that have agreed on naming standards for tags. I believe that there are a few heuristics built into Git as to when a transaction crosses such network boundaries (e.g. when you clone a repository or add it as a remote, it is considered to be part of your network, but if you just do a one-shot git pull, giving it a full URI to pull from, then it’s not. But, I am not sure about that.)

BTW: a quick interesting tidbit: if you look at the tag refs in .git/refs/tags, you can see the difference between lightweight tags and annotated tags: lightweight tags point to *commit* objects, annotated tags point to *tag* objects (which in turn contain a reference to the commit object). IOW, lightweight tags aren’t objects of their own, whereas annotated tags *are* proper Git objects, which means they are part of the repository, they have a SHA1 and so on. (This also means that you can modify a lightweight tag, but not an annotated tag, because then its SHA1 would change.)

]]>