videlov

I was interested in answering this question so I built a benchmark comparing git, jj and gitbutler in agentic context

https://vcbench.dev/

Disclaimer - I am a co-founder of GitButler

Surprised to see they kept Tauri. In our experience of using Tauri, it has been a significant source of compatibility and performance issues related to it's use of WebKit and WebKitGTK. So much so that we have started an effort of migrating away from it for our app, in favor of Electron (https://github.com/gitbutlerapp/gitbutler/tree/master/apps/l...) The choice was made specifically for the benefit of our users, but we were also pleasantly surprised by how much better the development experience is with it.

We will remove the hook constraint as soon as we complete this https://github.com/gitbutlerapp/gitbutler/issues/11866

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

I hope this helps

The app has a built-in mechanism for going back in time (an operations log) which can be used for undoing situations that should not arise in the first place. It can be accessed via the app (there's a history tab) as well as via the CLI https://docs.gitbutler.com/commands/but-oplog

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

You are right - it is something we did intentionally, but I would like to learn more from your use case - what is the reason to prefer isolation of changes?

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?

(co-founder of gb here) I am really sorry for the frustration - the app should do better and we will do better. In the past few months we have been putting a very deliberate effort to eliminate all conditions from which such poor experience can come about.

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.

(co-founder of GitButler here)

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)

excludesfile = ~/.gitignore

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.

I have found the following community site for generating Ghostty config quite helpful https://ghostty.zerebos.com/

Martin (the jj creator) recently gave a talk at the Git Merge 2024 conference: https://youtu.be/LV0JzI8IcCY?si=Pun7WJp4ZWvHq-3G

GitButler | Senior <Rust | TypeScript | Ruby> Engineer | Full-time | Onsite Berlin

We are a small team of 9 people who love Git, building new functionality on top of the Git format (branching, code review & more). Our own @schacon has published the Pro Git book as well as co-founded GitHub.

Repository: https://github.com/gitbutlerapp/gitbutler Tech stack: Rust, TypeScript / Svelte in the Client, Ruby / Rails on the backend.

Currently looking for Senior Software Engineers with Rust, TypeScript (frontend) or Ruby skills to join us onsite in Berlin. Job ads: https://gitbutler.homerun.co

We have been using Tauri for about a year (a desktop app) and I am very happy with our choice. What I initially found attractive was the smaller binary sizes. Over time I have come to really appreciate their stance on security and implementation of the Isolation pattern[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

I think you are right that our documentation does not sufficiently communicate what the application does especially in various corner cases.

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.

This limitation stems from the fact that GB introduces an additional dimension of versioning on top of Git. One way of thinking of what it does with virtual branches is like "multiplexing" multiple branches onto the same working directory. On the way out they get "demuxed" into plain git trees.

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.

I think there may be a misunderstanding here. While the tool does something unorthodox locally, the output that it generates is plan Git trees that do represent a consistent snapshot. It is the process of arriving at those snapshots (locally) that we feel we can make more ergonomic. Disclaimer: I am a Co-founder

We used an app called Screen Studio.

This article resonated with me be because I have also thought of branches as something ephemeral, with the ultimate goal of packaging and delivering a change to "prod". Perhaps this has to do with the fact that I have mostly worked on projects that have the concept of "prod".

The "what is a branch" question has been very interesting for me for a while. One alternative way of looking at it is as just semantic groupings as opposed to separate universes. For almost a year I have been working on an idea[0] of having multiple branches applied in the working directory at the same time. Why? To make it easier for me to organise my changes in small PRs (eg. bugfix, featureX, unrelated refactors etc). If anyone reading this is also into the 'what is a branch' question, I would actually like to get some critique / feedback & opinions

[0] https://docs.gitbutler.com/features/virtual-branches

Currently GitButler only generates commit messages in this way (with some config options for style e.g. semantic commits). With that said, generating PR descriptions is something I was tinkering with this morning.

(disclaimer: I'm a GitButler co-founder)

Thank you for sharing this project! I have been searching for something like this for some time

I quite like your diff visualisation idea, thanks for sharing. Since I am currently working on a git client (gitbutler), I'm gonna experiment a little bit to see how it feels in practice

I wish we could go back to a world where 'crypto' means cryptography

GitButler | Senior Rust Developer | Berlin | Onsite | git

About GitButler: We are building a git-compatible next-gen version control. Currently a team of 5, including one of GitHub cofounders (https://twitter.com/chacon).

Product Docs: https://docs.gitbutler.com/features/virtual-branches

Role (Berlin, Onsite): You will be working with us developing a desktop app using Rust & the Git internals (libgit2). We are looking for an experienced and practical Rust developer to join our tight-knit local team in our cool office space.

Job ad: https://gitbutler.homerun.co/senior-rust-developer/en

GitButler | Senior Rust Developer | Berlin | Onsite | git

About GitButler: We are building a git-compatible next-gen version control. Currently a team of 5, including one of GitHub cofounders.

Product Docs: https://docs.gitbutler.com/features/virtual-branches

Role (Berlin, Onsite): You will be working with us developing a desktop app using Rust & the Git internals (libgit2). We are looking for an experienced and practical Rust developer to join our tight-knit local team in our cool office space.

Job ad: https://gitbutler.homerun.co/senior-rust-developer/en

Over the past couple of days I tried 11 different vector databases, in order to evaluate and decide which one we'd choose for our use case.

I ended up choosing Weaviate specifically because of the nice docs, but beyond that, time will tell.

We built a semantic code search CLI tool (fully local and open source) using a similar model that I tuned https://github.com/sturdy-dev/semantic-code-search

I found the blog posts by Jay Alammar to be particularly good. Here are my starting suggestions (in this order) — https://jalammar.github.io/illustrated-word2vec/ https://jalammar.github.io/illustrated-transformer/ https://jalammar.github.io/illustrated-bert/ https://jalammar.github.io/illustrated-stable-diffusion/

Hey HN! Last week I saw this thread 'AI found a bug in my code' (https://news.ycombinator.com/item?id=33632610) which I thought was pretty cool.

I was inspired and wanted to play around with the idea, both for learning and also to try it on my code, so I built my own implementation of it (I could not find the sources from the OP).

It was important for me to make it as a local and privacy respecting app (i.e. running locally), which placed some constraints on the model size I could use, but the results are looking promising.

Feel free to play around with the tool / code (this is why I'm sharing it)! I would love to hear if it detects anything interesting for you.

Here's a demo output: https://sturdy-dev.github.io/suspicious/demos/cli_py/ (more in the README.md)

i made an open source implementation of this idea, not sure if OP did it the same way https://github.com/sturdy-dev/suspicious

I recently saw a company that seems to be doing just that[0], but I’m not sure if their model is open source

[0] https://www.kaedim3d.com/

It is not trained per language but it has 2 things up its sleeve: it considers the author's past experience in the context of the files being changed as well as if similar code changes (perceptual hashes) are associated with objections or fixes.