Flirt is now Open-Source
41 points by senekor
41 points by senekor
I hope you don't mind some constructive criticism. It's likely that your blog posts and the project's README are the first time someone is going to hear about the project so it helps to write for those people.
For example, for me it would be great if the blog post has at least a short description for the what and how. "Flirt is a command-line tool to help inspect contributions in a patch workflow as is common in projects like the Linux kernel. It helps project maintainers to <etc>."
Another example, when arriving at the repository and looking at the README I would love to have quick installation or build instructions so I can quickly try out the project. In my experience only a few people will likely be interested in contributing code to the project early on.
I don't mind at all :) I added a short description of Flirt to the blog post, good point.
In my experience only a few people will likely be interested in contributing code to the project early on.
True, and I honestly don't expect too much engagement at this point. It's just that I promised to make it open-source and I don't really have a reason anymore to postpone it. And, if somebody did want to contribute already, I would find that very cool.
when arriving at the repository and looking at the README I would love to have quick installation or build instructions so I can quickly try out the project.
Well, this is kind of a feature, not a bug. It's a Rust project, so it's just cargo install --path . Non-Rust-devs shouldn't be running it yet (as per the warning in the readme), so pointing out installation instructions would be counter-productive.
Very smart LLM policy.
You are, of course, allowed to use LLMs in a personal context however you see fit. For example, you may use LLMs for exploring the codebase, research, debugging and bouncing around your ideas.
It’s funny they say “of course” — because this statement is enough for the project to go on the open-slopware list as “condones LLM ingestion”.
I'm not sure if I understand your comment correctly. The "of course" part is there because I think it's none of my business. Even if I believe using LLMs in any way is bad, I don't get to tell you what to do. While I think this should be obvious, I still included it for clarity.
I agree with your position. It’s just funny that you (and me) think that’s not our business, but others would already shame the project for that. ;)
That’s funny, that “of course” is the only thing I thought I might edit out if I end up using this as a template. I agree that it should be common sense but words like “obvious” “of course” and “common sense” often inflame people.
Good point, thanks. I'll edit it out. I have to think about a better way to get this point across. Maybe a footnote that explains that personal use is simply out of scope for the policy...
AGPL ;_; I was so excited to use this for work when I first heard about it but I guess that won't be happening
This isn't a knock, I'm just actually a bit sad I can't try it because it fills a niche for a tool I've been desperately needing
How does that in any way prevent using it for work? You're not copying parts of the code into the patches you review...
Legal departments everywhere I've worked have just banned using anything licensed AGPL even as a binary.
Even as a tool? I mean, you're not talking about deploying it, you're talking about running it on your laptop... I've never had a legal department get involved in what I run on my laptop before
I am busy this week, so can't try your project right now, but it looks interesting. Since I've also been working in the area of patch series management lately, I thought I'd mention that since maybe there's room for collaboration. What I'm working on (partially with a contributor, Yusuf):
A parser for patch files [1],
A tool to split patch files [2] based on that parser, and I have made plans to create another tool to compare multiple sets of patch files or commit series to show the changes between them,
A (much better structured) Rust rewrite of a Perl program I made a long time ago [3] to work with Git histories--still haven't finished or published that since I got interrupted a couple months ago.
(PS. all of the linked code is manually written.)
[1] https://github.com/IntermediateResults/split-patch/blob/main/patchparser/README.md [2] https://github.com/IntermediateResults/split-patch/blob/main/split-patch/README.md [3] https://github.com/pflanze/cj-git-patchtool
Cool stuff! Flirt's approach for reading patches in emails is to to use git am to turn the email into a commit, which can then be treated the same way as other backends that use commits directly. In order to read comments, I use unidiff to parse the patch, which has all the features I needed so far.
OK, thanks for your reply!
What cj-git-patchtool does is turn Git commits into patch files, which then are worked on as files (allowing even manual edits to the diffs directly), then read them back into Git via git am. That's how I end up needing to parse and write patch files. (I actually don't remember why I didn't decide to use the unidiff crate, either somehow escaped my search (weird), or there was some issue, I'll check again when I find time. What I did find out during patchparser's creation was that letting bumpalo "own" all data provides for a nice programming paradigm for persistent data structures, perhaps that will remain an argument to not use unidiff, but I'll see.)
I hope to check out your project some time in the next weeks.