[Request] :DiffviewGraph

[3dyuval]

First of all I really appreciate the effort everyone has put into this.
I was so relieved all bugs finally went away. So I was thinking - why not introduce new once? (😂)

Here's my idea. Neogit has a nice surface-level integration with Diffview, and seeing them together just hits my sweet spot. So much so I started wondering how to get them play nicely. I landed on: Neogit's graph view + Diffview's layouts = 🔥

For example, here are two Neovims side by side. On the left is Diffview's DiffviewFileHistory; on the right is :Neogit log (Kitty terminal).

Considerations

I think this belongs in diffview-plus itself rather than tying the two plugins closer together. Diffview's state is straightforward, and most of the selection logic already exists in the file-history view.

• cmd name? :DiffviewLog was my first choice but seeing it already exists. (debug log) we either add new command or a flag on it. Something like :DiffviewLogPretty is really a mouthful, no sure about it. For now lets leave it at :DiffviewGraph
• Where the panel lives?
  The graph itself pinned either to the left, bottom (and or right, right?).
  Diffview already supports placing panels in any of those.
• Selecting multiple commits: I'd want to select a range and have them highlight together; most of that already exists in the file-history panel.
• No hard dependency on Neogit: the graph drawing would be included in diffview-plus directly, so users wouldn't need Neogit installed.

Architecture

1. Saving/restoring the view across sessions - right now a "graph" view can't be stored, as its own type. So we need to add it as one.
2. How the commit list maps to diffs - Diffview is built around "the files a commit changed" whereas a graph is about how commits connect. So the graph display would need to sit on top of Diffview's existing model rather than replace it.

What do you think? Love to hear your thoughts.

[dlyongemallo]

Have you considered gitgraph.nvim? It also has diffview integration and multiple commit selection, without the heavy dependency of neogit.

I don't know if it's possible to save/restore the graph across sessions, but it should be possible to regenerate it using an autocmd on SessionLoadPost.

Implementing a "commit graph" feature is a serious endeavour for a problem which has already been solved in the Neovim ecosystem. I don't see the need to maintain yet another implementation.

[3dyuval]

Nice. I didn't knew it existed.
So there is a clean seperation. The dependency is reversed though in my mind. Diffview already does all heavy lifting with views, windows, querying, state... Gitgraph is a view.

Diffview could use it to render a stateful Graph panel. Users could opt-in with deps = "isakbm/gitgraph.nvim"

[dlyongemallo]

That is still a huge maintenance burden. gitgraph.nvim has no releases or public API, which means that the change you're suggesting effectively ties the maintenance of diffview+ to an external repo's internal API. The project's own README says NOTE: this project is still very WIP and there is no help documentation aside from this README.md. To have the degree of integration that you want, gitgraph.nvim should at least have a public API contract which is promised to be stable.

Furthermore, doing what you ask will introduce a feature which is git-only, regressing the degree of feature-parity for multi-VCS support.

I also don't see why this plugin should tie itself to one way of integrating commit graphs with neovim, when there are others (like Neogit, or vim-flog).

What are you trying to do that you can't already do with scripting using diffview+'s public API, which integrating so closely with a commit graph plugin would buy you?

[3dyuval]

Yes I agree, its a shot in the dark. Its a huge endevour.

I'm trying to push the limits of both plugins by writing a RECIPE-GitGraph.nvim.md. I'm curious how far a userspace config can go, some gaps are:

gitgraph.nvim doesn't has a stable public core api. Its exposing a draw, Nothing for working with items via callbacks. (Ideally, something like a snacks api.)

diffview-plus.nvim doesn't expose view_opened and file_open_post hooks. Ideally for having q forquit, <CR> for prev and next by emitting so global keymaps_context (per this naive recipe)

I will try to explore CDDiffView after discovering it now.

What I'm going after is replicating the experience I had with Webstorm. The VCS panel over there is unparallel to anything I've seen.

With diffview split system, I can jump between changes, conflicts, files, and its smooth again thanks to your hard work.

But given I'm a frontend dev that likes changing stuff just to see where they break, I figured, if I could hook into a some window I could replicate the Webstorm experience. This included things like filtering by author, by repo, by hash, and the graph changes instantly, everything is very clear and intuitive.