Re: [PATCH] configure: add git describe output to PG_VERSION when building a git tree

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Oskari Saarenmaa <os(at)ohmu(dot)fi>
Cc: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [PATCH] configure: add git describe output to PG_VERSION when building a git tree
Date: 2013-11-05 14:35:38
Message-ID: 16337.1383662138@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Oskari Saarenmaa <os(at)ohmu(dot)fi> writes:
> On Tue, Nov 05, 2013 at 02:06:26PM +0200, Heikki Linnakangas wrote:
>> I can see some value in that kind of information, ie. knowing what
>> patches a binary was built with, but this would only solve the
>> problem for git checkouts. Even for a git checkout, the binaries
>> won't be automatically updated unless you run "configure" again,
>> which makes it pretty unreliable.
>>
>> -1 from me.

> I don't think we can solve the problem of finding local changes for all the
> things people may do, but I'd guess it's pretty common to build postgresql
> from a clean local git checkout and with this change at least some portion
> of users would get some extra information.

I agree with Heikki that this is basically useless. Most of my builds are
from git + uncommitted changes, so telling me what the top commit was has
no notable value. Even if I always committed before building, the hash
tags are only decipherable until I discard that branch. So basically, this
would only be useful to people building production servers from random git
pulls from development or release-branch mainline. How many people really
do that, and should we inconvenience everybody else to benefit them?
(Admittedly, the proposed patch is only marginally inconvenient as-is,
but anything that would force a header update after any commit would
definitely put me on the warpath.)

BTW, I don't think the proposed patch works at all in a VPATH build.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2013-11-05 14:55:57 Re: pgsql: Remove internal uses of CTimeZone/HasCTZSet.
Previous Message Leonardo Francalanci 2013-11-05 14:28:52 Re: Fast insertion indexes: why no developments