Like embee, I'm curious about those backport grafts that appear as merges. Is this only a problem of representation in gitk and git-log? To me it seems odd to describe them as merges since I reckon that content would be identical after a merge.
I did some backchecks on the git mailinglist now, and it appears that I was a bit overly optimistic in my assumption that git is able to distinguish between backports and merges based on parenthood alone.
The recommended practice is that for back/forwardports the commit id's of the originating cherry-picked patches are mentioned at the bottom of the new commit message.
Unfortunately that won't help (if we) in the future use git for backports, since the new backports will get the same graphs once again.
I believe the problem lies in how gitk determines what branch(es) a commit is on rather than on our use of grafts for backports.
This means that I'll have to regenerate the backport/forwardport way of linking to modify the commit messages instead of the graft/parent list. -- Sincerely, Stephen R. van den Berg.