Skip to content

Checking out non-local branches in telescope picker #30

@tvsfx

Description

@tvsfx

It's currently hard to use the telescope worktree creation functionality, because it only works well for branches that have been checked out locally as well. There are a few issues when trying to create a worktree from a tracking branch:

  1. The Git.has_branch logic will not find the branch (the git branch list does not contain remote tracking branches) and hence a new branch will incorrectly be created here.
    Fix: check for remote tracking branches as well
  2. The following issue in git-worktree v1 still applies when one tries to create a git worktree from a remote-tracking branch: Additional origin added for Head and Merge ThePrimeagen/git-worktree.nvim#77. To summarize, for the new branch the <remote>/ prefix is kept in the local branch name as well, which results in a rather confusing user experience (e.g. in git log, there's now two references called <origin>/<branch>).
    Potential fix (related PR: [RFC] Set --track when creating a worktree #20.): git checkout and git worktree add have the same semantics, where if the starting branch is a tracking branch that does not exist locally and is present in a single remote, then a local checkout is created. Therefore, the Telescope git_branches command has faced a similar concern already, where remote branches are shown but usually what the user wants is to checkout a new, local branch (relevant issue: git_branch checkout a non-local remote branch nvim-telescope/telescope.nvim#1932). They have solved this by binding the function git_track_branch (https://github.com/nvim-telescope/telescope.nvim/blob/5972437de807c3bc101565175da66a1aa4f8707a/lua/telescope/actions/init.lua#L748-L756) to <C-T>, allowing one to pass the --track option to git checkout, which provides the correct semantics. The telescope picker for git-worktree could similarly allow passing the --track option to git worktree add.
  3. [Not related to telescope] I'm also not quite sure why fetching and setting the upstream here https://github.com/polarmutex/git-worktree.nvim/blob/500629d0ad916ec362f53ecf21f84f3ba445f73e/lua/git-worktree/worktree.lua#L112C1-L117C1
    is necessary in the default case. This seems to differ from the git-worktree semantics one would expect, and seems to cause the "double origin" part of the aforementioned issue (Additional origin added for Head and Merge ThePrimeagen/git-worktree.nvim#77).

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions