Gated Merge?

I wish there were a way to let me annotate a commit with a statement like this:

 * When merging a branch that does not have me in it into a trunk
   that already has me, do this extra check on the result of the
   merge before allowing it to be recorded.

For example, suppose there is a topic that changes all instances of this

	__attribute__((format(printf, X, Y)))

into a new macro FORMAT_PRINTF(X, Y). With such a facility, I can annotate the commit at the tip of that series to define an extra check:

   ! git diff HEAD | grep '^+.*__attribute__((format(printf'

which would prevent me from merging a topic that introduces a new instance of the printf-format attribute that is spelled in an old-fashioned way.

In this particular example, it might be even better if the facility allowed me to declare something like this instead:

 * When merging a branch that does not have me in it into a trunk
   that already has me, do this extra processing on the result of
   the merge before recording it.

The difference between them is the "extra processing" part. For this example, it would be something that is built around:

    perl -p -e '
        s{__attribute__\(\(format\(\s*printf,\s*(\d+),\s*(\d+)\)\)\)}
         {FORMAT_PRINTF($1, $2)}gx
    '

to update the old-fashioned one to use the new macro, and the result would become an evil merge.

To realize this, there are low-hanging-fruit building blocks that are trivial:

 - Such an annotation can be made as a note attached to the commit
   in question;

 - Such a check can be done in pre-commit hook;

 - Such a pre-commit hook can iterate over this set of commits

    DIFF=$(git rev-list --left-right HEAD...MERGE_HEAD)
    
   collect these Merge Gate annotations from the commit appears on
   the left hand side (e.g. only exists on the trunk that a side
   branch is about to be merged in), and run them.

But the last one feels very costly, and I suspect that there must be a better way to do this. I do not think we want the "what to do" part (i.e. checking new lines for __attribute__ in the first example, or rewriting new lines that has __attribute_ in the second example) to be in git-core; that clearly is outside the scope of the plumbing. But the part that finds these "annotations", especially if we can come up with a fast implementation that may be hard to script, may be a good addition to the plumbing command set.

Thoughts?