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?
It's a good question, I was just working on a blog post - both because worktrees are very cool and also because I think we have a nice alternative to a similar issue.
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.
> 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.
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.
Reminded me of a product called Rational ClearCase:
> 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
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.
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|2 years ago
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.
avgcorrection|2 years ago
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.
Tempest1981|2 years ago
> 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
https://en.m.wikipedia.org/wiki/Rational_ClearCase
frizlab|2 years ago
adrianmonk|2 years ago
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|2 years ago
I wouldn't use gitbutler for what I use worktrees, and I wouldn't use worktrees for what I think gitbutler is aiming at.