Skip to content

Wip 81 log graph - #2628

Draft
peso wants to merge 21 commits into
gitui-org:masterfrom
peso:wip-81-log-graph
Draft

Wip 81 log graph#2628
peso wants to merge 21 commits into
gitui-org:masterfrom
peso:wip-81-log-graph

Conversation

@peso

@peso peso commented Apr 29, 2025

Copy link
Copy Markdown
Contributor

This Pull Request is wip towards fixing #81

It changes the following:

  • work-in-progrss for adding git-graph DO NOT MERGE

Lots of bugs and strange behaviour

@peso
peso marked this pull request as draft May 3, 2025 07:17
@kooshi

kooshi commented May 23, 2025

Copy link
Copy Markdown

Hey man, if you accomplish this, you will be my hero. Thanks for tackling it!

@peso

peso commented Jun 23, 2025

Copy link
Copy Markdown
Contributor Author

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.

@yk-kd

yk-kd commented Jul 14, 2025

Copy link
Copy Markdown

Fonts can be made configurable to display graphs more neatly.
So it would be great if you could make the letter of the join configurable.

kovidgoyal/kitty#7681
https://github.com/rbong/vim-flog
https://www.reddit.com/r/neovim/comments/1ec118n/git_graph_teaser/

@peso

peso commented Jul 14, 2025

Copy link
Copy Markdown
Contributor Author

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.

@yk-kd

yk-kd commented Jul 14, 2025

Copy link
Copy Markdown

Sorry if I'm wrong.

-s, --style <style>      Output style. One of [normal/thin|round|bold|double|ascii].

I thought style could only be set up from these five, since it was written above.

@peso

peso commented Jul 15, 2025

Copy link
Copy Markdown
Contributor Author

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.

peso added 21 commits July 30, 2026 05:57
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.
@peso
peso force-pushed the wip-81-log-graph branch from e97e0bc to f1e12b2 Compare August 11, 2026 05:16
@peso

peso commented Aug 11, 2026

Copy link
Copy Markdown
Contributor Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants