Feature request / just a thought: best of both worlds: worktrees and gitbutler workspace

[fabian-xentral]

Hey folks,

working with gitbutler really made my life tremendously easier compared to earlier times with pure git.

One thing, however, keeps me struggling -- and maybe I didn't understand how to ideally set things up; in which case I would love to hear your recommendations.

Here's the challenge:

• I constantly have several agents running, producing code for different aspects, tuning features, fixing bugs.
• This works pretty nicely and for the most part, particularly if this are far enough apart from each other, the agents can reliably commit their work to the respective lanes.
• Sometimes, however, they get worried and unsure about the workspace moving while they're preparing the commits, fearing that something might sneak in since they last checked.

The idea:

• what if we combined git worktrees with gitbutler
• while an agent is running, they operate on their isolated worktree, where we only have whatever is currently in the combined workspace plus their modifications
• once they commit to any applied lane, their changes flow into the combined gitbutler workspace -- and consequently into all other lanes as well.
• What's different though:
  • they can work, and we can have defined consolidation points in time where things get put togeher.
  • Each works in isolation until they shipped. Clearly, while one is putting together their commit, and another one commits to a lane, this may cause a moving target again -- but it is much more controllable. Also the output of each of the agents would be directly visible at a glance, and you wouldn't have to worry which contribution comes from where.

What do you think?

Thank you & BR
f

[Byron]

Thanks so much for sharing!

Worktrees came up a lot lately! And I believe it will all be unlocked with single-branch-mode, which at least allows GitButler to be opened on a worktree directly, i.e. a branch that isn't gitbutler/workspace.

what if we combined git worktrees with gitbutler

This is an interesting idea and it's something that I think wouldn't be implemented at first. It would be that a worktree is created for branches that are in the GitButler workspace. Agents will work in their respective branch and use but to create commits. These would then be visible in the workspace that the user has created, combining the branches of multiple agents into one.

Having agents see the workspace commit, work on that in an isolated fashion, and absorb the changes into their respective branches is a great idea for letting them work together.

Both versions have their merit, and I think both should be able to work.

[Caleb-T-Owens]

I put together a rough demo of how worktrees could look in the future. I would be curious to see what you think about it.

tui-worktrees.mov

[lmtr0]

This looks incredibly good and would improve my workflow a lot right now

[fabian-xentral]

Hey @Byron & @Caleb-T-Owens , really cool how quickly you picked up on this !

Caleb, thank you for the demo and the video - really insightful !

IMHO I would have expected the file to remain on the worktree as well and not be moved over to the workspace.

The idea is more to keep somewhat separate areas where the agents can work independently until they are done, and once they commit things appear in the workspace (unified state across all applied lanes, essentially from there on existing gitbutler philosophy).
Keeping the files in the worktree allows the agents to continue work and iterate further, committing (maybe even amending) their subsequent changes, which then again make it into the worktree.

Instead of tying the propagation to the worktree to committing, it could already be sufficient to simply stage stuff to a lane -- this would give even more control and thinking about it I would actually even prefer that over commit-based propagation.

Now clearly: we'd have 2 versions on disk of the same file, so if someone came to the idea to modify the file in the workspace, that might be a bit icky ... would symlinks or a back-propagation option in case of such modifications be an option ?

How do you feel about this ?

Thank you & BR !
f

[Byron]

The demo was merely showing that an out-of-workspace worktree branch can be shown, and that moving a commit will update both worktrees respectively to match the now changed HEAD.
In a way, it was showing of something entirely now.

Assuming everything still is in a single workspace, then the linked worktree may have been 'muted', i.e. it's branch didn't contribute to the workspace, it is merely displayed. Then, once the workspace changed as the commit was moved into an unmuted branch, it showed up in the main worktree.

If that worktree branch was unmuted (the default), its commits would show up in the workspace automatically, assuming that GitButler notices that something changes if the commit is agent-created. So I think your proposed workflow would be possible with that, too.

[Caleb-T-Owens]

The plan would be to have operations to apply and unapply-to-worktree easily, as well as having some sort of "cherry-pick" operation between a WT and the workspace (and the other way round).

As you say, it does introduce the problem-set of having two potentially diverged versions of the same commit. It may take a little longer to solve this, but one thing we've been looking at is something like mercurial's obsolescence markers which let you build up a graph structure that describes how the same "change" has diverged across multiple commits, which then provides you with the ability to perform a three-way-merge to reconcile those changes again.