I realise that this is a bit of a special case.. OK it's a really special case. But it's a bit of a shame not to see it actually merging back up stream though I'm very glad they did some work to make the fork easier to maintain.
There are a lot of these new world great utilities like ripgrep, silversearcher, a bunch of rust parallel re-implementations of various core utilities. It would be nice to see more of them become easy to be the "default" tool to use. And forks make that harder.
> But it's a bit of a shame not to see it actually merging back up stream
What's a shame is people publicly complaining about how volunteers don't take on more work. Please don't do that next time. Thanks.
> It would be nice to see more of them become easy to be the "default" tool to use. And forks make that harder.
This fork has about zero relevance to whether ripgrep can be used as a replacement for other tools like GNU grep. The fork is serving an important but niche use case.
Yes the use case here is quite peculiar. Ripgrep default search engine is already amazingly fast, plus the fact that hyperscan DB can only be compiled using a single core and take some time doesn't help.
I'll try to sync the fork with upstream at least once a month in the future.. but yeah the ubiquity of (GNU) grep makes it hard to replace.
However since you can precompile the DB (with the provided flag), this works fine when you have a lot of regexps which don't change and new packs of data to parse.. which was (basically) the original use case of hyperscan.
For a single use, unless you have hundreds of GB of data to parse, the default ripgrep engine might just be better.
