gitk: weird history tree

Question

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.

Messidor

Is your graft expressed as <merge commit> <master parent> <branch parent>? That should specify which parent comes first. – Plunk

Yes it is. I made sure the second commit id is the id of the branch merging (normally master) to and the third/last id being the one from the branch. "git log" does show it correctly though... – Messidor

These images seem to have disappeared. Any chance you still have them and could upload to imgur or insert directly into your question? – Tude

Answer 1

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.

Holophrastic

After playing with different GUI, the behaviour really seems to be tool dependent. – Messidor

Actually, I use "git log --pretty=oneline --graph" in an alias so it's more ergonomic. I still prefer to see a branch being merged in master (when I actually merged a branch in master) instead of master being merged into a branch. Merging into both direction is valid, so why confuse things in the display? I'll take a look at git-forest. Thanx! – Messidor

One could argue that reading the commit message "merged X into Y" should provide the necessary info ;-) Furthermore, since git does not keep track which branch (by name) is an ancestor of another (2 bretheren commits sharing the same parent have the same rank), so the concept of branch relationships is more diffuse. (Some ideas about the case...) – Holophrastic

an improvement to the line coloring might help, basically keep the same color as the first parent, although there are some edge cases to deal with – Mimimimic

These images seem to have disappeared. Any chance you still have them and could upload to imgur or insert directly into your answer? – Tude

Answer 2

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...

Messidor

Answer 3

If you have a github account, you could try the "Network" view on there too.

Cue