3 ms·

I strongly disagree. Neither of those tools claim to be drop-in replacements. They’re more like a reinvention of the older tools given what we’ve learned in the

I strongly disagree. Neither of those tools claim to be drop-in replacements. They’re more like a reinvention of the older tools given what we’ve learned in the many decades since the originals came out, and tailored for the common use cases today. It’s rare that I want to grep, say, the node_modules directory in a JS project. The default of showing the results that git says are my own code is very useful. And as you say, there are aliases if you want to get off the beaten path.

godelski 2y ago
Disagree all you want, you still shouldn't be surprised people aren't expecting this fd: https://github.com/sharkdp/fd/issues?q=gitignore+ https://github.com/sharkdp/fd/issues?q=gitignore+ And I stand by it is strictly better for the __default__ to be unfiltered. This is what people expect in general. > tailored for the common use cases today. *YOUR* common usecases. Grep, sure, it is rare that I want to grep a binary file. But I do want to grep configs and secrets. I do want to find binaries all the time. There are many different ways to program and expecting everyone to program like you or even remotely like you is naive. There's so many things under the sun. Failure analysis is critical when designing anything. So let me rephrase Which do you think is a better mode of failure? 1) Not finding files you are expecting to find 2) Finding more files than you expect to find Or for ripgrep, grepping fewer files than you expect to vs grepping more files than you expect to. It is very hard to argue for one considering we have regex to filter which files we want... not to mention pipes and all sorts of common tools including the tools themselves.
- poincaredisk 2y ago
  >Grep, sure, it is rare that I want to grep a binary file. Case in your point - I grep binary files all the time (mainly to look for strings in complied executables).
  - godelski 2y ago
    A hacker on hacker news‽ But yeah this is why I'm arguing for no filtering by default and why I believe the best designs are the most flexible ones. Because any time I think "nobody would need that" I find a world of people I didn't know about. You can't ever predict the usage, so flexibility and defaults aren't about what fits most people's use cases but what can be easily modified to use cases of any group. I'm definitely too dumb to figure out what everyone actually needs lol
- 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 `*`.
- kstrauser 2y ago
  No, the most common use cases for the people using a tool designed to more easily search source code. Notice that the examples on its site show searching the Linux source code. For that matter, the very first sentence on that site says “ripgrep recursively searches directories for a regex pattern while respecting your gitignore” Grep still exists, unchanged. It does what you want it to. Ripgrep is a new tool designed for a different use case. It’s not about failure modes. Ripgrep isn’t failing when it doesn’t show you the files it tells you it’s going to skip in the very first line of its description. Again, you don’t have to use it if its advertised purpose doesn’t line up with what you want.
  - godelski 2y ago
    > For that matter, the very first sentence on that site says I'd rather not go in circles. Please refer back to the original post as I addressed this. See package managers and word of mouth. Do you really visit the website or GitHub page for every tool you install? I'd be surprised if you did. Also, why is it not okay that the design was wrong? That doesn't make it a bad project. But we can recognize that choices could have been better. Those are different things. It's learning from the past https://en.wikipedia.org/wiki/Principle_of_least_astonishment https://en.wikipedia.org/wiki/Principle_of_least_astonishmen...
    - kstrauser 2y ago
      Do I read the manual of every tool I use before counting on it? Yes, absolutely. The first sentence of ripgrep's man page's description section is: ripgrep (rg) recursively searches the current directory for a regex pattern. By default, ripgrep will respect your .gitignore and automatically skip hidden files/directories and binary files. You cannot pick up a tool, start using it without understanding what it does, then tell the tool that it's doing things wrong.
      - godelski 2y ago
        > Do I read the manual of every tool I use before counting on it? Yes, absolutely. Sorry I'm not sure I believe you and even if you are that rare case, I think you know most people don't. I'm a manual lover myself but haven't read all the manuals of all the tools I use. That would be extremely cumbersome given the sheer amount and the complexity of some tools. > You cannot pick up a tool, start using it without understanding what it does I don't disagree with the exact words but I do with what I think you're arguing. Lots of tools have a natural design where you can intuit their usage. A hammer or screwdriver is a great example. Many videogames also teach you how to play via level design without the need for tutorials (there's also many many terrible examples from video games and many sub par ones too). And that's what I'm arguing about when I'm talking about the direction of error. There's a natural signal coming back to the user so they know if something is wrong or isn't. But letting users think things are good when they aren't is an extremely costly error.

godelski 2y ago

Disagree all you want, you still shouldn't be surprised people aren't expecting this fd: https://github.com/sharkdp/fd/issues?q=gitignore+ https://github.com/sharkdp/fd/issues?q=gitignore+ And I stand by it is strictly better for the __default__ to be unfiltered. This is what people expect in general. > tailored for the common use cases today. *YOUR* common usecases. Grep, sure, it is rare that I want to grep a binary file. But I do want to grep configs and secrets. I do want to find binaries all the time. There are many different ways to program and expecting everyone to program like you or even remotely like you is naive. There's so many things under the sun. Failure analysis is critical when designing anything. So let me rephrase Which do you think is a better mode of failure? 1) Not finding files you are expecting to find 2) Finding more files than you expect to find Or for ripgrep, grepping fewer files than you expect to vs grepping more files than you expect to. It is very hard to argue for one considering we have regex to filter which files we want... not to mention pipes and all sorts of common tools including the tools themselves.

poincaredisk 2y ago
>Grep, sure, it is rare that I want to grep a binary file. Case in your point - I grep binary files all the time (mainly to look for strings in complied executables).
- godelski 2y ago
  A hacker on hacker news‽ But yeah this is why I'm arguing for no filtering by default and why I believe the best designs are the most flexible ones. Because any time I think "nobody would need that" I find a world of people I didn't know about. You can't ever predict the usage, so flexibility and defaults aren't about what fits most people's use cases but what can be easily modified to use cases of any group. I'm definitely too dumb to figure out what everyone actually needs lol
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 `*`.
kstrauser 2y ago
No, the most common use cases for the people using a tool designed to more easily search source code. Notice that the examples on its site show searching the Linux source code. For that matter, the very first sentence on that site says “ripgrep recursively searches directories for a regex pattern while respecting your gitignore” Grep still exists, unchanged. It does what you want it to. Ripgrep is a new tool designed for a different use case. It’s not about failure modes. Ripgrep isn’t failing when it doesn’t show you the files it tells you it’s going to skip in the very first line of its description. Again, you don’t have to use it if its advertised purpose doesn’t line up with what you want.
- godelski 2y ago
  > For that matter, the very first sentence on that site says I'd rather not go in circles. Please refer back to the original post as I addressed this. See package managers and word of mouth. Do you really visit the website or GitHub page for every tool you install? I'd be surprised if you did. Also, why is it not okay that the design was wrong? That doesn't make it a bad project. But we can recognize that choices could have been better. Those are different things. It's learning from the past https://en.wikipedia.org/wiki/Principle_of_least_astonishment https://en.wikipedia.org/wiki/Principle_of_least_astonishmen...
  - kstrauser 2y ago
    Do I read the manual of every tool I use before counting on it? Yes, absolutely. The first sentence of ripgrep's man page's description section is: ripgrep (rg) recursively searches the current directory for a regex pattern. By default, ripgrep will respect your .gitignore and automatically skip hidden files/directories and binary files. You cannot pick up a tool, start using it without understanding what it does, then tell the tool that it's doing things wrong.
    - godelski 2y ago
      > Do I read the manual of every tool I use before counting on it? Yes, absolutely. Sorry I'm not sure I believe you and even if you are that rare case, I think you know most people don't. I'm a manual lover myself but haven't read all the manuals of all the tools I use. That would be extremely cumbersome given the sheer amount and the complexity of some tools. > You cannot pick up a tool, start using it without understanding what it does I don't disagree with the exact words but I do with what I think you're arguing. Lots of tools have a natural design where you can intuit their usage. A hammer or screwdriver is a great example. Many videogames also teach you how to play via level design without the need for tutorials (there's also many many terrible examples from video games and many sub par ones too). And that's what I'm arguing about when I'm talking about the direction of error. There's a natural signal coming back to the user so they know if something is wrong or isn't. But letting users think things are good when they aren't is an extremely costly error.