git conversion status update

[Brian J. Tarricone]

On Sun, 10 May 2009 12:51:38 +0200 Jannis Pohlmann wrote:

> On Sun, 10 May 2009 01:35:05 -0700
> "Brian J. Tarricone" <brian at tarricone.org> wrote:
> 
> > On Sun, 10 May 2009 04:16:07 +0200 Jannis Pohlmann wrote:
> > 
> > > I'll need to test this but while working on the commit mail hook
> > > script, I found out that I can generate nice commit mails like
> > > this for tags:
> > > 
> > >   Updating annotated tag refs/tags/2.0.4
> > >        as new annotated tag
> > >            to c34c2d75b29d92c40f06a605d27482d45308b743 (tag)
> > >      replaces 2.0.0
> > >     tagged by Jannis Pohlmann <jannis at xfce.org>
> > >            on 2009-05-10 03:47 +0200
> > >   
> > >   Jannis Pohlmann (1):
> > >         Revision 16
> > > 
> > > That means git detects when a tag replaces another one and lists
> > > the commits between the two tags at the bottom of the mail. I
> > > don't know if this only works for tags like "x.y.z" or also for
> > > tags like "xfce-x.y.z". 
> > 
> > Unnecessary... I'm planning on setting up the pre commit hooks to
> > disallow changing tags.
> 
> No, this is not about changing a tag. This is about creating new ones.
> Let's say we've tagged 4.6.0 with "git tag -a 4.6.0" and later tag
> "git tag -a 4.6.1". That's when you'd get the email above: it tells
> you the previous tag and gives you a list of authors and commit
> subjects between the previous tag and the new one.

Then you *really* need to fix the language on that ^_~.  "Replaces" is
really not the right word... I don't really see how that makes sense
anyway.  How does a tag "replace" another anyway?  Even if it's the
next one in a logical series, it doesn't somehow make the previous tag
obsolete.  If you can even look at it that way... people might want to
tag for reasons that have nothing to do with making a release.

	-b