[adrianmonk]

Don't worktrees require more work to actually run your code because of multiple working directories?

If you're using an IDE, you'll probably need to create a project for each working directory. Or maybe you can change the path within the IDE's project.

If you're running a local web server, it will need to be configured for each working directory, again either multiple instances or one where you keep updating the path.

For compiled languages, the builds will take longer. When you create a new worktree, you may have to do a full build. Even if you have incremental builds, as you pull in upstream changes, you'll have to do N incremental builds instead of 1 incremental build.

It's not the end of the world, but it's a bit of hassle and extra computation that isn't needed with just one working copy.

[reyqn]

Maybe I don't understand how gitbutler works, but the main reason I use worktrees is actually to keep my IDE and incremental builds getting confused when I switch branches, on branches that have lots of differences. It works really well, and I can fix stuff on old versions of our app in a jiffy.

I wouldn't use gitbutler for what I use worktrees, and I wouldn't use worktrees for what I think gitbutler is aiming at.

[schacon]

Since we write out our virtual branch artifacts into refs/gitbutler/X, you could actually pretty easily setup worktrees from each of them to do this type of work on. Perhaps setup a post-commit hook to update any active worktrees automatically too. Might be an interesting way to effectively work on several worktrees from a single working directory.

[reyqn]

That's interesting. I'll try this out when windows support ships and keep an eye on it in the meantime.

[whoopsie]

That would be brilliant and an instant subscribe from a long time tower user