Sorry, I was a bit unclear... by "feels lazy" I meant, if you're creating a tag then it seems logical to me that the version should be the tag name... and that you'd use some sort of standard versioning scheme for that (major.minor.patch) that would be human-readable. I've seen far to many (svn) people that use the commit number *as* their version number. Not just build number, as the whole version. Naturally that makes even less sense in git, since commits are not sequentially numbered. If the user is using a nightly-build or "edge" sort of setup, then SHA1s would make sense. Simply put, if the end user is not aware of git (they're using a tarball instead of a clone), then I would expect that the packager wouldn't be either.
As for the contents of the tarball and the variables, you'd probably be best to direct those questions to the git mailing list. We just use git-archive to create the tarballs, and git doesn't have a variable system like svn does. On Tue, Dec 15, 2009 at 1:19 PM, Dieter_be <[email protected]>wrote: > > > On Dec 13, 10:49 pm, Tekkub <[email protected]> wrote: > > Perhaps you should make your tags in little side branches with the direct > > modifications you need in them. This is what I do, take a look at one of > my > > repos:http://github.com/tekkub/engravings/network With this users can > > directly download the tarball/zip directly, they don't need to know > anything > > about git, or even that the repo *is* git. > > > > The only issue here is that you can't use the SHA1, but honestly that > always > > feels sorta lazy anyway. What I do is replace the version string in my > code > > with the tag name, that's certainly more user friendly and just as easy > (if > > not easier) to track down than a SHA1 is. > > Hi, thanks, but: > - making own branches and manually updating a file just to denote a > version just seems wrong to me > - i prefer to have the hash available in the compiled software at > runtime, though i am willing to compromise for just the git tag ;) [at > least git tags are a good mechanim to mark releases] > - i definitely agree that the end user shouldn't need to know or be > aware of the git thing. it is only my intention for the makefile/ > buildscripts to be aware of the commit hash when building the software > (without internet access) > i.e. this is about building and packaging in "the downstream" > - what do you mean with "feels lazy"? if you mean "involves no manual > work" then you're definitely right, but that's a good thing ;) and i > think sha1 hashes are a great way to uniquely identify each single > source tree state (when trying to debug problems and such). but like > i said, i'm willing to compromise for git tags, as downstream usually > works with that anyway. > > > I think all ultimately needed for this is just a little .info file or > something in the tarball containing the "origin information" (hash, > tag, maybe url?) or > a magic variable replacement system like svn has (but i couldn't find > it for git :/) > > -- > > You received this message because you are subscribed to the Google Groups > "GitHub" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<github%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/github?hl=en. > > > -- You received this message because you are subscribed to the Google Groups "GitHub" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/github?hl=en.
