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

On Sun, Sep 26, 2010 at 8:24 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Sun, Sep 26, 2010 at 4:38 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> Hah, I have a plan.  Let's just run git log for "master..RELx_y_STABLE"
>>> for each branch, rather than all the way back.
>
>> This doesn't seem more reliable to me in any way.  Looking at the
>> actual commit history must surely be more reliable than assuming you
>> know what it is.  I think what you should be doing is using git log
>> --decorate and extracting the information from that as you go by.
>
> I looked at doing that but it didn't seem like an improvement.  Take
> a look at the new version and see what you think.

I'm not really sure. I suppose I'll have to play with it for a while
to really form a clear opinion. Clearly, knowing which minor releases
a commit is in is a major improvement, but the whole thing is so
heavily re-engineered from my original version that I'm not really
sure whether there's anything else that I care about that got broken
in the process. In particular, I'm wondering to what extent we're
baking in branch management conventions from which we may wish to
depart at some point in the future.

I maintain that if someone else whacked around one of your commits the
way you whacked this around, you'd bite their head off.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company