Thread: Include commit identifier in version() function

Include commit identifier in version() function

From
pasman pasmański
Date:
Hi.

I think, it be useful to include in version() function a hexadecimal
identifier of commit, for fast checkout to it in git.

-- 
------------
pasman


Re: Include commit identifier in version() function

From
Robert Haas
Date:
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


Re: Include commit identifier in version() function

From
Jeff Janes
Date:
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


Re: Include commit identifier in version() function

From
Robert Haas
Date:
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