Flirt: The Native Backend

https://blog.buenzli.dev/flirt-native-backend/

by senekor • 6 months ago

34 15 6 months ago

blog.buenzli.dev

seism• 5 months ago

Excellent. Starting with the domain name :)

N_Lens• 5 months ago

For those curious - Flirt is an incremental code review tool.

CurleighBraces4• 5 months ago

If you haven't read the first blog post it's pretty good at explaining the concepts.

https://blog.buenzli.dev/announcing-development-on-flirt/

The demo is particularly good if you can get past ( by the authors own admission ) slow typing speed.

As with everything these days I can see this being even more useful in reviewing agent code.

For example if an agent has spat out a bunch of code that I've reviewed and then I've asked it to make changes, I definitely do not want to review all that code again in the same diff later.

OJFord• 5 months ago

That's a really good point, at the moment I struggle to get past wanting it to create small logical changes that I can commit individually. If I could review them better such as Flirt describes, then maybe I don't care so much, and a big 'create initial implementation' commit becomes more acceptable, for example.

ale• 5 months ago

How is this different than simply committing between changes? Or even asking the agent to commit changes as it edits files.

CurleighBraces4• 5 months ago

Because I don't review everything between changes, there might be 10 small commits I review and state I am happy with, then I might prompt the agent to perform some small refactors after the review, I don't want the diff to show me everything in those 10 commits again in the diff ( like the usual PR would ) I want it only to show me new stuff.

exceptione• 5 months ago

  > Imagine a commit in a patch series changes 100 lines. 99 of the lines are good, but the first round of review suggests to add a missing semicolon on one of the lines. The author does that by amending the existing commit, to avoid an unseemly "add missing semicolon" commit ending up in the project history. After a force-push (or new patch series submission), reviewers are generally presented with the full 100-line diff to review, because the tools don't understand that only one line changed since the last review.

In the PR-workflow, why not add fixup! commits? I think that when the PR is approved, the PR owner should be free to rewrite the history in their PR.

Flirt looks interesting, but I am not sure if it would solve a real problem for me.

josephg• 5 months ago

Urgh. This problem with git is so unforced. Essentially, people want commits to mean 2 different things at the same time:

1. Store the uncurated history of how the project was developed. 1 commit is created whenever a dev types 'git commit'.

2. Be a linear list of PRs / changes / whatever to a project. Each PR is created by squishing many commits together. It is associated with a conversation around code review, a ticket / issue and often some feature or bug.

Commits can't be both of these things at the same time, so we end up with unnecessary tooling like this.

The answer seems pretty obvious. Git just needs 2 separate mechanisms for these 2 different ideas. The obvious approach would be to leave commits as being atomic units of code change, and invent a new concept in git which represents a feature / feature branch. It would essentially just be a metadata object naming a set of commits, and it would have links to an issue tracker, CI results and code reviews.

skydhash3• 5 months ago

This is a non-problem. Git primary role is a VCS. What you decide to version is up to you.

On the main repo I like linear commits on the main branch where each is tied to a PR and a ticket number. On my local, how I work is relevant to no one except myself.

When I create a PR, I expect the reviewer to do a full review. If I update, it would be best to also do a full because that’s what will be applied. I believe, as a reviewer, you need to understand the full patch, not little snippets over days.

Git just needs 2 separate mechanisms for these 2 different ideas

Git is distributed. What is shared between two instances are patches. These are immutables. If I was sent a set of patches that I would not accept for some reason, I would discard it and wait for an updated set of patches. What you propose should be good according to you, I don’t want days long back and forth.

WorldMaker• 5 months ago

The answer seems pretty obvious. Git just needs 2 separate mechanisms for these 2 different ideas. The obvious approach would be to leave commits as being atomic units of code change, and invent a new concept in git which represents a feature / feature branch. It would essentially just be a metadata object naming a set of commits, and it would have links to an issue tracker, CI results and code reviews.

git already has a tool for this called a "merge commit". A merge commit is mostly just a metadata object pointing to multiple previous commits. Sure, this forms a DAG rather than a line, but when all you want to see is a line just walk the graph in a specific pattern. In git that graph walking pattern is usually called `--first-parent`.

Mostly we just need UIs that stop trying to draw a "subway diagram" at all times and just does a `--first-parent` overview. It's strange to me how much work is being put into squashes and rebases and more just to avoid complicated "subway diagrams" when that often would be just fine with merge commits and adding `--first-parent` to your git log defaults and/or pick a UI tool that does that for you.

saghm• 5 months ago

Yeah, I will happily make small commits like this and then squash all of them before merging. There's been a built-in option for this on Github that's been around for close to a decade at this point and is easy to make the default. I don't feel like this is a real problem.

Flirt: The Native Backend

Related Stories