but the problem is, in the make process we need to know which commit
hash you're compiling from, so we can store that in the binaries. it
helps in identifying the software.
(see http://github.com/Dieterbe/uzbl/blob/master/Makefile )
for this we currently use the .git directory, but this directory is
not available in the tarballs.
is it possible for github to do one of:
- leaving .git intact in the tarball
- put a little file in the tarball, containing the commit hash and
optionally the tag
or alternatively, is their some trick we can do ourselves to have a
file which always contains the current commit hash? i think svn can do
something like that, but couldn't find it for git.
If you look at the tarball that is downloaded you'll see that we give you
the short hash. If you want the .git folder you should just clone the repo,
because that's created by your local git when you clone. You could also
just hit the tag page and parse the commit off that,
http://github.com/Dieterbe/uzbl/tree/2009.11.30. There might also be a way
to get that info from the API.
Tekkub
GitHub Tech Support
http://support.github.com/ Join us on IRC: #github on freenode.net
Discussion group: github@googlegroups.com
On Sat, Dec 12, 2009 at 11:14 AM, Dieter_be <dieterplaeti...@gmail.com>wrote:
> but the problem is, in the make process we need to know which commit
> hash you're compiling from, so we can store that in the binaries. it
> helps in identifying the software.
> (see http://github.com/Dieterbe/uzbl/blob/master/Makefile )
> for this we currently use the .git directory, but this directory is
> not available in the tarballs.
> is it possible for github to do one of:
> - leaving .git intact in the tarball
> - put a little file in the tarball, containing the commit hash and
> optionally the tag
> or alternatively, is their some trick we can do ourselves to have a
> file which always contains the current commit hash? i think svn can do
> something like that, but couldn't find it for git.
> thanks!
> Dieter
> --
> You received this message because you are subscribed to the Google Groups
> "GitHub" group.
> To post to this group, send email to github@googlegroups.com.
> To unsubscribe from this group, send email to
> github+unsubscribe@googlegroups.com<github%2Bunsubscribe@googlegroups.com>
> .
> For more options, visit this group at
> http://groups.google.com/group/github?hl=en.
On Dec 13, 2:51 am, Tekkub <tek...@gmail.com> wrote:
> If you look at the tarball that is downloaded you'll see that we give you
> the short hash. If you want the .git folder you should just clone the repo,
> because that's created by your local git when you clone. You could also
> just hit the tag page and parse the commit off that,http://github.com/Dieterbe/uzbl/tree/2009.11.30. There might also be a way
> to get that info from the API.
well..
- short hash is not enough. i need the long one
- packaging should work without internet access
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.
On Sun, Dec 13, 2009 at 2:34 PM, Dieter_be <dieterplaeti...@gmail.com>wrote:
> On Dec 13, 2:51 am, Tekkub <tek...@gmail.com> wrote:
> > If you look at the tarball that is downloaded you'll see that we give you
> > the short hash. If you want the .git folder you should just clone the
> repo,
> > because that's created by your local git when you clone. You could also
> > just hit the tag page and parse the commit off that,
> http://github.com/Dieterbe/uzbl/tree/2009.11.30. There might also be a
> way
> > to get that info from the API.
> well..
> - short hash is not enough. i need the long one
> - packaging should work without internet access
> thanks anyway
> Dieter
> --
> You received this message because you are subscribed to the Google Groups
> "GitHub" group.
> To post to this group, send email to github@googlegroups.com.
> To unsubscribe from this group, send email to
> github+unsubscribe@googlegroups.com<github%2Bunsubscribe@googlegroups.com>
> .
> For more options, visit this group at
> http://groups.google.com/group/github?hl=en.
On Dec 13, 10:49 pm, Tekkub <tek...@gmail.com> 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 :/)
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 <dieterplaeti...@gmail.com>wrote:
> On Dec 13, 10:49 pm, Tekkub <tek...@gmail.com> 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 github@googlegroups.com. > To unsubscribe from this group, send email to > github+unsubscribe@googlegroups.com<github%2Bunsubscribe@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/github?hl=en.
> 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.
okay that makes sense. i can live with "hashes for git users, tags for release users", but again: once you got the tarball from github there is no way to know which git tag it corresponds to.
this is really too bad, as you need to resort to workarounds such as manually updating versionfiles in order to support normal downstream packaging.
