They're useful, but the fact that you have to grant them a space somewhere on your computer does handicap them a bit. I typically reach for them when I'm doing library upgrades, which take a while, and having my repo switch back and forth to different versions is cumbersome, mostly due to things like dependencies and other unversioned files needing to be changed to support the application and it's specific set of dependencies.
For most other things, where unversioned files don't cause grief like this, a tool like jujutsu, which eliminates the whole stash dance, is generally better
I usually just clone the same repository multiple times for each branch I'm working on simultaneously, but obviously that's cumbersome if it's very large so worktrees are a good option there
This works even if you made uncommitted changes in your first clone. These uncommitted changes aren't copied. You can also check out an origin branch to not work with locally commited changes.
You can use git remote to set the new origin to upstream.
> That’s why the repo must have at least a main working tree
It doesn't, e.g. bare repositories don't have a worktree. This is useful for e.g. backing up a git repo to any SSH host by cloning a bare repository there and then adding it as an upstream of your local repo.
I like the idea of them…was just reading about them yesterday but the folder to a repo concept was a little and I didn’t realize exactly what was going on so this blog is perfect timing. I regularly need to switch branches and don’t really like the stash checkout flow that I have —- too much cognitive lift for me. Maybe work trees is the answer
They're useful, but the fact that you have to grant them a space somewhere on your computer does handicap them a bit. I typically reach for them when I'm doing library upgrades, which take a while, and having my repo switch back and forth to different versions is cumbersome, mostly due to things like dependencies and other unversioned files needing to be changed to support the application and it's specific set of dependencies.
For most other things, where unversioned files don't cause grief like this, a tool like jujutsu, which eliminates the whole stash dance, is generally better
I usually just clone the same repository multiple times for each branch I'm working on simultaneously, but obviously that's cumbersome if it's very large so worktrees are a good option there
You can do clone from an existing clone:
$ git clone git@whatever.com/...
Cloning into example
$ git clone example example-2
This works even if you made uncommitted changes in your first clone. These uncommitted changes aren't copied. You can also check out an origin branch to not work with locally commited changes.
You can use git remote to set the new origin to upstream.
Or, you could use worktrees. That's fine too.
Just don't use them with submodules or you're in for pain (even more pain than just using submodules in the first place).
> That’s why the repo must have at least a main working tree
It doesn't, e.g. bare repositories don't have a worktree. This is useful for e.g. backing up a git repo to any SSH host by cloning a bare repository there and then adding it as an upstream of your local repo.
I like the idea of them…was just reading about them yesterday but the folder to a repo concept was a little and I didn’t realize exactly what was going on so this blog is perfect timing. I regularly need to switch branches and don’t really like the stash checkout flow that I have —- too much cognitive lift for me. Maybe work trees is the answer
Secrets mean it is not stable yet ?