From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Øyvind A(dot) Holm <sunny(at)sunbase(dot)org>, PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: patch: version_stamp.pl: Add Git commit info to version if 'git' is specified |
Date: | 2015-08-28 08:44:03 |
Message-ID: | 20150828084403.GA7232@awork2.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2015-08-28 07:48:28 +0200, Fabien COELHO wrote:
> >Salesforce did something similar in their internal build, and TBH I do not
> >find it a good idea. The basic problem is it's completely misleading to
> >equate the last commit with the source you actually built from, because
> >that might not have been an unmodified file set.
>
> Indeed. What I've done in an svn-based project is to build the stamp from
> the Makefile basically when linking, that is really as late as possible. The
> other good point is that svnversion adds 'M' for modified if the source tree
> has uncommitted changes.
>
> Maybe such an approach could be used with git to have something reliable.
I've done the same using the output $(git describe --tags --dirty) -
which will return something like REL9_5_ALPHA1-330-g8a7d070-dirty. That
is, the last tag, the number of commits since, the commit hash, and
whether the current build tree is dirty.
That's still not perfect considering plpgsql and such, but it's pretty
helpful.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Shulgin, Oleksandr | 2015-08-28 08:58:14 | Re: psql - better support pipe line |
Previous Message | Kyotaro HORIGUCHI | 2015-08-28 08:33:44 | Multiline-statement and multi-statement for pgbench custom script. |