On Thu, Sep 16, 2010 at 09:59:43AM +0200, Adam Borowski wrote: > On Thu, Sep 16, 2010 at 03:22:31PM +1000, Matthew Palmer wrote: > > On Wed, Sep 15, 2010 at 03:18:20PM +0200, Adam Borowski wrote: > > > Why won't you just use `git --describe`? > > > It produces nice version numbers of the format > > > <last tag>-<number of commits after it>-<start of hash> > > > (or just <last tag> when you're packaging a release) > > > > > > The "start of hash" is a way to disambiguate in the case of multiple > > > branches based on the same release that happen to have the same number > > > of commits past that it; it will be the minimal repo-wide unambiguous > > > hash not shorter than (by default) 7 characters. > > > > You cannot use hashes in your version strings, because you can't assume that > > the "later" version is going to sort after the "earlier" version. If > > <tag>-<commitcount> isn't sufficiently unique, you're stuffed. > > You can't compare unversioned branches to other branches anyway. If you > move from one branch to another, you need to label that manually. > > Git's scheme provides enough versioning to handle anything that can be done > in automated way. Indeed, packaging multiple branches stemming from the > same tag may give versions that are not sufficiently sortable, but there's no > way to tell which branch is the "lesser" and which is the "greater" one > without human intervention.
So what does this have to do with producing a suffix to put on an upstream version for a Debian package? > > Using a tag, however, is a possibility I hadn't considered. If you merge > > from upstream at relevant points and then tag in your repo, you could use > > 0.x.y~<tagname> as the upstream version. Again, README.source would need to > > document this convention, but you can control the content of the tag to make > > it monotonically increasing. > > This would be bad, as your tags won't say anything about the version you > package. Without a mapping between your tags and particular commits, > there's no way to tell what upstream source you refer to. Can't you tell git to retrieve a tag (and all commits therefrom) from a remote repository? If not, what *is* the point of a git tag? > > If it is ambiguous, you can always put that sort of information in the > > Debian > > changelog, or perhaps README.source. > > git --describe doesn't have that pesky requirement. git --describe is, as far as I can tell, useless for the purpose stated at the beginning of the thread. - Matt -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
