This makes it easy to see if the binaries were built from a real release
or if they were built from a custom git tree.
---
configure.in | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/configure.in b/configure.in
index a4baeaf..7c5b3ce 100644
--- a/configure.in
+++
On 05.11.2013 12:22, Oskari Saarenmaa wrote:
This makes it easy to see if the binaries were built from a real release
or if they were built from a custom git tree.
Hmm, that would mean that a build from git checkout REL9_3_1 produces
a different binary than one built from
On Tue, Nov 05, 2013 at 02:06:26PM +0200, Heikki Linnakangas wrote:
On 05.11.2013 12:22, Oskari Saarenmaa wrote:
This makes it easy to see if the binaries were built from a real release
or if they were built from a custom git tree.
Hmm, that would mean that a build from git checkout REL9_3_1
On Tue, Nov 5, 2013 at 2:05 PM, Oskari Saarenmaa o...@ohmu.fi 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
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
* Tom Lane (t...@sss.pgh.pa.us) wrote:
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.
The focus of this change would really be, imv anyway, for more casual
PG developers,
Stephen Frost sfr...@snowman.net writes:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
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
On 11/05/2013 10:32 AM, Stephen Frost wrote:
All-in-all, I'm not super excited about this but I also wouldn't mind,
so while not really a '+1', I'd say '+0'. Nice idea, if it isn't
painful to deal with and maintain.
I doubt it's buying us anything worth having. What's more, it
* Tom Lane (t...@sss.pgh.pa.us) wrote:
What about, say, a configure option to add a
user-specified string to the version() result?
I quite like that idea, personally. Folks who care about it being a git
tag could then trivially get that also.
Thanks,
Stephen
On 11/05/2013 10:53 AM, Stephen Frost wrote:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
What about, say, a configure option to add a
user-specified string to the version() result?
I quite like that idea, personally. Folks who care about it being a git
tag could then trivially get that also.
On Tue, Nov 5, 2013 at 6:35 AM, Tom Lane t...@sss.pgh.pa.us wrote:
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
11 matches
Mail list logo
