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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [COMMITTERS] pgsql: Still more tweaking of git_changelog.
Дата
Msg-id 6582.1285519342@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [COMMITTERS] pgsql: Still more tweaking of git_changelog.  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: [COMMITTERS] pgsql: Still more tweaking of git_changelog.  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Marios Vodas
Дата:
Сообщение: Re: C function to return tuple
Следующее
От: Tom Lane
Дата:
Сообщение: Re: C function to return tuple