From: Santi Béjar Date: Thu, 02 Nov 2006 12:39:26 GMT Subject: Re: Suggestion: drop 'g' in git-describe suffix Message-ID: <8aa486160611020439r255bcdb1q6e7ece46c77de11c@mail.gmail.com> In-Reply-To: <4549D4B4.4030601@shadowen.org> On 11/2/06, Andy Whitcroft wrote: > 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. > 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 .