* Tom Lane (tgl@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