3 ms·

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

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.

dnpp123 7y ago
(i'm the author of the fork) 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.
burntsushi 7y ago
> 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.