* 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, particularly those familiar with github and who work with branches pushed there by other developers. > Even if I always committed before building, the hash > tags are only decipherable until I discard that branch. Certainly true- but then, are you typically keeping binaries around after you discard the branch? Or distributing those binaries to others? Seems unlikely. However, if you're pulling in many branches from remote locations and building lots of PG binaries, keeping it all straight and being confident you didn't mix anything can be a bit more challenging. > 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? Not many do it today because we actively discourage it by requiring patches to be posted to the mailing list and the number of people writing PG patches is relatively small. Even so though, I can see folks like certain PG-on-cloud providers, who are doing testing, or even deployments, with various patches to provide us feedback on them, and therefore have to manage a bunch of different binaries, might find it useful. > (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. Clearly, that would need to be addressed. 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. Thanks, Stephen
Description: Digital signature