After watching your (very enjoyable) talk in the other thread, schacon, one thing struck me - there _is_ a way to work on multiple branches at the same time: worktrees.
What's the advantage of a tool like this over that?
What's the advantage of a tool like this over that?
With worktrees you can have different branches in different working directories and work on them at the same time. But practically, there is very little difference to just cloning the repo twice and working on different branches in the two checkouts.
The way we're doing it, the branches are both in the same working directory at the same time.
This can have a couple of advantages - one is if you have an annoying bugfix and you need it in order to keep working on your feature, you can have them both applied but you don't have to commit one into the history of the other. You cannot do this with worktrees.
Another is trying out multiple branches together. If they don't conflict, you can essentially get the result of a multi-way merge without creating any merge artifacts. Say you merge three work in progress branches to test them together, then keep working on each independently. Also, in this case, you _know_ that you can merge them in any order and the result will work because you've actually worked on the merged tree.
> It uses the MultiVersion File System (MVFS) which is a virtual file system that displays specific versions of data stored. In particular, it supports dynamic views which can show an arbitrary combination of local and remote files
It's a good feature especially with big monorepos where it is helpful to pick and choose a known good version of specific module or subset of files without polluting the history.
Tracking good versions of every single file with huge number of files changing was a pain though.
It's effectively a way to take changes you're making and pretend like you did them in worktrees without having to switch back and forth.
Or maybe, to work on several branches, achieve the merged state you want, then split the work up into reviewable branches that can be merged in any order to achieve that final state.
So, in the context of worktrees I read _"The way we're doing it, the branches are both in the same working directory at the same time"_ as having both the branch's files (not changes) available in the same worktree.
Thanks for clarifying that it is similar to changelists.
With clones you have to fetch everything N times. You have to gc everything N times. You have to do `git config --local` N times if the config matters/affects all clones. If you need a local branch in two clones you need to synch. between them. The repository needs to be managed, which means that every clone needs to be managed. With a worktree there is nothing extra to manage.
And when you’re done you remove it via the subcommand and it’s gone.
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.
I wouldn't use gitbutler for what I use worktrees, and I wouldn't use worktrees for what I think gitbutler is aiming at.