[RFC] cherry-pick using multiple parents to implement -x

I've been converting some old CVS repositories to git, and as it turns out, these repositories consist of a number of main branches of the same project that were created at several points in time (the stable release branches), and the branches contain numerous backports (and a few forward ports) between each other.

I.e. the branches split off each other at various points in time, and evolved independently ever since (except for the numerous backports).

Now, the backports can be implemented using a mere "git cherry-pick -x", but that creates this silly text references to the original commits. I'd rather use something that gitk can visualise.

So I tried to use the parents of the commit to reference the origin(s). I.e. the first parent links to the linear history on a given branch, but the second (and possibly more) parents point to the cherry-picked back-ported commit from another branch. This graft-constructed repository is then fed to filter-branch to make it permanent. To view it try: git://pike-git.lysator.liu.se/pikex

This works quite well and shows the following results:
- gitk shows proper grafts.
- gitk properly shows a zero-diff between the new commit and the
  commits we cherry-picked from.
- It even works perfectly when picking from multiple parents.
- gitk is confused in its display of tags preceding and following this
  commit (depending on the situation it mixes up the branches).

Obviously the reason it works rather well is because git can actually distinguish between a merge and a backport because of the way the contents of the trees change.

The questions now are:
- Would there be good reason not to record the backport/forwardport
  relationship in the additional parents of a commit?
- Since most of the git machinery (git diff, and gitk, most notably)
  seem to work just fine when using parents for that purpose, would it
  be acceptable to create a patch to cherry-pick to support an option to
  record the backport/forwardport relationship in the second (or more)
  parent field(s)?
- And depending on an affirmative on the previous question, would it be
  acceptable to teach the gitk preceding/following tag listing to deal
  with these backport/forwardports ?