4 ms·

I know this isn't the perfect place for a feature request, but I've recently found it quite annoying that ripgrep ignores .github directories because they're hi

by sshine 1y ago

I know this isn't the perfect place for a feature request, but I've recently found it quite annoying that ripgrep ignores .github directories because they're hidden. Maybe there are similar directories that people prefer included by default. Then again, if these results suddenly pop up and people upgrade to a major version and expect backwards compatibility, the tradeoff might not be worth it.

burntsushi 1y ago
> I know this isn't the perfect place for a feature request, but I've recently found it quite annoying that ripgrep ignores .github directories because they're hidden. As has been suggested elsewhere in this thread, have you considered `echo '!/.github/' > .ignore` in the root of your repository? That's what ripgrep's repo itself does: https://github.com/BurntSushi/ripgrep/blob/d47663b1b4548e4fa02d6e4b575718d0f5f5e7d6/.ignore https://github.com/BurntSushi/ripgrep/blob/d47663b1b4548e4fa... There have been some requests to whitelist certain directories by default. And it will absolutely never happen. It makes the semantics too complicated and even more surprising. Today, I can just say, "ripgrep respects gitignore, ignores hidden files and binary files." But if I started whitelisting specific things, that description would no longer be correct. I'd have to add them as exceptions when explaining ripgrep's default heuristics. Plus, whitelisting a directory is extremely easy and simple. People seem to think `.ignore` files are only for ignoring. But they're not. They also let you un-ignore things without having to touch the CLI command. > Then again, if these results suddenly pop up and people upgrade to a major version and expect backwards compatibility, the tradeoff might not be worth it. I do use semver in ripgrep. That is, if I make a breaking change, then I bump the major version. Regardless, big breaking changes that aren't exceptionally well motivated are basically off the table. semver allows breaking changes to be made, but it works best in the context of libraries. For ripgrep, that has direct end users, semver doesn't really help much. Users will just experience their scripts breaking. Or commands they used to use, now don't work any more or do something different.

by sshine 1y ago

burntsushi 1y ago

> I know this isn't the perfect place for a feature request, but I've recently found it quite annoying that ripgrep ignores .github directories because they're hidden. As has been suggested elsewhere in this thread, have you considered `echo '!/.github/' > .ignore` in the root of your repository? That's what ripgrep's repo itself does: https://github.com/BurntSushi/ripgrep/blob/d47663b1b4548e4fa02d6e4b575718d0f5f5e7d6/.ignore https://github.com/BurntSushi/ripgrep/blob/d47663b1b4548e4fa... There have been some requests to whitelist certain directories by default. And it will absolutely never happen. It makes the semantics too complicated and even more surprising. Today, I can just say, "ripgrep respects gitignore, ignores hidden files and binary files." But if I started whitelisting specific things, that description would no longer be correct. I'd have to add them as exceptions when explaining ripgrep's default heuristics. Plus, whitelisting a directory is extremely easy and simple. People seem to think `.ignore` files are only for ignoring. But they're not. They also let you un-ignore things without having to touch the CLI command. > Then again, if these results suddenly pop up and people upgrade to a major version and expect backwards compatibility, the tradeoff might not be worth it. I do use semver in ripgrep. That is, if I make a breaking change, then I bump the major version. Regardless, big breaking changes that aren't exceptionally well motivated are basically off the table. semver allows breaking changes to be made, but it works best in the context of libraries. For ripgrep, that has direct end users, semver doesn't really help much. Users will just experience their scripts breaking. Or commands they used to use, now don't work any more or do something different.