3 ms·

Perhaps the best of both worlds would just be to write a warning to stderr by default that files in .gitignore have been ignored (only if such a file is applied

by setopt 2y ago

Perhaps the best of both worlds would just be to write a warning to stderr by default that files in .gitignore have been ignored (only if such a file is applied)?

Timwi 2y ago
Or just have a command-line option to specify an ignore file. That's strictly more useful because then you're not arbitrarily limited to files named “.gitignore”.
- setopt 2y ago
  rg, fd, etc. all use not only .gitignore, but also merge in rules from a global gitignore in your home directory, as well as a local .ignore file that takes precedence over .gitignore. Setting up all that with CLI flags is a lot of work for what is arguably a sensible default.
  - godelski 2y ago
    > Setting up all that with CLI flags is a lot of work for what is arguably a sensible default. alias fd="fd --include-gitignore --include-global-gitignore" alias rg="rg --include-gitignore --include-global-gitignore" I would not consider even a long line like this in your shell's config file "a lot of work". In fact, it seems pretty standard.
- burntsushi 2y ago
  Why assume that ripgrep or fd is "arbitrarily" limited to files named `.gitignore`?
burntsushi 2y ago
This won't happen because it would imply writing a warning for almost every run of ripgrep. It's the kind of warning that pisses people off because 1) it's the intended behavior and 2) since it would be shown almost all the time, folks would immediately start ignoring it. ripgrep does try to emit a warning if you run `rg foo` and it doesn't search any files because of gitignore. This can happen in some cases, e.g., when you have a `.gitignore` in your `$HOME` with a `*`.
- setopt 2y ago
  Makes sense – thanks for the explanation and for ripgrep. Personally, I love this default and find it way more usable than grep in most cases. It’s a more important feature to me than the per-file search speed, since grep is often fast enough.

by setopt 2y ago

Perhaps the best of both worlds would just be to write a warning to stderr by default that files in .gitignore have been ignored (only if such a file is applied)?

Timwi 2y ago

Or just have a command-line option to specify an ignore file. That's strictly more useful because then you're not arbitrarily limited to files named “.gitignore”.

setopt 2y ago
rg, fd, etc. all use not only .gitignore, but also merge in rules from a global gitignore in your home directory, as well as a local .ignore file that takes precedence over .gitignore. Setting up all that with CLI flags is a lot of work for what is arguably a sensible default.
- godelski 2y ago
  > Setting up all that with CLI flags is a lot of work for what is arguably a sensible default. alias fd="fd --include-gitignore --include-global-gitignore" alias rg="rg --include-gitignore --include-global-gitignore" I would not consider even a long line like this in your shell's config file "a lot of work". In fact, it seems pretty standard.
burntsushi 2y ago
Why assume that ripgrep or fd is "arbitrarily" limited to files named `.gitignore`?

burntsushi 2y ago

This won't happen because it would imply writing a warning for almost every run of ripgrep. It's the kind of warning that pisses people off because 1) it's the intended behavior and 2) since it would be shown almost all the time, folks would immediately start ignoring it. ripgrep does try to emit a warning if you run `rg foo` and it doesn't search any files because of gitignore. This can happen in some cases, e.g., when you have a `.gitignore` in your `$HOME` with a `*`.

setopt 2y ago
Makes sense – thanks for the explanation and for ripgrep. Personally, I love this default and find it way more usable than grep in most cases. It’s a more important feature to me than the per-file search speed, since grep is often fast enough.