Revision Graph - view "main history" of a branch vs merged branches
When exploring the history of a non-trivial repository, with plenty of branching and merging, it's not feasible to understand from the Revision Graph the same kind of ancestry that you can see from the regular log.
This image shows a fragment of TortoiseGit's own history to illustrate what I mean:
In the log on the right, you can see that the main branch, the one on the left, has the sequence:
The 0c7739c4 commit on main was a merge of a temporary branch called RevisionGraph (judging by the commit message), which is represented in red in the log, with history:
- af6d431e
- dfc52545
- a019c4b5
- f1099f3f
- ... This red branch in turn at some point merged into it a pull request from ch3cooli/ogdf-utf8, etc.
Now, the problem is on the interpretation of the revision graph by itself.
Since the layout being applied does not guarantee a vertical alignment of the main ancestry of each branch, i.e. following the first-parent, there's no way to know on the graph that the main parent of commit 0c7739c4 if the path on the right, and the left one is the branch that got merged in.
I added the color arrows to match one view against the other, but it would be extremely useful to be able to pinpoint just by looking at the graph what path is the main one when navigating backwards at each merge point.
What could be implemented
Elaborate features that could be added could be improving somehow the layout being applied to the graph (instead of ogdf::SugiyamaLayout
?), or the introduction of arrow colors to identify the ancestry of each branch from the moment it diverged till it got reintegrated again, just like we see on the Log view.
However, one adjustment that might be much simpler to implement and could improve a lot the usefulness of the graph, would be to simply mark the arrows with a different style or color, irrespective of the branch. If the first parent of each merge commit is shown with a certain arrow style/color, and any additional parents have a different one, we'd be navigating the history of "main" and when reaching 0c7739c4 we know that the arrow on the right is the fist parent, while the one on the left is a branch that got merged into main.
I don't really have a dev environment or the experience to submit a working merge request, but looking at the code it seems that the key thing to do would be to identify which graph edges are the main vs secondary ones here based on whether it's the first commit parent or not, store that on the graphAttrs (?), and when drawing here use the info about the edge to draw it with a different pen to be visually different and help the user interpret the "correct path" of the branch history.