Re: [COMMITTERS] pgsql: Still more tweaking of git_changelog. - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [COMMITTERS] pgsql: Still more tweaking of git_changelog.
Date
Msg-id 16788.1285533503@sss.pgh.pa.us
Whole thread Raw
In response to Re: [COMMITTERS] pgsql: Still more tweaking of git_changelog.  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [COMMITTERS] pgsql: Still more tweaking of git_changelog.  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
I wrote:
> 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.

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.  Then we can identify the
sprout point as the parent of the last emitted commit for the branch.
The "post dated" or "double tagged" or whatever you call 'em branch
annotations for earlier master commits can then be inserted by hand,
rather than reverse-engineering them by matching author/message/etc.
This should be both faster and more reliable than the current method.

Note: if using --since then this method won't necessarily identify the
sprout point: we might end up with the SHA1 of some commit on the
branch.  But it won't matter, because we won't be going back far enough
on the master branch for there to be any commits that need to be
double-tagged for that branch.

A possible objection to this method is that it might be difficult to
scale it up to cases where you were interested in branches sprouting off
of maintenance branches, rather than only branches sprouted directly
from master.  But I find it hard to foresee caring about such cases.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: do we want to gitignore regression-test-failure files?
Next
From: Robert Haas
Date:
Subject: Re: [COMMITTERS] pgsql: Still more tweaking of git_changelog.