Dustin,
/tmp/bar $ git --version git version 1.7.6.1 /tmp/bar $ git pull --tags remote: Counting objects: 4, done. remote: Compressing objects: 100% (2/2), done. remote: Total 3 (delta 0), reused 0 (delta 0) Unpacking objects: 100% (3/3), done. >From /tmp/foo - [tag update] 1.0 -> 1.0 Fetching tags only, you probably meant: git fetch --tags The 1.0 tag was correctly updated. B. On 21 October 2011 19:11, Noah Slater <[email protected]> wrote: > On Fri, Oct 21, 2011 at 7:04 PM, Dustin Sallings <[email protected]> wrote: > > IMO, simplicity and conventions win here. Tags should be treated as >> immutable pointers to commits that had some meaning and should be named and >> labeled meaningfully as well. Branches are pointers to works in progress. >> When work is "finished", they can be tagged and deleted. If you do this, >> all of the defaults work and you don't have to invent and document as much. >> > > The only way I can see this working then is to "move" the tag once a vote > passes. Whether this involves duplicating the tag, or creating a new one > that points to the same thing, I don't know. Other people with more Git-fu > can step in here. But we need a way of blessing tags that works with > downstream repositories, and that separates them out from defunct tags that > never made the cut. >
