Re: [COMMITTERS] pgsql: Still more tweaking of git_changelog.

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: [COMMITTERS] pgsql: Still more tweaking of git_changelog.
Date: 2010-09-26 19:24:03
Message-ID: 15614.1285529043@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

I wrote:
> I think we could get that behavior fairly easily by remembering the last
> tag matching one of the commits on a branch, as we chase the branch
> backwards.

I find that this works just fine for the branches, but not so well for
master, because more often than not the initial RELx_y_z tag is applied
on the release's branch and not on master. So for example commits on
master appear to jump from REL7_2 development to REL8_0 development,
because 7.3 and 7.4 have no release tag on the master branch.

We could perhaps fix that if there were an inexpensive way to get the
SHA1 of the master commit that each branch is sprouted from. However,
I'm inclined to propose that we instead manually place a tag at each
sprout point. Any thoughts about that? In particular, what should
the naming convention for such tags be? I would have liked to use
RELx_y, but that's out because before 8.0 we named the initial
releases that way.

regards, tom lane

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Tom Lane 2010-09-26 19:27:41 Re: [COMMITTERS] pgsql: Still more tweaking of git_changelog.
Previous Message Robert Haas 2010-09-26 18:11:20 Re: [COMMITTERS] pgsql: Still more tweaking of git_changelog.

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2010-09-26 19:27:41 Re: [COMMITTERS] pgsql: Still more tweaking of git_changelog.
Previous Message Robert Haas 2010-09-26 19:18:46 Re: Patch: Extend NOT NULL representation to pg_constraint