On Sun, Sep 26, 2010 at 8:24 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Sun, Sep 26, 2010 at 4:38 PM, Tom Lane <t...@sss.pgh.pa.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
