I'm porting an svn repo to git (using svn2git from https://www.negativetwenty.net/redmine/projects/show/svn2git) and since svn does not track merges, I need to edit .git/info/grafts manually. For this, I launch gitk, search for the term "Merge" in commit messages, verify that the merge commits have the right ancestry and populates .git/info/grafts acordingly.
The issue I'm having is that gitk seems to be confused with the "master" branch. It often shows master being "forked" from a branch and being merged into a branch afterword, when actually it is the opposite.
Why is it unable to understand that master should be "as linear" as possible and it's the branch that should be forked from it, not the opposite? Is it a gitk issue or is the history of the git repo incomplete? It seems "git log --pretty=oneline --graph" is able to show the correct behaviour so I'm thinking it might be a gitk issue.
I also tried giggle and qgit, but both have their problem. I find giggle's tree hard to understand (merges are horizontal for example, while in qgit and gitk they are oblique...) and qgit seems to not show some commits (the commit creating the branch in svn is shown as a git commit in both "git log --pretty=oneline --graph" and gitk, but not in qgit nor giggle).
Note that I use "gitk --all" in my tests.
So my question is: -How can I force gitk to show master as linear as possible? Ideally "left justified" with branches being forked from it, not the opposite. "git log --pretty=oneline --graph" seems to be doing it the right way, but what about gitk?
Thanks!
Edit: Screenshot links are dead. Previously said:
I have uploaded screenshots of the different tools: git log, gitk, giggle, qgit
See how "git log" shows the branch being merged into trunk, while gitk shows trunk being merged in branch. Giggle and qgit shows the right merge, but they often drop some commits (creating branches) so it's really hard to manualy edit the .git/info/grafts file.
After playing with different GUI, the behaviour really seems to be tool dependent. Saddly, not many of them are configurable...
I prefer having a tree view of what actually happened compared to an optimized view where everything fits...
I have settled for "gitg" (http://trac.novowork.com/gitg/). Seems relatively active, and it does exactly what I expect from the history view. Master is the left most "lane", branches are forked from it and merged into it from the right. I feel it is consistent with my workflow. Also, I can show "inactive lanes" so master is always shown and on the left-most side (enable/disable in preference window). A nice thing also is the "Show history in topological order". When checked, gitg will try to place commits on a branch together. When unchecked, they will appear in chronological order.
It can also do basic commits and staging.
Only drawback I can find is the search: it seems I cannot enter an sha1sum and find the right commit. Maybe just a bug.
About the original question (can gitk be configured the way I want it?) I'm still not sure it's possible. Probably a design decision...
See how "git log" shows the branch being merged into trunk, while gitk shows trunk being merged in branch.
That is because gitk freely reorders parents — as do many other tools. The leftmost parent is not always the 1st parent. Often tools put the parents whereever there is space. It ultimately provides for a more packed view. Compare:
- http://i53.tinypic.com/29lfyti.png - git log makes "master" wind around the "nucrypt2" branch so that the X'th (X>=2) parent is always right of the merge
- http://i52.tinypic.com/sc7r5v.png - git-forest, default
- http://i51.tinypic.com/28iatjd.png - same, with merge shortcut seeking disabled
I find git-log's graphing not very ergonomic - it takes more blank lines.
If you have a github account, you could try the "Network" view on there too.
来源：https://stackoverflow.com/questions/4511416/gitk-weird-history-tree