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.

0 files changed, 0 insertions, 0 deletions