rev-list behavior in mail notification when pushing multiple branches

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