hi

[asottile]

the best time for collaboration probably would have been when starting the project but I guess the second best time is now!

the slated long-term plan for pre-commit is to replace the python implementation with rust -- I've been slowly working towards that over the last couple of years but I've been busy and progress has been slow. I figure we can probably accelerate that if you'd like to work together on accomplishing it

there's also the tricky task of compatibility and migration (which I've fortunately thought a lot about and will hopefully make the transition smoother!) -- the main compatibility issues is going to be around regular expressions, language: pygrep, and ultimately bootstrapping python where missing for language: python (though I think uv will likely take that responsibility at some point) -- happy to talk more on this though as it's kinda the hardest part of making such a shift successful

can also help with the planned direction I'm going for with languages in general -- as that's going to break a lot of what isn't yet implemented here (or there) since the structure and internals are likely to change a lot there (goal being to divorce the installations, repositories, and languages as they're really three separate entities currently represented as one (maybe 1.5 if we're being honest))

an aside -- the repository in the current state violates several copyrights and licenses. I intentionally chose to release my code under MIT to make it very simple to abide by the license (simply distribute a copy of the license in derivative works) but unfortunately your current implementation reads as a plagiarism -- fortunately an easy fix to include the licenses of your copied work!

[j178]

I'm thrilled to see you, @asottile!

I apologize for the copyright violation regarding pre-commit. I must admit that I essentially translated the original Python implementation into this project. I've now added a copyright notice for pre-commit to the LICENSE in #74. Thank you so much for your outstanding work on pre-commit!

I started this project purely to practice Rust and was completely unaware of the existence of https://github.com/pre-commit/pre-commit-rs, which has been around for two years! I never intended for this project to become widely known, so I didn't reach out for collaboration—especially since my Rust skills are quite basic and I wasn't sure how far this project would go.

I'm truly honored by your invitation to collaborate! I believe the ideal home for this project is https://github.com/pre-commit/pre-commit-rs. Do you have any specific plans for moving forward? Since I wasn't aware of https://github.com/pre-commit/pre-commit-rs, my implementation took a slightly different path. How do you find the current implementation? Would you prefer a merge, or should we develop anew from the ground up?

But there are reasons this project should continue. I have ideas that might differ from yours regarding implementations or feature additions. Initially, I envisioned this project as a unique dialect of the original pre-commit, not a replacement. I might keep some distinct features here, as the original pre-commit is so widely used, and adding features or making breaking changes is challenging. This way, users can choose whichever suits them best.

What do you think? Thanks again for reaching out—I really appreciate it!

[asottile]

I'm truly honored by your invitation to collaborate! I believe the ideal home for this project is https://github.com/pre-commit/pre-commit-rs. Do you have any specific plans for moving forward? Since I wasn't aware of https://github.com/pre-commit/pre-commit-rs, my implementation took a slightly different path. How do you find the current implementation? Would you prefer a merge, or should we develop anew from the ground up?

I haven't had time to look over much of this code yet -- though the few files I've glanced at look like they were straight ported by chatgpt? given that I think I'd prefer to continue in the approach I was going with -- which is carefully porting a piece of functionality at a time until the rest is built out -- and then working on the compatibility / transition plan (tool for testing existing configuration for regex compatibility, "deprecating" pygrep for rsgrep (doesn't exist yet), etc.)

But there are reasons this project should continue. I have ideas that might differ from yours regarding implementations or feature additions. Initially, I envisioned this project as a unique dialect of the original pre-commit, not a replacement. I might keep some distinct features here, as the original pre-commit is so widely used, and adding features or making breaking changes is challenging. This way, users can choose whichever suits them best.

I was a little worried you'd say this. I hope you understand the optics of what you've built so far looks like a hostile fork -- and is unethical to lift the code as you've done. the "not a replacement" at the very least seems disingenuous given your README uses exactly the word replacement.

ideally this wouldn't continue. two separate divergent implementations is going to create a rift in users and add undue compatibility / complexity pains (for both parties!).

I totally get wanting to learn rust and try out cool things but I would strongly encourage you to build your own project instead of ripping off mine :) and while my LICENSE intentionally does not forbid you to do such things I'd encourage you think think about them from an ethical perspective.

and ignoring all of that if you want to continue divergently please change the name to reduce as much confusion as possible (pre-commit's name already sucks enough -- I'd hate for you to carry that too!)