couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Newson <>
Subject Re: Tweaking the release procedure
Date Fri, 21 Oct 2011 18:25:39 GMT

/tmp/bar $ git --version
git version

/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.


On 21 October 2011 19:11, Noah Slater <> wrote:
> On Fri, Oct 21, 2011 at 7:04 PM, Dustin Sallings <> 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.

View raw message