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.
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.
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...
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.
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.
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.
manfred | 11 hours ago
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.
[OP] senekor | 10 hours ago
I don't mind at all :) I added a short description of Flirt to the blog post, good point.
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.
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.wmurra | 6 hours ago
Very smart LLM policy.
mxey | 4 hours ago
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”.
[OP] senekor | 4 hours ago
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.
mxey | 4 hours ago
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. ;)
wmurra | 2 hours ago
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.
[OP] senekor | 2 hours ago
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...
pflanze | 9 hours ago
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
[OP] senekor | 8 hours ago
Cool stuff! Flirt's approach for reading patches in emails is to to use
git amto 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 useunidiffto parse the patch, which has all the features I needed so far.pflanze | 8 hours ago
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.