Oskari Saarenmaa <o...@ohmu.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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
