Comparison with gitgraph.nvim

[rbong]

I have noticed a spike in traffic from comparisons with gitgraph.nvim so I have added a comparison to the FAQ. I am posting this for visibility.

gitgraph.nvim is a work in progress, so the details here may change.

Summary:

gitgraph.nvim's graph drawing algorithm aims for a better graph on large repos. It currently is much slower at the initial rendering of the graph.

gitgraph.nvim currently has more accurate branch highlighting than Flog. Branch highlighting may also be more performant in gitgraph.nvim while scrolling in large repos and on weaker machines.

Both Flog and gitgraph.nvim are customizable.

Flog supports Vim and Neovim. gitgraph.nvim only supports Neovim.

Flog is designed as an extension to fugitive.vim. gitgraph.nvim has hooks to integrate with plugins such as diffview.

gitgraph.nvim and Flog both have good code quality. gitgraph.nvim has not yet gone through aggressive optimizations with its branch drawing functions, so it is much cleaner and more readable.

Flog focuses on integration tests instead of unit tests. There is only one branch drawing function in Flog for optimization. This eliminates function call overhead, but means that we don't have small branch drawing functions to individually unit test. Integration tests also ensure the plugin works end-to-end.

gitgraph.nvim has a different testing strategy which uses unit tests. These types of tests typically allow more easily identifying the exact spot where code is failing.

Flog has features which have no equivalent in gitgraph.nvim currently. This includes commit marks, some navigation mappings, and contextually aware command completion.

[rbong]

I have removed the initialization time comparison for now. gitgraph.nvim is continually improving their speed and I don't want to misrepresent it.

Flog has also had speed improvements and I'm noticing that when I only render with -max-count values a few thousand commits apart, the run times are negligibly different. I think I am just measuring initialization overhead when using a -max-count of at least 10,000 or less. I have had trouble running gitgraph.nvim with this many commits without running out of memory, so I can't fairly compare either plugin right now.

Note my memory issues with gitgraph.nvim could be entirely environment specific to me, I haven't reported the issue yet properly either. It's not meant to be taken as representative of the plugin.

[rbong]

Trying to determine some of the differences in branch drawing logic.

An easy one is that in Flog if a parent appears for the last time in the graph, it will be shown "tapering off", and will be removed from the graph in order to save horizontal space. gitgraph.nvim currently doesn't have an equivalent.

I believe another difference is that if a commit is a parent of more than one commit, gitgraph.nvim will defer showing forking until the parent commit is encountered, where Flog shows the fork right away.

For example, here is a graph in Flog:

• [A]
│
│ • [B]
├─┤
│ • [C]
│ │
│ • [D]
├─╯
│ • [E]
│ ├─╮
│ │ │ • [F]
│ │ │ │
│ │ │ │ • [G]
│ │ │ │ │
│ • │ │ │ [H]
│ ├───┤ │
│ │ │ │ │ • [I]
│ │ │ │ ├─╯
│ │ │ │ │ • [J]
│ │ │ │ │ │
• │ │ │ │ │ [H]

Here is the same graph in gitgraph.nvim:

* [A]
│
│ M [B]
│ ├─╮
│ │ * [C]
│ │ │
│ │ * [D]
│ │ │
│ │ │ M [E]
│ │ │ ├─╮
│ │ │ │ │ * [F]
│ │ │ │ │ │
│ │ │ │ │ │ * [G]
│ │ │ │ │ │ │
│ │ │ M │ │ │ [H]
│ │ │ ├─│─│─│─╮
│ │ │ │ │ │ │ │ * [I]
│ │ │ │ │ │ │ │ │
│ │ │ │ │ │ │ │ │ * [J]
├─┴─╯ │ │ │ │ │ │ │
M     │ │ │ │ │ │ │ [H]

Case 1:

[B] is a merge of [C] and [H]. Flog shows the [B] branch connected to [H] right after the commit, but gitgraph.nvim doesn't show it until later.

Case 2:

[I] is a new branch that forks out of a commit to the left. Flog shows this fork right away, whereas gitgraph.nvim defers it until later.

Flog's approach is more compact, however all the information is there to understand what is happening, and if g:flog_enable_extended_branch_chars is on it's much more clear. It also can make it hard to track what commit it will eventually be connected to at the end of the branch - however gitgraph.nvim just has the same problem, but in reverse.

The gitgraph.nvim approach has a few downsides by my estimation:

• Unnecessary vertical branches in the output. In both cases here, there are at least 2 vertical branches for the same commit in the output all the way down until it reaches the commit, taking up more horizontal space. It is unclear that these branches will eventually be connected.
• Difficulty tracking which commit a fork will be attached to - the same problem Flog has but in reverse.

Overall, I believe Flog has a clearer representation of reality. The first case is very common and I believe Flog tells the story of what happened:

• The user forked a branch off of H.
• The user made some changes to the new branch.
• The user merged H with the forked branch again.

The gitgraph.nvim representation, however, looks like the user may have made two forks at the same time, but they did not. It is unclear when reading from the top that the leftmost branch (H) is involved at all.

The second case is clear in Flog as well:

• The user forked a new branch.

Part of the lack of clarity comes from the extra vertical branch in the output. If it's connected to other commits, this can create a confusing picture of what realistically happened, like in the first case. If it's not connected to other commits, it can create fake branches that linger in the output for no reason.

The rest of the lack of clarity comes from deferring showing connections until later in the graph.

I believe in the crusade of gitgraph.nvim for better terminal-based graph drawing, but as of now I believe there are just tradeoffs for both. There may be cases I'm missing where the gitgraph.nvim methodology is better, but from what I can find it strictly has more downsides.

Other differences in graph drawing logic are hard to determine because this one alone makes the graphs so different.

[rbong]

I've dug into all the differences I could and updated the FAQ in v3. Please feel free to comment here or start a new issue if you have anything to add.