Wip 81 log graph - #2628
Conversation
|
Hey man, if you accomplish this, you will be my hero. Thanks for tackling it! |
|
Right now I'm working on refactoring git-graph so the git backend can be swapped. It is based on git2 and gitui is moving away from git2 towards gix. |
|
Fonts can be made configurable to display graphs more neatly. kovidgoyal/kitty#7681 |
|
The symbols are already configurable. git-graph (not the vs code plugin "git graph") has a configurable option called "style" to change the symbols used. Regarding the specific symbols you link to, git-graph issue 90 requests the enhancement you propose. Note however, that the proposed symbol-set is larger than the current symbol-set and thus require some changes at the algorithm level. It is a bit more work than simply changing the symbols. |
|
Sorry if I'm wrong.
I thought style could only be set up from these five, since it was written above. |
|
You are right. As a user you can only change symbols by picking one of the predefined styles. There is no support for changing a single symbol (eg. "join") in a style. |
This is preparation for a log graph implementation. In case of a diamond graph where the common ancestor has a newer date than some of its children, the walk order of the current code will violate topology order. If commits are not in topology order, a graph may have to draw a parent before its child. This is confusing to the user and require extra memory for the graph render algorithm.
LogWalker uses git2, due to SharedCommitFilterFn
LogWalkerWithoutFilter is based on gix, so it touches a different part of the code.
When a commit graph can be shown, this allows us to see multiple branches next to each other.
These functions are relevant to gleisbau
By separating model and view data it is easier to see what is going on.
Adding parent information to CommitInfo will increase memory usage significantly, but makes it possible to build the branch graph. This is a prototype. When a PR is made to gitui it could reduce the memory impact.
CommitList is the view that shows the log graph. It stores commits and their data, therefore TrackMap belongs there. It is already updated by a thread found in asyncgit. This thread will be expanded to include walking the graph. Use layout_track_range to layout a subset of the graph.
Return walk error if one occurrs.
The graph should be rendered in a different location in code, so the marker can be on the left side of the graph.
To make branch column more stable, add a window around what is visible. Only update the window when trying to show something outside.
|
The current code is a little more stable than that from a year ago. It still has a lot of rough edges and performance is much better but still not good enough if too many branches are present. |
This Pull Request is wip towards fixing #81
It changes the following:
Lots of bugs and strange behaviour