Add support for Worktrees (or something like it)

[dalewking]

I have read your comparison of git butler and git worktrees and disagree that they re doing the same thing.

Worktrees allows you to work on multiple things simultaneously, which I use extensively. I will have multiple workspaces at the same time and multiple projects open in my IDE and can easily switch between branches that way. I can start a long-running build in one and while that is going on go edit code in another.

Gitbutler provides a convenient way to switch what you are working on but you can only ever be working on one thing as you only have one workspace. Granted, it makes that switching very convenient, but without the ability to do things simultaneously it is a non-starter for me.

[Byron]

Thanks a lot for sharing!

What I can imagine to be a natural next step for GitButler is to support worktrees at all, i.e. to allow itself to open them, along with the ability to operate on any branch (instead of gitbutler/integration). Then one could use GitButler features in each worktree, using one instance of GItButler per worktree.

A second step could be that there is some sort of tabbed layout, allowing to show and use multiple projects (worktrees in this case) in a single application instance.

Would that make it (more) viable?

[OPeyrusse]

To add my 2 cents to the original description, a worktree allows to have multiple folders in sync. In the case of an entreprise product with multiple actively supported branches, I find it useful to have all repos synced while maintaining separate workspaces for different branches. The benefit of worktree is that it avoids the pain of recurrent git pulls. You develop the branch bugfix-v1 in one folder, push it and open a PR. Then move to the workspace for another version to create bugfix-v2 (instead of checkout, to ease the life of IDEs :smile: ) and don't need a pull for bugfix-v1 because it is already there. But more generally, when you need to have multiple dev workspaces for the same project, having all workspaces share the same underlying git repo removes the pain of walking all dirs to find where you left your incomplete unpushed branch for something.

So I see myself using gitbutler for all my devs on a single version but still use different folders for different versions. And like @dalewking , I will like have two workspaces for the same version, one for a build and test are running while playing with the other in the meantime.

[StripedMonkey]

Worktrees do solve some orthogonal problems to what gitbutler is trying to solve. Using bare repositories and worktrees from that is a workflow I'd like to see supported even if gitbutler can only handle a single worktree at a time.

[Byron]

[..] even if gitbutler can only handle a single worktree at a time.

I love that idea. Because in theory, it could be setting the GitButler/integration branch in the worktree and then work ordinarily. The user can have multiple projects at different locations, and each of these can be switched to GitButler/integration exclusively, one at a time, to be able to use GitButler on it.

The tricky part here is to assure no two worktrees point to GitButler/integration at the same time, and if GitButler was to assure that, it would have to know to which branch to set the other worktree that currently points to GitButler/integration so it can set its 'about-to-be-opened' worktree to GitButler/integration.

On the other hand, maybe there could be multiple GitButler/integration branches, one per worktree… and I think this is possible with per-worktree references, which exist naturally. Thus, each worktree can have its own integration branch. In theory, git2 should already provide sufficient support.