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: \'
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.
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.
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.
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>
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.
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 commandThis command allows to relocate linked worktrees.
Main worktree cannot (yet) be moved.
And:
worktree move
: refuse to move worktrees with submodulesSubmodules contains
.git
files with relative paths.
After aworktree 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, thisvalidate_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.