Unfortunately not! I'm struggling a little with managing comment threads. It's not rocket science, but there are a bunch of annoying edge cases. Especially looking forward to the backends I want to support. Alpha relese hopefully in a couple weeks.
Unfortunately not! I'm struggling a little with managing comment threads. It's not rocket science, but there are a bunch of annoying edge cases. Especially looking forward to the backends I want to support. Alpha relese hopefully in a couple weeks.
I wrote an update on the development of Flirt:
blog.buenzli.dev/flirt-native...
`rebase --autosquash` can be configured as default, so you don't have to think about it anymore:
```gitconfig
[rebase]
autoSquash = true
```
Thank you! From what you describe, Flirt should match up with your ideas very precisely. No matter how small a diff is, some issues only become apparent in the context of the whole code base. That's why I believe local-first review is the way to go.
Ooh, great question. TBH I haven't thought about this too hard yet. I guess a comment could be attached to a line in the left or right side of a diff. The other side wouldn't necessarily be stable, depending on the diff algorithm. How to decide which side to attach the comment to... IDK.
I think I'll have to read a little more about the Radicle protocol to understand what a Flirt backend for it would entail. It looks super interesting so far!
Very cool! I skimmed the user guide's sections on patches. It looks like Radicle doesn't have its own concept of code review? That's a good thing, from the perspective of making a Flirt-backend for Radicle. There's no need for an "adapter" between Radicle's and Flirt's concepts of code review.
I wrote a blog post about Flirt, a new code review tool I started working on:
blog.buenzli.dev/announcing-d...