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.

[torarnv]

My non-GitButler setup looks like this:

❯ git worktree list
/Users/torarne/dev/qt/.git/modules/qtbase    (bare)
/Users/torarne/dev/qt/5.15/qtbase            2b7d6eb6ea2 [5.15]
/Users/torarne/dev/qt/6.2/qtbase             37f05cbebe2 [6.2]
/Users/torarne/dev/qt/6.5/qtbase             fb77e8569be [6.5]
/Users/torarne/dev/qt/6.6/qtbase             a6cb5512c66 [6.6]
/Users/torarne/dev/qt/6.7/qtbase             8d811bb882e [6.7]
/Users/torarne/dev/qt/6.8/qtbase             ae6b6bf363d [6.8]
/Users/torarne/dev/qt/qtbase                 957131c2738 [dev]

And GitButler does not allow me to add the repo in /Users/torarne/dev/qt/qtbase, because it's not the "main worktree", nor does it allow me to add /Users/torarne/dev/qt/.git/modules/qtbase (which I assume is the main worktree) because it's bare.

I normally work out of the /Users/torarne/dev/qt/qtbase worktreee, and treat it as my main worktree. Would be nice if GitButler supported this workflow.

[Byron]

Thanks for sharing!

Even though this might not be possible with the next major release just yet, it's something that is definitely in the pipeline. Bare repositories will be out of range though as a worktree is truly required, but it shouldn't have any special requirements anymore in the branch that is checked out.

[torarnv]

Any update on this? :) I wanted to use GB in my work on qtbase and hit this issue again.

[Byron]

It has been a while!

With single-branch mode in testing (but not ready for prime-time), we could also consider lifting some restrictions. It should then be possible to open any repository as long as it has a worktree (i.e. non-bare). Even though in this case, we might still want to prevent workspace workspace creation outside of the main worktree.

[iamhenry]

@Byron could you expand on what you mean by "single branch" mode?

After using gitbutler for several months now I def agree that at gb needs worktrees.

This entire time I always thought I could work on the same file and gb would handle it by creating a new virtual branch. That's not the case. If you do then you need to unapply that branch. Worktrees natively within gb would enable this incredible workflow.

[Byron]

@Byron could you expand on what you mean by "single branch" mode?

GitButler won't need a workspace branch anymore, but will just show whichever branch you have checked out, along with the usual mutations.

This entire time I always thought I could work on the same file and gb would handle it by creating a new virtual branch. That's not the case. If you do then you need to unapply that branch. Worktrees natively within gb would enable this incredible workflow.

I admit to not understand just yet how GitButler could help with Git worktrees, or amplify them to something they haven't been before. Something I could imagine is some sort of unified worktree view, in a separate pane, that shows where all the worktrees are compared to a shared base maybe. These could also be brought into a workspace, as long as that workspace is in the main (Git) worktree, more or less.

[OPeyrusse]

@Byron I don't see either how Gitbutler could offer some management for worktrees. I cannot think of any sort of features, as IMO, the main point of worktree is to share a single repository and sort of "symlink" multiple repos to the same source. This way, you don't have to pull multiple times the same remote repository. You can also see all the branches you are working on in all your different copies of the same repository - which would otherwise require some push/fetch/checkout/pull combos. I would say that the only thing that matter from Gitbutler is to accept that worktrees exist and that they are represent by .git behind a file pointing to the actual .git directory. And given what you are saying that you don't need any workspace branch anymore, the rest should work seamlessly. If you use plain git commands, it should work out of the box for Gitbutler. If you have implemented your own git reads/writes, then I think it is just a question of accepting the indirection.

Now, I completely acknowledge that I am passing some opinions and talking without any knowledge about Gitbutler codebase. Feel free to correct my errors

[Byron]

Thanks for sharing, @OPeyrusse, technically there will soon be nothing in the way of allowing worktrees, once we validated that it indeed is working as it should in those checkouts.

[Byron]

I have linked #10677 as rough ideation on what could be possible in future. And that future will come, once we have covered:

• apply/unapply
• updating workspaces, stacks, pushing and fetching of stacks
• conflicts when rebasing

All these items are TODO, with apply being in the works.