On Sat, Nov 5, 2011 at 2:46 PM, Jeff Janes <jeff.ja...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers