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

On Sun, Sep 26, 2010 at 1:51 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Still more tweaking of git_changelog.
>
> 1. Don't assume there's only one candidate match; check them all and use the
> one with the closest timestamp.  Avoids funny output when someone makes
> several successive commits with the same log message, as certain people
> have been known to do.
>
> 2. When the same commit (with the same SHA1) is reachable from multiple
> branch tips, don't report it for all the branches; instead report it only
> for the first such branch.  Given our development practices, this case
> arises only for commits that occurred before a given branch split off from
> master.  The original coding blamed old commits on *all* the branches,
> which isn't terribly useful; the new coding blames such a commit only on
> master.

Uhm, could you stop massively changing the behavior of this script
with no discussion at all?  I happen to think that this is a
distinctly bad idea.  It defeats one of the major use cases of the
original script, which is being able to easily figure out which
branches a certain commit is in.  If you want to have an option for
this behavior, fine, but please do not presume that everyone wants the
same thing as you (since that is evidently not the case) or that you
are the only person who is using it (if that were so, it should be
stored in your personal workspace, rather than our community
repository).

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

Robert Haas <robertmhaas@gmail.com> writes:
> On Sun, Sep 26, 2010 at 1:51 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Still more tweaking of git_changelog.

> Uhm, could you stop massively changing the behavior of this script
> with no discussion at all?

Uh, there was no discussion of the original behavior of the script
either.

> I happen to think that this is a
> distinctly bad idea.  It defeats one of the major use cases of the
> original script, which is being able to easily figure out which
> branches a certain commit is in.

Hm?  As far as I can tell, this fixes that not breaks it.  The problem
I was seeing was that commits would be attributed to a branch when in
fact they were made before the branch ever existed.

> If you want to have an option for
> this behavior, fine, but please do not presume that everyone wants the
> same thing as you (since that is evidently not the case) or that you
> are the only person who is using it (if that were so, it should be
> stored in your personal workspace, rather than our community
> repository).

I was under the impression that the purpose of the script was to replace
cvs2cl and do approximately what cvs2cl did.  If you have another
use-case then please explain what it is and why this change is bad
for it.
        regards, tom lane

On Sun, Sep 26, 2010 at 12:08 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Sun, Sep 26, 2010 at 1:51 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> Still more tweaking of git_changelog.
>
>> Uhm, could you stop massively changing the behavior of this script
>> with no discussion at all?
>
> Uh, there was no discussion of the original behavior of the script
> either.

It was posted to the list weeks before it was committed and it was
discussed by multiple people at that time.  We didn't debate every
detail of the behavior but there was certainly ample space for public
comment.

>> I happen to think that this is a
>> distinctly bad idea.  It defeats one of the major use cases of the
>> original script, which is being able to easily figure out which
>> branches a certain commit is in.
>
> Hm?  As far as I can tell, this fixes that not breaks it.  The problem
> I was seeing was that commits would be attributed to a branch when in
> fact they were made before the branch ever existed.

But the commits are still on any subsequently-created branches.
Frequently, I'm trying to figure out the first release that contains
some particular change.  Say, tablespaces.  So I go back and look
through the git log and find the commit.  And here it is:
2467394ee1566e82d0314d12a0d1c0a5670a28c9.

Now I want to know which branches contain that commit.  With the old
coding, I can just run this script, and it'll tell me all the branches
REL8_0_STABLE and higher have that commit.  If the abbreviated SHA1
hashes are the same, I know that the commit was actually done before
the branch points for those releases.  If they're different, I know
that the commit was back-patched into those branches.  With your
changes, all I get is:

Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [2467394ee] 2004-06-18 06:14:31 +0000

...which is much less useful, at least given that I don't have the
dates of all the branch points memorized.

> I was under the impression that the purpose of the script was to replace
> cvs2cl and do approximately what cvs2cl did.  If you have another
> use-case then please explain what it is and why this change is bad
> for it.

See above.

Thanks,

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

Robert Haas <robertmhaas@gmail.com> writes:
> On Sun, Sep 26, 2010 at 12:08 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Hm? �As far as I can tell, this fixes that not breaks it. �The problem
>> I was seeing was that commits would be attributed to a branch when in
>> fact they were made before the branch ever existed.

> But the commits are still on any subsequently-created branches.
> Frequently, I'm trying to figure out the first release that contains
> some particular change.  Say, tablespaces.  So I go back and look
> through the git log and find the commit.  And here it is:
> 2467394ee1566e82d0314d12a0d1c0a5670a28c9.

> Now I want to know which branches contain that commit.  With the old
> coding, I can just run this script, and it'll tell me all the branches
> REL8_0_STABLE and higher have that commit.  If the abbreviated SHA1
> hashes are the same, I know that the commit was actually done before
> the branch points for those releases.  If they're different, I know
> that the commit was back-patched into those branches.

Well, all I can say is that I find that unnecessarily verbose, and
that in ten years of working with cvs2cl I can't recall ever once
wishing that it would behave that way.

What I do often wish is that it were easier to tell which point-releases
a given patch was applied between, ie, if it's on the 8.4 branch did it
appear in 8.4.1, 8.4.2, etc.  But neither of these behaviors is useful
for that.

If we could figure out how to show which major release a master-branch
commit antedated, and which point release a back-branch commit
antedated, I think we would have something that's actually significantly
more useful for both purposes than either of these behaviors.  It would
show you what you want without having to make nonobvious deductions
from comparisons of commit hashes, and it would also ease my main
use-case which is "which point release did that get fixed in?"

I've experimented with git log --all --source but it tends to make
unhelpful choices of which tag to report; maybe the secret would be
to limit the set of tags it chases from?
        regards, tom lane

I wrote:
> If we could figure out how to show which major release a master-branch
> commit antedated, and which point release a back-branch commit
> antedated, I think we would have something that's actually significantly
> more useful for both purposes than either of these behaviors.

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.  However, I'm not seeing a convenient way to extract the
commit SHA1s pointed to by the available tags.  git tag doesn't tell
this and git show provides way too much information.  Anybody know the
right incantation for that?
        regards, tom lane

On Sun, Sep 26, 2010 at 1:25 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I wrote:
>> If we could figure out how to show which major release a master-branch
>> commit antedated, and which point release a back-branch commit
>> antedated, I think we would have something that's actually significantly
>> more useful for both purposes than either of these behaviors.
>
> 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.  However, I'm not seeing a convenient way to extract the
> commit SHA1s pointed to by the available tags.  git tag doesn't tell
> this and git show provides way too much information.  Anybody know the
> right incantation for that?

git rev-parse REL8_3_0

But I still want an option for the original behavior.  I have been
using it extensively and I like it.

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

Robert Haas <robertmhaas@gmail.com> writes:
> But I still want an option for the original behavior.  I have been
> using it extensively and I like it.

You really think this:

Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [872c1497f] 2005-05-24 18:02:31 +0000
Branch: REL9_0_STABLE [872c1497f] 2005-05-24 18:02:31 +0000
Branch: REL8_4_STABLE [872c1497f] 2005-05-24 18:02:31 +0000
Branch: REL8_3_STABLE [872c1497f] 2005-05-24 18:02:31 +0000
Branch: REL8_2_STABLE [872c1497f] 2005-05-24 18:02:31 +0000
Branch: REL8_1_STABLE [872c1497f] 2005-05-24 18:02:31 +0000
Branch: REL8_0_STABLE [a94ace079] 2005-05-24 18:02:55 +0000
Branch: REL7_4_STABLE [0a7b3a364] 2005-05-24 18:03:24 +0000
   Previous fix for "x FULL JOIN y ON true" failed to handle the case   where there was also a WHERE-clause restriction
thatapplied to the   join.  The check on restrictlist == NIL is really unnecessary anyway,   because
select_mergejoin_clausesalready checked for and complained   about any unmergejoinable join clauses.  So just take it
out.

is preferable to something like

Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master Release: REL8_1 [872c1497f] 2005-05-24 18:02:31 +0000
Branch: REL8_0_STABLE Release: REL8_0_4 [a94ace079] 2005-05-24 18:02:55 +0000
Branch: REL7_4_STABLE Release: REL7_4_9 [0a7b3a364] 2005-05-24 18:03:24 +0000
   Previous fix for "x FULL JOIN y ON true" failed to handle the case   where there was also a WHERE-clause restriction
thatapplied to the   join.  The check on restrictlist == NIL is really unnecessary anyway,   because
select_mergejoin_clausesalready checked for and complained   about any unmergejoinable join clauses.  So just take it
out.

?  It's not hard to offer an option for that, I guess, but I foresee an
argument about what the default is going to be.
        regards, tom lane

On Sun, Sep 26, 2010 at 2:07 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> [Do you really want the behavior you said you wanted?]

Yes.

> ?  It's not hard to offer an option for that, I guess, but I foresee an
> argument about what the default is going to be.

If there's no clear consensus, I'm OK with the time-honored tie-break
of "he who does the work...".

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

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

Robert Haas <robertmhaas@gmail.com> writes:
> On Sun, Sep 26, 2010 at 2:07 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> ? �It's not hard to offer an option for that, I guess, but I foresee an
>> argument about what the default is going to be.

> If there's no clear consensus, I'm OK with the time-honored tie-break
> of "he who does the work...".

How about

Usage: git_changelog [--post-date/-p] [--since=SINCE]   --post-date Show branches made after a commit occurred
--since    Print only commits dated since SINCE
 

?  Got a better name for it?
        regards, tom lane

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

On Sun, Sep 26, 2010 at 4:38 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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.

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.

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

Robert Haas <robertmhaas@gmail.com> writes:
> On Sun, Sep 26, 2010 at 4:38 PM, Tom Lane <tgl@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.
        regards, tom lane

On Sun, Sep 26, 2010 at 8:24 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Sun, Sep 26, 2010 at 4:38 PM, Tom Lane <tgl@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

Robert Haas <robertmhaas@gmail.com> writes:
> On Sun, Sep 26, 2010 at 8:24 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> 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.

If we ever start doing things like sub-branches it's likely to need
more work, but I suggest that that would have been true anyway.
I don't believe that the current version shows a different set of
commits from the original (other than endpoint bugs...).

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

I apologize if I offended you.  I hadn't believed that there was any
particular consensus on how this script ought to behave; I thought
it was something you'd whipped up in an hour based on my request for
something like cvs2cl, and that making it work more like that would be
uncontroversial.
        regards, tom lane

<div dir="ltr"><div class="gmail_quote">On Mon, Sep 27, 2010 at 3:03 AM, Robert Haas <span dir="ltr"><<a
href="mailto:robertmhaas@gmail.com">robertmhaas@gmail.com</a>></span>wrote:<br /><blockquote class="gmail_quote"
style="margin:0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="im">On Sun,
Sep26, 2010 at 8:24 PM, Tom Lane <<a href="mailto:tgl@sss.pgh.pa.us">tgl@sss.pgh.pa.us</a>> wrote:<br /> ><br
/></div><br/> I maintain that if someone else whacked around one of your commits the<br /> way you whacked this around,
you'dbite their head off.<br /><div class="im"><br /></div></blockquote></div><br />:) Yes, he would. And you are not
beingany less forgiving either.<br /><br />#ilovepostgrescommunity<br clear="all" /><br />-- <br />gurjeet.singh<br />@
EnterpriseDB- The Enterprise Postgres Company<br /><a
href="http://www.EnterpriseDB.com">http://www.EnterpriseDB.com</a><br/><br />singh.gurjeet@{ gmail | yahoo }.com<br
/>Twitter/Skype:singh_gurjeet<br /><br />Mail sent from my BlackLaptop device<br /></div> 

On Sun, Sep 26, 2010 at 9:14 PM, Gurjeet Singh <singh.gurjeet@gmail.com> wrote:
> On Mon, Sep 27, 2010 at 3:03 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>>
>> On Sun, Sep 26, 2010 at 8:24 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> >
>>
>> I maintain that if someone else whacked around one of your commits the
>> way you whacked this around, you'd bite their head off.
>>
>
> :) Yes, he would. And you are not being any less forgiving either.
>
> #ilovepostgrescommunity

I actually do love the PostgreSQL community, and I really enjoy
working with Tom.  This does not mean that we won't disagree about
things some times, and I do put on my flame-retardant undergarments
every time I sit down to read -hackers.  That's OK.  It's still an
awesome community, and that is why I put the time and effort into it
that I do (he writes at 9PM on a Sunday night).

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

On Sep 26, 2010, at 2:24 PM, Tom Lane wrote:

> 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.


Particularly with PostgreSQL's linear branch history, `git merge-base` will show you the point at which the branches
divergedfrom master: 

$ git merge-base origin/REL9_0_STABLE master
1084f317702e1a039696ab8a37caf900e55ec8f2

$ git show 1084f317702e1a039696ab8a37caf900e55ec8f2
commit 1084f317702e1a039696ab8a37caf900e55ec8f2
Author: Marc G. Fournier <scrappy@hub.org>
Date:   Fri Jul 9 02:43:12 2010 +0000
   tag beta3

Also, the `git describe` command can be used to identify the closest tag a specific commit is a part of:

$ git describe --tags 6d297e0551a2a3cc048655796230cdff5e559952
REL9_0_BETA2-153-g6d297e0

This indicates that the indicated commit is the 153rd commit after the REL9_0_BETA2 tag (and includes the abbreviated
SHA1for unique identification in the case that there are multiple branches which have since been re-merged; not the
casein this project, but still handy for uniqueness). 

The command `git branch --contains` will come in handy for commits which are the exact same content (ignoring the
commitparentage and time and using only the patch-id (`git --help patch-id`)).  This obviously won't catch commits
wherethe changed content had to be modified in the back-patching process, but could serve as a quick basis.  (In truth,
thismay be relatively useless, as I tried to find an example which included back-branches, but wasn't able to find an
exampleoff-hand.)  In any case, the option exists... :-) 

$ git branch -a --contains 2314baef38248b31951d3c8e285e6f8e4fd7dd05
* master remotes/origin/HEAD -> origin/master remotes/origin/REL8_4_STABLE remotes/origin/REL8_5_ALPHA1_BRANCH
remotes/origin/REL8_5_ALPHA2_BRANCHremotes/origin/REL8_5_ALPHA3_BRANCH remotes/origin/REL9_0_ALPHA4_BRANCH
remotes/origin/REL9_0_ALPHA5_BRANCHremotes/origin/REL9_0_STABLE remotes/origin/master 

Regards,

David
--
David Christensen
End Point Corporation
david@endpoint.com

David Christensen <david@endpoint.com> writes:
> On Sep 26, 2010, at 2:24 PM, Tom Lane 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.

> Particularly with PostgreSQL's linear branch history, `git merge-base` will show you the point at which the branches
divergedfrom master:
 

> $ git merge-base origin/REL9_0_STABLE master
> 1084f317702e1a039696ab8a37caf900e55ec8f2

Ah-hah, I figured there had to be some plumbing command that would get that.
The current version of the script siphons the information off from git
log --parents, but it'd likely be cleaner to do it with git merge-base.
It might be a bit slower though --- some experimentation here says that
git merge-base takes a bit of time, which isn't surprising if I'm right
in guessing that it has to chase back from the two branch heads looking
for a commit in common.  That's going to basically duplicate work that
git log has to do also.
        regards, tom lane

Tom Lane <tgl@sss.pgh.pa.us> writes:
> Author: Tom Lane <tgl@sss.pgh.pa.us>
> Branch: master Release: REL8_1 [872c1497f] 2005-05-24 18:02:31 +0000
> Branch: REL8_0_STABLE Release: REL8_0_4 [a94ace079] 2005-05-24 18:02:55 +0000
> Branch: REL7_4_STABLE Release: REL7_4_9 [0a7b3a364] 2005-05-24 18:03:24 +0000
>
>     Previous fix for "x FULL JOIN y ON true" failed to handle the case
>     where there was also a WHERE-clause restriction that applied to the
>     join.  The check on restrictlist == NIL is really unnecessary anyway,
>     because select_mergejoin_clauses already checked for and complained
>     about any unmergejoinable join clauses.  So just take it out.

It's easy enough to find it on the website too, or to search for some
other patch as I did this morning:
 http://git.postgresql.org/gitweb?p=postgresql.git;a=commit;h=872c1497f
http://git.postgresql.org/gitweb?p=postgresql.git;a=commit;h=40608e7f949fb7e4025c0ddd5be01939adc79eec

Having your proposed output in there would be awesome, because the use
case of determining which releases contain the patch is a *huge* one of
course --- and gitweb searches are easy, fast and convenient.

Now I can't comment on the git_changelog tool chapter, so that's a
little Off Topic, but still. Can we do something about the gitweb
interface to include such a feature?

Regards,
-- 
dim

Dimitri Fontaine <dfontaine@hi-media.com> writes:
> Tom Lane <tgl@sss.pgh.pa.us> writes:
>> Author: Tom Lane <tgl@sss.pgh.pa.us>
>> Branch: master Release: REL8_1 [872c1497f] 2005-05-24 18:02:31 +0000
>> Branch: REL8_0_STABLE Release: REL8_0_4 [a94ace079] 2005-05-24 18:02:55 +0000
>> Branch: REL7_4_STABLE Release: REL7_4_9 [0a7b3a364] 2005-05-24 18:03:24 +0000
>
>   http://git.postgresql.org/gitweb?p=postgresql.git;a=commit;h=872c1497f
>   http://git.postgresql.org/gitweb?p=postgresql.git;a=commit;h=40608e7f949fb7e4025c0ddd5be01939adc79eec
>
> Can we do something about the gitweb interface to include such a feature?

Please?
-- 
dim

Tom Lane wrote:
> > I maintain that if someone else whacked around one of your commits the
> > way you whacked this around, you'd bite their head off.
> 
> I apologize if I offended you.  I hadn't believed that there was any
> particular consensus on how this script ought to behave; I thought
> it was something you'd whipped up in an hour based on my request for
> something like cvs2cl, and that making it work more like that would be
> uncontroversial.

I am hoping git_changelog wil be like pgcvslog so I can easily create
the 9.1 major release notes someday.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +