Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Simplify column assignment algorithm #654
A graph configuration is found that is not correctly handled using current way to maintain occupied column set. If all children of a fork commit are merges and they are assigned a column before the commit processing then no one of children will be assigned same column. Also, no one of them will left parent's column because of the condition in the main loop. In other configuration the column is left when a non-fork ancestor at the column merges. But, in current configuration, no child remains on the column. As a result, the column 'leaks'. This causes the graph spreading.
Such configuration is not found in Git-Cola graph. I've found one in Qemu graph. After selected fork the 7-th column leaks.
Investigating the bug I have realized that fixing up the predicate is possible but it will result in new nested loop. Instead, another way was found. It is described in comments and commit messages.
This is great. I wonder if it would be resilient to octopus merges, and octopus over octopus. I don't think I've ever seen those in the wild, though ;-)
One thing I noticed is that the first-parent chain seems to get lost on the right side, and this tiny tweak seems to make keep things left-aligned
I'm going to merge this as-is, but might apply that on top later. What do you think?
The negative offset seems to work ok on the qemu repo too. In the cola repo the first-parent history chain become easier to see with a negative x offset. Any downsides?
There also seems to be a rendering artifact from overlapping tags with the commit circle (
Feb 1, 2017
1 check passed
The problem is detection of 'first' ('main') chain. (I think, 'first-chain' is the one that was 'master' before the merge. Correct me if it is wrong.) If 'master' branch consists of merge commits only then the heuristic in column distribution assigns same column to those merge commits. Because generation of each other is gather than generation of any other child of the fork. But, in real life, 'master' contains regular commits too. It is not clear how to distinguish what branch is 'main'. In fact, same generation commits is assigned random columns. As a result, the first-parent chain is shifted to side.