For the Claude question, the CLI ships a skill, set it up with `but skill install`.

I hope this helps

NB - the CLI version of GitButler is not yet at feature parity with the graphical version of the app yet

Is it the case that you wish to have multiple agents working on the same task and then picking the best implementation? Or do you have a reason to prefer multiple tasks to be implemented in complete isolation from one another?

The work is not complete but we have stability and correctness as a primary goal, and something that is a requirement for us to declare a v1.0.

We chose not to use separate git worktrees under the hood for this functionality. Let me try to break down why, maybe there's an opportunity for me to learn more here.

In my head I separate between use cases of 1) "different tasks" and 2) "best of n, same task".

The app that we built already had the ability to separate changes into branches while in the worktree (on disk) it renders the integration of the branches. Our canonical use case back in the days was "A developer works on a feature branch and wishes to commit & publish a bugfix from separate branch". When we learned that people were using this for running multiple parallel agents we added some additional tooling for it.

So in practice what happens when you have multiple agents coding in parallel with GitButler is that the system captures information after an agent completes an edit (via the agent hooks) and uses that to 1) stage the particular edit to a branch dedicated to the agent and 2) perform a commit into that branch (GB can have multiple staging areas, one per applied branch).

The system will not allow multiple agents to edit the same file at the same time (via a locking mechanism in the pre-edit hook), but agents do see each others changes.

In the context of the "different tasks for different agents" use case, we have found that them seeing edits by others to have a positive effect on the outcomes. The first one that comes to mind is - no merge conflicts. But beyond merge conflicts, we have found that there is a lower likelihood of reaching a state where code diverges semantically.

In my own usage, I have found it helpful when I am hands on programming on something and wish to have an agent do some auxiliary task, for us to share a workspace (so that I can nudge it one way or another).

Is there something I am missing here? Of course for best-of-n of the same task this doesn't exactly make sense, but with regards to different tasks, what are some additional reasons to require full isolation? (as different worktrees would provide)

Comments URL: https://news.ycombinator.com/item?id=45527221

Points: 2

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=43613305

Points: 306

# Comments: 227

It has happened to me in the past to wonder why certain files/folders are ignored by git, only to realise that I had a global git ignore for the particular pattern.

Not sure l’d recommend this as a good default, but perhaps others have better memory than I do.

Comments URL: https://news.ycombinator.com/item?id=41929688

Points: 1

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=41860394

Points: 9

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=41765760

Points: 2

# Comments: 0

When we were deciding whether we want to build our business[1] around Tauri, the final argument that helped me decide was the video manifesto[2] on their site as I felt that we were aligned on values. Having interacted with the community over this one year I have had a very positive experience, therefore Tauri definitely gets my recommendation.

[0] https://tauri.app/v1/references/architecture/inter-process-c... [1] https://github.com/gitbutlerapp/gitbutler [2] https://tauri.app/about/intro

For my own sake, allow me to articulate the core value proposition once more. GitButler's virtual branches permit two novel use cases:

- A developer can lazily assign diffs/changes to belong to separate logical branches while maintaining their content within the same working dir. Those logical branches can be converted to plain git trees at any time. The canonical use case here is doing a bugfix while working on an unrelated feature - with the proposed workflow one can separate those contributions into discrete PRs while still having the content of both within the working dir.

- A developer can apply and unapply the content of remote branches to their working directory for the purpose of testing & review. This is distinct from rebasing and merging because it does not introduce merging or rebasing into the branch that the developer was originally working on.

In any case, we will work on communicating and documenting the tool better.

With that said, the tool is very cautious not to mess with any existing branches. This is the very reason it operates on a separate integration branch. Switching between the "special/integration" branch and any other branch is also not an issue.

Comments URL: https://news.ycombinator.com/item?id=39306865

Points: 1

# Comments: 0