'' is already checked out at '' in git worktrees

后端 未结 6 764
被撕碎了的回忆
被撕碎了的回忆 2020-12-14 15:31

I started using git worktrees. It seems to work, but I\'m getting this error when attempting to check out a branch in the cloned worktree:

fatal: \'

        
相关标签:
6条回答
  • 2020-12-14 16:01

    If you really want you can bypass this check, either by directly modifying the ref in the respective HEAD file, or by recreating the branch with the same name with e.g. git checkout -B master origin/master

    As others have said, you need to know what you're doing though; branches are common to all worktrees, changing one in one worktree will immediately affect the status of your other worktree.

    0 讨论(0)
  • 2020-12-14 16:06

    Note that this also happens if your $pwd has links in it. git should probably readlink -f on the $pwd prior to checking.

    Edit: Or this may indeed be because I missed to call git worktree prune. Now it's working.

    0 讨论(0)
  • 2020-12-14 16:13

    Simply go to the worktree directory of your desired branch, and it automatically checkout for you.

    In my case, I have two long-running worktree that means two relevant branches beside the master.

    $git branch
    master  # base stuff here
    version-silver # some normal features
    version-gold # some better features
    

    There is one repository, but I have 3 separate folders beside each other for each branch above. And make the common changes in master. then merge it with both other versions.

    Specific changes of each version will go in the corresponding folder as well, and the works on each project are isolated and IDE wouldn't be confused.

    Hope that helps.

    0 讨论(0)
  • 2020-12-14 16:17

    Since you cannot checkout twice in both worktree and the original repository. How about checkout original repo to somewhere else before you checkout the worktree?

    git -C </other/location> checkout <branch>~1
    git -C <worktree> checkout <branch>
    
    0 讨论(0)
  • 2020-12-14 16:20

    Git won't let you check out the same branch twice, because if you do, and then go to one of the two work-trees and make a new commit, you'll set yourself up for misery when you go back to the other work-tree.

    If you have actually removed the other work-tree, simply run git worktree prune to make Git realize this. If you have not actually removed the other work-tree, don't check it out twice: it's no fun.

    0 讨论(0)
  • 2020-12-14 16:22

    How do I get around this without deleting the .git/worktrees directory?

    You will have an easier time with Git 2.17+ (Q2 2018), since "git worktree" has learned 'move' and 'remove' subcommands.

    See commit 7f19def (04 Mar 2018) by Eric Sunshine (sunshineco).
    See commit ee6763a, commit cc73385, commit 78d986b, commit c64a8d2, commit 9f792bb, commit 9c620fc (12 Feb 2018), and commit 4ffffddc1 (24 Jan 2018) by Nguyễn Thái Ngọc Duy (pclouds).
    (Merged by Junio C Hamano -- gitster -- in commit bd0f794, 14 Mar 2018)

    In your case, you could move the existing worktree to the place you now wants it (when attempting to create a new worktree for the same branch).

    worktree move: new command

    This command allows to relocate linked worktrees.
    Main worktree cannot (yet) be moved.

    And:

    worktree move: refuse to move worktrees with submodules

    Submodules contains .git files with relative paths.
    After a worktree move, these files need to be updated or they may point to nowhere.

    This is a bandage patch to make sure "worktree move" don't break people's worktrees by accident.
    When .git file update code is in place, this validate_no_submodules() could be removed.


    Note: before Git 2.21 (Q1 2019), "git worktree remove" and "git worktree move" refused to work when there is a submodule involved.
    This has been loosened to ignore uninitialized submodules.

    0 讨论(0)
提交回复
热议问题