Hi @dlyongemallo, I very much appreciate your work on the diffview.nvim plugin!
I'm looking for a way to utilize the making feature in your fork for streamlining merge request reviews in gitlab.nvim. There is currently one main point that increases the friction: The marks are linked to a file and revision. However, it frequently happens that a MR needs to be rebased onto the target branch---as a consequence, all the marks are removed, because rebasing changes the "base SHA" of the MR, even if the rebase doesn't really affect the MR content and "viewed" marks should not be removed.
Ideally, I'd like to be able to use a public diffview.nvim API for programmatically modifying the marked files. I imagine that in the gitlab.nvim plugin I could first record the marked files before rebasing, then use Gitlab's API to rebase (I've got a draft PR open for this), and then restore marks for files that don't need re-reviewing.
Another feature that is missing in diffview.nvim to make this workflow really smooth is the possibility to replace one of the references in a Diffview. For example: In gitlab.nvim a user starts a review with a current base revision, then after a rebase, it would be nice if the diffview could be updated by replacing the first part in the commit range :DiffviewOpen abc123..def456 -> :DiffviewOpen ghi123..def456. There is of course a workaround: Close the current diffview and open a new one, but if this could be done "in-place" without the screen reshuffling, it would be awesome!
Considered alternative approaches
Instead of using a particular SHA as the MR base, I could use the branch name as the reference, then this would not be affected by the rebase. However, this is not optimal because then the Diffview can show a lot of noise when the source/feature branch is not rebased onto the base branch.
Hi @dlyongemallo, I very much appreciate your work on the diffview.nvim plugin!
I'm looking for a way to utilize the making feature in your fork for streamlining merge request reviews in gitlab.nvim. There is currently one main point that increases the friction: The marks are linked to a file and revision. However, it frequently happens that a MR needs to be rebased onto the target branch---as a consequence, all the marks are removed, because rebasing changes the "base SHA" of the MR, even if the rebase doesn't really affect the MR content and "viewed" marks should not be removed.
Ideally, I'd like to be able to use a public diffview.nvim API for programmatically modifying the marked files. I imagine that in the
gitlab.nvimplugin I could first record the marked files before rebasing, then use Gitlab's API to rebase (I've got a draft PR open for this), and then restore marks for files that don't need re-reviewing.Another feature that is missing in diffview.nvim to make this workflow really smooth is the possibility to replace one of the references in a Diffview. For example: In gitlab.nvim a user starts a review with a current base revision, then after a rebase, it would be nice if the diffview could be updated by replacing the first part in the commit range
:DiffviewOpen abc123..def456->:DiffviewOpen ghi123..def456. There is of course a workaround: Close the current diffview and open a new one, but if this could be done "in-place" without the screen reshuffling, it would be awesome!Considered alternative approaches
Instead of using a particular SHA as the MR base, I could use the branch name as the reference, then this would not be affected by the rebase. However, this is not optimal because then the Diffview can show a lot of noise when the source/feature branch is not rebased onto the base branch.