18 ms·

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 wa

by miggol 6d ago

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.

svlasov 6d ago
> 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).
- dzaima 6d ago
  Or "--ignore-other-worktrees" for "git switch". This leaves things in a weird state though, as modifying the branch from one of the worktrees will effectively change the ref the other is pointing to, but won't update the other's working tree, making it look like it's preparing to revert all the changes that the first worktree made. (obligatory mention of jj, whose workspaces track what state they were snapshotted at, thus never losing what the true diff of a workspace should be, allowing a "jj workspace update-stale" to safely update the working copy with whatever the other workspaces changed (if you change the working copy and in parallel from another workspace change what that workspace points to, you'll get a saved commit of the working copy changes before being updated, which you'll need to squash/rebase wherever those changes were needed))
LeBit 6d ago
I wonder what use case there would be to checkout the same branch in multiple worktrees. Or you aren’t saying this is a wanted feature, simply that magit should switch to the worktree (like lazitgit behavior)?
- rgoulter 6d ago
  > I wonder what use case there would be to checkout the same branch in multiple worktrees. I've run into it when I've wanted to checkout that branch (to try running code there, or view a file, or rebase it, or whatever) and there's already a worktree checked out. This is more like treating worktrees as "lightweight clone of the repo checkout out at some dir". (If it were a separate clone, it wouldn't be an issue to have the same branch checked out in two places).

by miggol 6d ago

svlasov 6d ago

> 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).

dzaima 6d ago
Or "--ignore-other-worktrees" for "git switch". This leaves things in a weird state though, as modifying the branch from one of the worktrees will effectively change the ref the other is pointing to, but won't update the other's working tree, making it look like it's preparing to revert all the changes that the first worktree made. (obligatory mention of jj, whose workspaces track what state they were snapshotted at, thus never losing what the true diff of a workspace should be, allowing a "jj workspace update-stale" to safely update the working copy with whatever the other workspaces changed (if you change the working copy and in parallel from another workspace change what that workspace points to, you'll get a saved commit of the working copy changes before being updated, which you'll need to squash/rebase wherever those changes were needed))

LeBit 6d ago

I wonder what use case there would be to checkout the same branch in multiple worktrees. Or you aren’t saying this is a wanted feature, simply that magit should switch to the worktree (like lazitgit behavior)?

rgoulter 6d ago
> I wonder what use case there would be to checkout the same branch in multiple worktrees. I've run into it when I've wanted to checkout that branch (to try running code there, or view a file, or rebase it, or whatever) and there's already a worktree checked out. This is more like treating worktrees as "lightweight clone of the repo checkout out at some dir". (If it were a separate clone, it wouldn't be an issue to have the same branch checked out in two places).