couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dustin Sallings <>
Subject Re: Tweaking the release procedure
Date Fri, 21 Oct 2011 08:54:04 GMT

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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message