rev-list behavior in mail notification when pushing multiple branches

[Tim Niemueller <niemueller@kbsg.rwth-aachen.de>]

Hi.

We are using git to manage a project which is separated in multiple
repositories. We use email notification for commits to the central
repositories, but the log output in these mails is not what we expect.
We use the contrib hook script from the git repository.

The main repository contains the trunk, in the real sense, meaning that
it is composed of infrastructure code shared among all repositories, not
in the svn sense. The other repositories contain the trunk master branch
as "trunk" branch. Their own master branch is based on trunk, but
extended by additional modules. We regularly merge from the main
repository into the other repositories trunk.

Consider the following situation:

--*---X-------Y     master branch
     /       /
A---B--C*---D       trunk branch

master has been ultimately derived from trunk. At X trunk changes up to
C have been merged into the master. Then trunk evolves but master
remains unchanged. We merge again everything up to D from trunk. Now
assume that we haven't pushed since B/X and now push after D/Y. Then
there are two mails to be generated, one for master X..Y, effectively
containing log message Y (merged...), and one for trunk B..D, C* is any
number of intermediate commits to the trunk.

It happens to be that master has been pushed first. The email contains
the expected output in the log section. However, for the trunk branch
the output unexpectedly is empty, meaning that information about C* is
never send in any mail.

The reason is the following: in show_new_revisions "rev-parse --not" is
used to generate "stop" points for rev-list. The stop point issued for
the master branch is Y. This causes rev-list to stop immediately, since
this is the last commit in the chronological order.

What we would like to have is the that the master mail only states
"merged trunk changes" (as it is right now, if there were commits
between X and Y these should be included as well), while the trunk mail
issues all C* commits and D.

I have tried to come up with a way to filter out entries from the mails
that have been issued on "the other" branch(es) originally (although
they are now /after/ merging also part of the this branch's history).
Since gitk can show this there should be a way to figure it out, but my
git-fu isn't strong enough, yet. Can someone give advice on how to
achieve this, or how you solved the problem, if you did?

Thanks,
	Tim

-- 
AllemaniACs RoboCup Team            KBSG - Knowledge-Based Systems Group
========================================================================
http://robocup.rwth-aachen.de                     RWTH Aachen University
http://www.kbsg.rwth-aachen.de                           Ahornstrasse 55
http://www.fawkesrobotics.org                             D-52056 Aachen