Re: Suggestion: drop 'g' in git-describe suffix

From: Santi Béjar <sbejar@gmail.com>
Date: Nov 2, 2006, 12:39 UTC
Message-ID: <8aa486160611020439r255bcdb1q6e7ece46c77de11c@mail.gmail.com>
In-Reply-To: <4549D4B4.4030601@shadowen.org>

On 11/2/06, Andy Whitcroft <apw@shadowen.org> wrote:

Show 13 quoted lines

> Santi Béjar wrote:
> > One problem I see with this scheme (either 'g', 'git' of '+') is that
> > it does not provide an increasing version number, even for
> > fast-forwarding commits. Then it is not useful as a package version
> > number (deb or rpm). I've already seen deb packages with
> > version+git20061010. One possibility could be to add the number of
> > commits between the tag and the commit as:
> >
> > v1.4.3.3-git12g1e1f76e
> >
> > to provide a weak ordering for fast-forwarding commits. What do you thing?
>
> I think you'll restart the 1.2.3.4 versioning is better 'debate' again!

Sorry, I don't undestand this.

Show 5 quoted lines

> Surly if things are being pushed into a .deb or .rpm we should be using
> a real release version.  We should be tagging that.  If the project is
> not providing release number, there is nothing stopping you from tagging
> them yourself in your copy of the repository and using your tag.  you
> could use like 'unofficial-N' where N increments in the way you want.

And where do you store this tag? It is an upstream commit and you just refer to this. With the unofficial-N there is no way to know which upstream commit you are refering without having access to the git repository of the packager .