5 ms·

I find this very annoying. I don't know if this is the right thing or not, but my workflow for starting new work is "git checkout master; git pull; git checkou

I find this very annoying. I don't know if this is the right thing or not, but my workflow for starting new work is "git checkout master; git pull; git checkout -b new_work". This is all fun and games until you have a worktree that's sitting at master. Now you have to figure out where that is, chdir there, and update that branch from the remote. It's actually extremely annoying. Maybe there is "git update master from remote and throw away my local changes because if i committed something there that was a mistake". But probably not, sadly, because technically the "git pull" operation to pull origin/master into the local tracking branch master updates the working copy where master is checked out, and that's what worktree is trying to avoid (changing a directory you're not in). I guess "git pull; git checkout -b new_branch remotes/origin/master" is what I should write, but that's more bytes to type.

wiredfool 3y ago
git fetch origin git checkout -b new_work origin/master Git pull is essentially git fetch + merge. You don't have to update your local master branch to check out a new branch based on it.
frfl 3y ago
I get around this by having "wt-" (wt-1, wt-2, etc) branches that act as my main/master branch per work tree. As long as you set the upstream to master, it works fine, you can pull in upstream main/master changes without issue. It does mean you have these "wt-" branches, but it works well enough for me, never got in my way or caused me to stop using worktrees. My workflow is like this: For each worktree I add, checkout a new branch, wt-N, with it's upstream set to main/master. If I need to checkout some other branch in a worktree, do it, finish up, check out wt-N again, git pull to bring it up to date with upstream. Leaving idle worktrees on a "wt-" branch so I don't have the issue of "branch X is already checked out out worktree Y"
CuriousCosmic 3y ago
just a minor nit but you don't even need to do `remotes/origin/master`, just `origin/master`. Alternatively you could do `git switch -c new_work && git pull -f origin master` which will create a new branch (you could use `git checkout -b` as well but like you said, more bytes to type) and then force pull from master on origin into the current branch (which is now your new branch) replacing the history with origin/master.

wiredfool 3y ago

git fetch origin git checkout -b new_work origin/master Git pull is essentially git fetch + merge. You don't have to update your local master branch to check out a new branch based on it.

frfl 3y ago

I get around this by having "wt-" (wt-1, wt-2, etc) branches that act as my main/master branch per work tree. As long as you set the upstream to master, it works fine, you can pull in upstream main/master changes without issue. It does mean you have these "wt-" branches, but it works well enough for me, never got in my way or caused me to stop using worktrees. My workflow is like this: For each worktree I add, checkout a new branch, wt-N, with it's upstream set to main/master. If I need to checkout some other branch in a worktree, do it, finish up, check out wt-N again, git pull to bring it up to date with upstream. Leaving idle worktrees on a "wt-" branch so I don't have the issue of "branch X is already checked out out worktree Y"

CuriousCosmic 3y ago

just a minor nit but you don't even need to do `remotes/origin/master`, just `origin/master`. Alternatively you could do `git switch -c new_work && git pull -f origin master` which will create a new branch (you could use `git checkout -b` as well but like you said, more bytes to type) and then force pull from master on origin into the current branch (which is now your new branch) replacing the history with origin/master.