Draft: feat: implement rebasing#534
Draft: feat: implement rebasing#534jakubbortlik wants to merge 11 commits intoharrisoncramer:developfrom
Conversation
| end | ||
|
|
||
| vim.api.nvim_command(string.format("%s %s..%s", diffview_open_command, diff_refs.base_sha, diff_refs.head_sha)) | ||
| local full_command = string.format("%s %s..%s", diffview_open_command, remote_target_branch, state.INFO.source_branch) |
There was a problem hiding this comment.
By using branch names to open the Diffview the view automatically updates after fetching the remote target branch and pulling the source branch which has been rebased on the server.
I still need to find out if this doesn't break anything or if the diff_refs should not be replaced in other parts of the codebase as well.
There was a problem hiding this comment.
After some testing, I think it will be more appropriate if the base SHA is taken from the diff_refs (vim.api.nvim_command(string.format("%s %s..%s", diffview_open_command, diff_refs.base_sha, state.INFO.source_branch)), as it was originally otherwise the diffview shows too many "changed" files when the MR needs to be rebased.
jakubbortlik
force-pushed
the
feat/implement-rebasing
branch
from
27e544a to
6fc6475
Compare
jakubbortlik
force-pushed
the
feat/implement-rebasing
branch
from
6fc6475 to
3384ee1
Compare
jakubbortlik
force-pushed
the
feat/implement-rebasing
branch
from
3384ee1 to
d528de8
Compare
jakubbortlik
changed the title
jakubbortlik
changed the title
jakubbortlik
force-pushed
the
feat/implement-rebasing
branch
from
dff2d2a to
49d2495
Compare
| create_mr = "glC", -- Create a new MR for currently checked-out feature branch | ||
| choose_merge_request = "glc", -- Chose MR for review (if necessary check out the feature branch) | ||
| start_review = "glS", -- Start review for the currently checked-out branch | ||
| reload_review = "gl<C-R>", -- Load new MR state from Gitlab and apply new diff refs to the diff view |
There was a problem hiding this comment.
I'm wondering whether it would make sense to connect this to the refresh of the discussion tree instead of making it a separate function and keybinding.
| gitlab.close_review() ~ | ||
|
|
||
| Closes the reviewer tab and discussion tree and cleans up (e.g., removes | ||
| winbar timer). | ||
| >lua | ||
| require("gitlab").close_review() | ||
| < |
There was a problem hiding this comment.
This is an existing API that was just missing documentation.
| M.is_open = true | ||
| local cur_view = diffview_lib.get_current_view() | ||
| M.diffview_layout = cur_view.cur_layout | ||
| M.diffview = require("diffview.lib").get_current_view() |
There was a problem hiding this comment.
Saving this to the module table makes it possible to reduce the reliance on the diffview.lib in other places of the codebase.
| if M.tabnr ~= nil and vim.api.nvim_tabpage_is_valid(M.tabnr) then | ||
| vim.cmd.tabclose(vim.api.nvim_tabpage_get_number(M.tabnr)) | ||
| end |
There was a problem hiding this comment.
This approach makes sure we close the tab created by gitlab.nvim when the reviewer.close() function is called in a different diffview.
The `vim.api.nvim_get_current_tabpage()` function returns a tab ID, not a tab number, as exemplified by the usage: `vim.cmd.tabclose(vim.api.nvim_tabpage_get_number(M.tabid))`
1 participant
Closes #497.
This is still in draft because I would like to test it thoroughly, but the main functionality works. The maintained Diffview fork supports updating a diffview, and programmatically modifying selections which enables us to update the reviewer in place without closing and reopening after a rebase.
There will be a trivial conflict with #530 because both PR's add keybindings in the same place in settings.
AI use: The Go code is mostly generated by Claude Opus 4.5. The same model has been used for reviewing the lua code.