Martin Stjernholm, Roxen IS @ Pike developers forum wrote:
As for now, until the fully backport-connected history is finished and the patch to gitk is in, you can reduce the clutter in the gitk view by using: gitk --first-parent 7.8 7.6 7.4 7.2 7.0 0.6 0.5
That doesn't make any difference for my little test case src/pike_memory.c. I use git 1.5.4.3.
Well, it should, because it removes all the backport info, but then again maybe not all commands you are using are honouring the --first-parent flag. However, instead of pursuing this...
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.
Gitweb already automatically transforms them into clickable links, gitk probably still needs patches to make them both clickable as well as draw a visual dotted line in the treegraph to show the relation.
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.