6 ms·

You raise good points, thank you. I hope to support some of those features, since they seem like nice conveniences. In principle I'd be fine standardizing on a

You raise good points, thank you. I hope to support some of those features, since they seem like nice conveniences. In principle I'd be fine standardizing on a common ignore file. We'd need to come up with a format (I think I'd vote for "do what gitignore does", since I think that's what we're both doing now anyway). Adding files to this list is kind of a bummer though. I could probably get away with replacing `.rgignore` proper, but I suspect you'd need to add it without replacing `.agignore`, or else those angry users you were talking about might show themselves. :-) I do kind of like `.grepignore` since `grep` has kind of elevated itself to "search tool" as a term, but I can see how that would be confusing. `.searchignore` feels too long. `.ignore` and `.ignorerc` feel a bit too generic, but either seems like the frontrunner at the moment.

ggreer 10y ago
I also vote for "do what gitignore does". My plan is to add support for the new file name, deprecate .agignore, and update docs everywhere. But it'd be a while before I removed .agignore completely. I really like .ignore, and I like it because it's generic. The information I want it to convey is: > Dear programs, > If you are traversing this directory, please ignore these things. Of course, some programs could still benefit from having application-specific ignore files, but it'd cut down on a lot of cruft and repetition.
- burntsushi 10y ago
  Let's do it. https://github.com/BurntSushi/ripgrep/issues/40 https://github.com/BurntSushi/ripgrep/issues/40
  - ggreer 10y ago
    …and merged: https://github.com/ggreer/the_silver_searcher/pull/974 https://github.com/ggreer/the_silver_searcher/pull/974 I'll tag a new release in a day or two. Also, it looks like the sift author is getting on the .ignore train: https://github.com/svent/sift/issues/78#issuecomment-249335277 https://github.com/svent/sift/issues/78#issuecomment-2493352... This worked out pretty well. :)
    - burntsushi 10y ago
      Same! https://github.com/BurntSushi/ripgrep/pull/41 https://github.com/BurntSushi/ripgrep/pull/41 Agreed :-)
      - deleted 10y ago
        [deleted]
      - tonglil 10y ago
        This is probably the best case of out-in-the-open open source developers of similar-but-different tools collaborating on a new standard and implementing them in record time that I have ever seen. Keep it up all (rg/ag/sift)!
        scott_karana 10y ago
        I completely agree. That was one of the most reasonable and level-headed discussions between strangers I have _ever_ seen on the Internet!
  - deleted 10y ago
    [deleted]
chrisshroba 10y ago
I really like .grepignore as it is generic enough to encompass all tools which have grep-like functionality while never stepping on the feet of other programs that may also require ignore files that may be different than the .grepignore.
- ggreer 10y ago
  The problem is that grep will never obey .grepignore. That's so confusing as to be a deal-breaker. Also, what about programs that have search functionality as part of their design, but not as their core function? For example, I don't want my text editor to search .min.js files. I'd even prefer it if such files didn't show up in my editor's sidebar. Do I have to add *.min.js to .searchignore and .atomignore? (Or if the editor people ever work out a standard, maybe it will be .editorignore.) If I had to draw a Venn diagram of ignore patterns in my text editors, my search tools, and my rsync scripts, they'd mostly overlap. I don't deny the need for application-specific ignores, but there is a large class of applications that could benefit from a more generic ignore file.
  - ajsalminen 10y ago
    I do think it would be better to have the name at least reflect that class of applications, maybe "searchignore" like someone else suggested. There may be overlap but it's hard to predict all the types of applications people are using that need ignore functionality and something as simple as backing things up with rsync would seem like an example where someone could well want considerably different ignores.

ggreer 10y ago

I also vote for "do what gitignore does". My plan is to add support for the new file name, deprecate .agignore, and update docs everywhere. But it'd be a while before I removed .agignore completely. I really like .ignore, and I like it because it's generic. The information I want it to convey is: > Dear programs, > If you are traversing this directory, please ignore these things. Of course, some programs could still benefit from having application-specific ignore files, but it'd cut down on a lot of cruft and repetition.

burntsushi 10y ago
Let's do it. https://github.com/BurntSushi/ripgrep/issues/40 https://github.com/BurntSushi/ripgrep/issues/40
- ggreer 10y ago
  …and merged: https://github.com/ggreer/the_silver_searcher/pull/974 https://github.com/ggreer/the_silver_searcher/pull/974 I'll tag a new release in a day or two. Also, it looks like the sift author is getting on the .ignore train: https://github.com/svent/sift/issues/78#issuecomment-249335277 https://github.com/svent/sift/issues/78#issuecomment-2493352... This worked out pretty well. :)
  - burntsushi 10y ago
    Same! https://github.com/BurntSushi/ripgrep/pull/41 https://github.com/BurntSushi/ripgrep/pull/41 Agreed :-)
    - deleted 10y ago
      [deleted]
    - tonglil 10y ago
      This is probably the best case of out-in-the-open open source developers of similar-but-different tools collaborating on a new standard and implementing them in record time that I have ever seen. Keep it up all (rg/ag/sift)!
      - scott_karana 10y ago
        I completely agree. That was one of the most reasonable and level-headed discussions between strangers I have _ever_ seen on the Internet!
- deleted 10y ago
  [deleted]

chrisshroba 10y ago

I really like .grepignore as it is generic enough to encompass all tools which have grep-like functionality while never stepping on the feet of other programs that may also require ignore files that may be different than the .grepignore.

ggreer 10y ago
The problem is that grep will never obey .grepignore. That's so confusing as to be a deal-breaker. Also, what about programs that have search functionality as part of their design, but not as their core function? For example, I don't want my text editor to search .min.js files. I'd even prefer it if such files didn't show up in my editor's sidebar. Do I have to add *.min.js to .searchignore and .atomignore? (Or if the editor people ever work out a standard, maybe it will be .editorignore.) If I had to draw a Venn diagram of ignore patterns in my text editors, my search tools, and my rsync scripts, they'd mostly overlap. I don't deny the need for application-specific ignores, but there is a large class of applications that could benefit from a more generic ignore file.
- ajsalminen 10y ago
  I do think it would be better to have the name at least reflect that class of applications, maybe "searchignore" like someone else suggested. There may be overlap but it's hard to predict all the types of applications people are using that need ignore functionality and something as simple as backing things up with rsync would seem like an example where someone could well want considerably different ignores.