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