That’s not really how one would use worktrees in git. Worktrees are useful in the case when e.g. you are working on version 0.15 of your software that has many breaking changes to version 0.14 (perhaps even on a build system level) and you need to release a 0.14.1 patch. Worktrees separate directories which means you don’t need to stash or do a wip commit, nor clear you 0.15 build artefacts. Just cd to a different worktree, checkout the 0.14 branch, create and checkout the 0.14.1 branch, clear build artifacts in a different directory from your main development one, and start working.
When done, just cd back and keep working again without switching branches, clearing artifacts, or doing full rebuilds of the in-development 0.15 version.
Plus, git does not store change sets or branches or anything on any remote unless you push them either, so if you’re having that problem just stop pushing things you don’t want to push. You can totally rsync a git repo, just ensure it’s at rest. Otherwise do what you should be doing anyway: set the repo on another machine as a remote of the other repo, so you can git pull my_private_machine feature/my_private_branch without needing to push to a central repo.
I’m sure jujutsu has many advantages, but it also reads to me like you’re misunderstanding the git model. Which can be a fair critique of git to be fair, but then we would need to talk about what about the git model people have trouble with, why, and how to address those issues, and so far I haven’t seen any kind of research in that direction from jujutsu (not that I’ve been looking particularly hard)
That’s not really how one would use worktrees in git. Worktrees are useful in the case when e.g. you are working on version 0.15 of your software that has many breaking changes to version 0.14 (perhaps even on a build system level) and you need to release a 0.14.1 patch. Worktrees separate directories which means you don’t need to stash or do a wip commit, nor clear you 0.15 build artefacts. Just cd to a different worktree, checkout the 0.14 branch, create and checkout the 0.14.1 branch, clear build artifacts in a different directory from your main development one, and start working.
When done, just cd back and keep working again without switching branches, clearing artifacts, or doing full rebuilds of the in-development 0.15 version.
Plus, git does not store change sets or branches or anything on any remote unless you push them either, so if you’re having that problem just stop pushing things you don’t want to push. You can totally rsync a git repo, just ensure it’s at rest. Otherwise do what you should be doing anyway: set the repo on another machine as a remote of the other repo, so you can
git pull my_private_machine feature/my_private_branchwithout needing to push to a central repo.I’m sure jujutsu has many advantages, but it also reads to me like you’re misunderstanding the git model. Which can be a fair critique of git to be fair, but then we would need to talk about what about the git model people have trouble with, why, and how to address those issues, and so far I haven’t seen any kind of research in that direction from jujutsu (not that I’ve been looking particularly hard)