Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

BUG? - :bnext and :bprevious takes you to file on previous worktree #84

Open
lpanebr opened this issue Apr 15, 2022 · 1 comment · May be fixed by #93
Open

BUG? - :bnext and :bprevious takes you to file on previous worktree #84

lpanebr opened this issue Apr 15, 2022 · 1 comment · May be fixed by #93

Comments

@lpanebr
Copy link

lpanebr commented Apr 15, 2022

How to reproduce:

  1. Open project
  2. Switch to an existing worktree A
  3. Open SomeFile and move cursor 10j or make some edit and save
  4. Switch to an existing worktree B where SomeFile also exists
  5. Notice that the cursor position correctly resets
  6. Do :bn followed by :bp
  7. Notice that you're back to SomeFile on worktree A
@ecosse3
Copy link

ecosse3 commented Jun 6, 2022

I can confirm this bug.

Anyway I have my own solution for that but it's only when you are using barbar.nvim as your bufferline.

worktree.on_tree_change(function(op, metadata)
  if op == worktree.Operations.Switch then
    utils.log("Switched from " .. metadata.prev_path .. " to " .. metadata.path, "Git Worktree")
    vim.cmd ('BufferCloseAllButCurrent')
    vim.cmd ('e')
  end
end)

This will close all buffers but not current you were in and refresh it so it shows bufferline correctly. Either :BufferNext will work correctly from barbar.nvim as well as :bn will not go into buffers from previous worktree (same for BufferPrevious/bp).

@Kasama Kasama linked a pull request Jul 25, 2022 that will close this issue
Kasama added a commit to Kasama/git-worktree.nvim that referenced this issue Jul 25, 2022
Change update_current_buffer function to update all currently open buffers and de-list buffers from the previous worktree.

Buffers from files that don't exist on another worktree will only be de-listed.

Buffers unrelated to the worktree (temporary or external files) should ignored

The focused buffer file will be kept focused on the new worktree, unless if it doesn't exist, in which case it will select the last one.

In the future, it would also be possible to remember closed files that don't exist for when you switch back, that's not addressed by this PR

Also fixes ThePrimeagen#84
saulvaldelvira pushed a commit to saulvaldelvira/git-worktree.nvim that referenced this issue Jul 11, 2024
Change update_current_buffer function to update all currently open buffers and de-list buffers from the previous worktree.

Buffers from files that don't exist on another worktree will only be de-listed.

Buffers unrelated to the worktree (temporary or external files) should ignored

The focused buffer file will be kept focused on the new worktree, unless if it doesn't exist, in which case it will select the last one.

In the future, it would also be possible to remember closed files that don't exist for when you switch back, that's not addressed by this PR

Also fixes ThePrimeagen#84
saulvaldelvira pushed a commit to saulvaldelvira/git-worktree.nvim that referenced this issue Jul 12, 2024
Change update_current_buffer function to update all currently open buffers and de-list buffers from the previous worktree.

Buffers from files that don't exist on another worktree will only be de-listed.

Buffers unrelated to the worktree (temporary or external files) should ignored

The focused buffer file will be kept focused on the new worktree, unless if it doesn't exist, in which case it will select the last one.

In the future, it would also be possible to remember closed files that don't exist for when you switch back, that's not addressed by this PR

Also fixes ThePrimeagen#84
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 a pull request may close this issue.

2 participants