On Oct 20, 2011, at 9:03 PM, Paul Davis wrote:
> Your argument here and the earlier argument about branches being
> temporary tags confuses me. Both are nothing more than pointers at
> hashes. This is just a social distinction. This entire thread is
> considering social distinctions about community consensus to decide
> what will be the value of the 1.1.1 (for immediate reference) tag.
Tags and branches are considerably different things with different uses.
A tag is a first class object with a creator, timestamp, message, and
optional GPG signature with a corresponding ref. It points to a commit (though
it *can* point to other objects, you generally don't do that). A branch is
just a symbolic ref pointing to a commit.
Tags objects are generally harder to get rid of than branches.
Upstream tag deletions aren't propagated downstream on normal clones (for good
reason described in the tag documentation). Anyone who clones your repo and
updates his clone will most surely receive your new tag and you will have to
ask him to do extra work to remove the tag when you delete it. That's just not
practical since you can't even know who has cloned your repo. (try it --
create an "upstream repo", clone it, tag it, update your clone (pull, etc...),
remove the tag and try to convince the clone to care without manually deleting
it there, too)
Branches, however, at least do have 'git remote update -p' to prune
away any local mirrors of upstream refs when you remove them.
Tags are, in practice, permanent pointers to important points in the
history of the project. Branches are named pointers to development locations.
They're often ephemeral (feature branches are common) and are generally meant
to be treated the way you're describing "rc tags".
Again, I don't really have much of a dog in the fight here. I'm just
suggesting that creating conventions that are different from what the tools are
accustomed to, you might find some technical difficulties you'd otherwise avoid.
--
dustin sallings
