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 16:42:22
Message-ID: 6582.1285519342@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Sun, Sep 26, 2010 at 12:08 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Tom Lane 2010-09-26 17:25:43 Re: [COMMITTERS] pgsql: Still more tweaking of git_changelog.
Previous Message Robert Haas 2010-09-26 16:25:09 Re: [COMMITTERS] pgsql: Still more tweaking of git_changelog.

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2010-09-26 16:52:34 Re: C function to return tuple
Previous Message Marios Vodas 2010-09-26 16:38:33 Re: C function to return tuple