Thread: Include commit identifier in version() function
Hi. I think, it be useful to include in version() function a hexadecimal identifier of commit, for fast checkout to it in git. -- ------------ pasman
2011/10/28 pasman pasmański <pasman.p@gmail.com>: > I think, it be useful to include in version() function a hexadecimal > identifier of commit, for fast checkout to it in git. It's sort of impossible to make this accurate, though. You may have patched your tree but not created a commit with those changes before you build; or if you have created a commit it may very well not be one that's in the public repo, but just something on our system. Moreover, there's no real guarantee that you're compiling from a git tree at all; you could well be compiling from a tarball. All in all I feel like this is a solution in search of a problem. People shouldn't be using anything other than a released version in production, or if they do, they should take it upon themselves to version-stamp it appropriately. An automated solution will probably not be reliable, and probably will create all sorts of build-system headaches. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
2011/10/28 Robert Haas <robertmhaas@gmail.com>: > 2011/10/28 pasman pasmański <pasman.p@gmail.com>: >> I think, it be useful to include in version() function a hexadecimal >> identifier of commit, for fast checkout to it in git. > > It's sort of impossible to make this accurate, though. You may have > patched your tree but not created a commit with those changes before > you build; or if you have created a commit it may very well not be one > that's in the public repo, but just something on our system. Sure, I may be compiling changes that are not committed, but still knowing the most recent commit/checkout that did happen would have better granularity than just "9.2devel". And if that commit hash is not in the public repo, that is fine, as I would want such a thing for my own use. > Moreover, there's no real guarantee that you're compiling from a git > tree at all; you could well be compiling from a tarball. > > All in all I feel like this is a solution in search of a problem. > People shouldn't be using anything other than a released version in > production, That is probably true, but 99+% of the compilations and installs I do are not intended for production use. I would be happy to see this feature in my own dev repository, even if it never did see its way into production. (It would already be there, if I knew of a way to make it happen) Cheers, Jeff
On Sat, Nov 5, 2011 at 2:46 PM, Jeff Janes <jeff.janes@gmail.com> wrote: >> Moreover, there's no real guarantee that you're compiling from a git >> tree at all; you could well be compiling from a tarball. >> >> All in all I feel like this is a solution in search of a problem. >> People shouldn't be using anything other than a released version in >> production, > > That is probably true, but 99+% of the compilations and installs I do > are not intended for production use. I would be happy to see this > feature in my own dev repository, even if it never did see its way > into production. (It would already be there, if I knew of a way to > make it happen) I wouldn't mind having it in my repository either, though I suspect it would be of only occasional use to me in practice. I think your parenthetical note hints at the real problem: right now, there's nothing in our repository that knows anything about the repository itself. To make something like this work, you'd have to know, for example, that on Bruce's machine, the git you need to use is actually called pggit, and is probably located at some pathname that would make the gods of standardization cringe. Leaving aside the wisdom of such configurations, upon which all sorts of doubt may be and has been cast, they cause the rest of us no inconvenience right now, and doing something like this would change that. Or you could ignore the git executables and just look for a .git directory that you could read by hand; but then you're at the mercy of any changes in the way that git does things. Every way I can think of to do something like this would fail in some situations in which everything now works. I've taken to installing test builds on my machine under $HOME/install/$IDENTIFIER, where $IDENTIFIER is a branch name or the first 10 characters of a commit SHA. I've found that to be a pretty handy solution to this problem. It still doesn't account for the possibility that different builds were done with different options, but at least I know what source code I was building from (the tip of branch X as of whenever I did the install, or that specific commit). -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company