Just use copy-on-write clones. They're way more flexible, faster and easier to reason about.
I don't get spending all this time on tooling that tries to ease working with worktrees when they're just not the right abstraction for the way we're working now.
> If <branch> does exist, it will be checked out in the new worktree, if it’s not checked out anywhere else, otherwise the command will refuse to create the worktree (unless --force is used).
Worktrees are significantly faster to use and checkout than clones. They also use much less disk space, and obviously commits made in one worktree do not require git plumbing to get them visible in another etc.
I don't understand why worktrees either, but to each their own.
For my purposes, the alternative with just switching branches or if parallelism is needed, full repos and remotes (including local path remotes) is just much more flexible. Clone local, branch it, optionally do anything later: push a branch back to the local repo, push it to a remote, delete local repo done.
The actual code and clean merges is much more significant than worktrees vs full clones
As the author, I have been using worktrees due to AI agents. And I love Magit but didn’t know it handles git worktrees so well! Thanks for letting me know, will start using magit to manage my worktrees immediately.
To be honest, AI or not, I just don't like to be in the situation where I need multiple checkouts of the same repository. I do it sometimes anyways, but it's not because I'd like to work like that, rather, because something (bad) happened and it needs fixing, and having an extra checkout would help fixing it.
Some things that the post indicates as the problems solved by worktrees to me feel like the (quite common) problems of development environment setup. For example, OP uses worktrees to prevent different tools from competing over files in the working directory of their development environment... Well, a better way to run tests is to not run them from the development environment at all: deploy them to wherever they are supposed to run, and run them there.
Unfortunately, a lot of tools are designed to run code from "dirty" environment by default, take for instance Python developer's love for "pip install -e" or pytest running code from the source directory by default. But, for one's own sanity, these practices are better avoided. Running from the working directory of the development environment means that you, as a developer, have to remember every detail of the state left by the previous run and reassure yourself that none of those changes matter to your next run... I don't trust myself to remember that.
Worktrees are a must if you work with monorepos or just multiple branches in general. Lack of conventions (or rather the braindead defaults) and having to explicitly type out everything is what hinders adoption the most.
I've solved this by running thin bash script wrappers that keep the workflow SVN-like with a root directory that contains per-branch directories and a hidden bare repo).
I think my layout is similar to yours. What do your scripts do?
My branches end up in a tree structure (no shit!), and I rebase and merge up stream as changes land. I guess it could be more automated, but the only tedious part is remembering to remove old worktrees and prune the old branches
worktree add: `git worktree add` that creates a local new branch and a directory with the same name and sets upstream to match; alternatively checks out an existing remote branch.
worktree rm: Removes worktree directory, first checking it is in porcelain state. Then prunes them and removes local branch pointers if they match the remote ones.
These all are handwritten and probably buggy, but still less prone to errors than typing out `git worktree add -b foo-123-fix-missing-semicolon foo-123-fix-missing-semicolon origin/develop` manually every time. One pass with Claude or Codex would probably do wonders.
You could try proposing a worktree copy command on the mailing list. Worktrees are currently independent and work off of repositories which may have no existing worktree / working copy at all, let alone one it makes sense to start from, so there is bothing to copy but for dodgy heuristics.
Like many of you I also knew what git worktrees were but always found them clunky because you mentally had to manage worktrees AND branches at the same time. That's why I didn't bother using them.
A couple of weeks ago I discovered Worktrunk. That's when my whole workflow flipped 180 degrees: I now always use worktrees, love it, will never go back. Worktrunk was the missing piece for me. Very recommended.
Just use copy-on-write clones. They're way more flexible, faster and easier to reason about.
I don't get spending all this time on tooling that tries to ease working with worktrees when they're just not the right abstraction for the way we're working now.
A slight limitation of worktrees is that you can only have a branch checked out once in all of your worktrees. I guess that's just how git works.
But when I want to checkout a branch that's already checked out in another worktree, Magit just plain refuses. I wish it would offer me to either:
1. Switch to that worktree instead
2. Detach head in the other worktree and checkout here
Would be such an improvement! No excuses though, I love magit and might as well hack this myself. I'm just bad at elisp.
> I guess that's just how git works.
You can use `--force`:
> If <branch> does exist, it will be checked out in the new worktree, if it’s not checked out anywhere else, otherwise the command will refuse to create the worktree (unless --force is used).
Sorry git worktrees are a waste of time Just keep multiple copies of the repo
Worktrees are significantly faster to use and checkout than clones. They also use much less disk space, and obviously commits made in one worktree do not require git plumbing to get them visible in another etc.
I don't understand why worktrees either, but to each their own.
For my purposes, the alternative with just switching branches or if parallelism is needed, full repos and remotes (including local path remotes) is just much more flexible. Clone local, branch it, optionally do anything later: push a branch back to the local repo, push it to a remote, delete local repo done.
The actual code and clean merges is much more significant than worktrees vs full clones
As the author, I have been using worktrees due to AI agents. And I love Magit but didn’t know it handles git worktrees so well! Thanks for letting me know, will start using magit to manage my worktrees immediately.
To be honest, AI or not, I just don't like to be in the situation where I need multiple checkouts of the same repository. I do it sometimes anyways, but it's not because I'd like to work like that, rather, because something (bad) happened and it needs fixing, and having an extra checkout would help fixing it.
Some things that the post indicates as the problems solved by worktrees to me feel like the (quite common) problems of development environment setup. For example, OP uses worktrees to prevent different tools from competing over files in the working directory of their development environment... Well, a better way to run tests is to not run them from the development environment at all: deploy them to wherever they are supposed to run, and run them there.
Unfortunately, a lot of tools are designed to run code from "dirty" environment by default, take for instance Python developer's love for "pip install -e" or pytest running code from the source directory by default. But, for one's own sanity, these practices are better avoided. Running from the working directory of the development environment means that you, as a developer, have to remember every detail of the state left by the previous run and reassure yourself that none of those changes matter to your next run... I don't trust myself to remember that.
Great name
Worktrees are a must if you work with monorepos or just multiple branches in general. Lack of conventions (or rather the braindead defaults) and having to explicitly type out everything is what hinders adoption the most.
I've solved this by running thin bash script wrappers that keep the workflow SVN-like with a root directory that contains per-branch directories and a hidden bare repo).
I think my layout is similar to yours. What do your scripts do?
My branches end up in a tree structure (no shit!), and I rebase and merge up stream as changes land. I guess it could be more automated, but the only tedious part is remembering to remove old worktrees and prune the old branches
worktree clone: Basically git clone that initializes a worktree root according to this guide: https://dev.to/metal3d/git-worktree-like-a-boss-2j1b
worktree add: `git worktree add` that creates a local new branch and a directory with the same name and sets upstream to match; alternatively checks out an existing remote branch.
worktree rm: Removes worktree directory, first checking it is in porcelain state. Then prunes them and removes local branch pointers if they match the remote ones.
These all are handwritten and probably buggy, but still less prone to errors than typing out `git worktree add -b foo-123-fix-missing-semicolon foo-123-fix-missing-semicolon origin/develop` manually every time. One pass with Claude or Codex would probably do wonders.
There are many uses for worktrees for people who are more than meat proxies:
https://stackoverflow.com/questions/31935776/what-would-i-us...
I'm currently very much on the jujutsu train as the author also mentioned, i do recommend y'all give it a try
One thing I've desperately wanted from git worktrees is to use reflinking in some way to lower the cost of copies.
I just found https://github.com/josharian/git-cow-worktree that doesn't inspire confidence.
You could try proposing a worktree copy command on the mailing list. Worktrees are currently independent and work off of repositories which may have no existing worktree / working copy at all, let alone one it makes sense to start from, so there is bothing to copy but for dodgy heuristics.
Like many of you I also knew what git worktrees were but always found them clunky because you mentally had to manage worktrees AND branches at the same time. That's why I didn't bother using them.
A couple of weeks ago I discovered Worktrunk. That's when my whole workflow flipped 180 degrees: I now always use worktrees, love it, will never go back. Worktrunk was the missing piece for me. Very recommended.