| Age | Commit message (Collapse) | Author |
|---|
|
|
|
When we know we aren't going to process gitignores, we shouldn't waste
the syscall in every directory to check for a git repo.
|
|
Also alphabetise the list.
PR #1288
|
|
Issue #10 already states that "ripgrep is now in most or all of the major
package repositories."
PR #1280
|
|
This is necessary because jemalloc + musl + Ubuntu 16.04 is apparently
broken.
Moreover, jemalloc doesn't support i686, so we accept the performance
regression there.
See also: https://github.com/gnzlbg/jemallocator/issues/124
|
|
This brings in a bug fix that no longer tries to run `git` to update the
submodule if the `git` command doesn't exist.
This is useful is more restricted build contexts where `git` isn't
installed. Such as in the docker image used for running `cross`.
|
|
|
|
It turns out that musl's allocator is slow enough to cause a fairly
noticeable performance regression when ripgrep is built as a static
binary with musl. We fix this by using jemalloc when building with musl.
We continue to use the default system allocator in all other scenarios.
Namely, glibc's allocator doesn't noticeably regress performance compared
to jemalloc. But we could add more targets to this logic if other
system allocators (macOS, Windows) prove to be slow.
This wasn't necessary before because rustc recently stopped using jemalloc
by default.
Fixes #1268
|
|
In an effort to strip line terminators, we assumed their existence. But
a pattern file may not end with a line terminator, so we shouldn't
unconditionally strip them.
We fix this by moving to bstr's line handling, which does this for us
automatically.
|
|
This is for consistency with the short and long flags given in other
bullet points. I originally assumed there was no long flag for `-P`
because none was given here.
PR #1254
|
|
This feature solves a major reason I was skeptical of using ripgrep, so
I think it’s good to mention it in the section about why one should use
it.
I use backreferences a lot, so I had previously thought that ripgrep
would provide no speed advantage over ag, since I would always have
`-P` enabled. But when I saw `--auto-hybrid-regex` in the 11.0.0
changelog, I learned that ripgrep can use it to speed up simple queries
while still allowing me to write backreferences.
PR #1253
|
|
|
|
|
|
|
|
This brings in a fix for a regression introduced in ripgrep 11.
Fixes #1247
|
|
PR #1248
|
|
Add support for file types used by the GAP language, a research system
computational discrete algebra, see <https://www.gap-system.org>
PR #1249
|
|
The brew tap isn't really needed any more, since SIMD is now
automatically enabled in all binaries.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
There was a performance warning in the --pre docs, but didn't mention
--pre-glob as a possible mitigation to it.
|
|
|
|
|
|
Credit to @okdana for catching this. This naming is a bit more
consistent with the existing --max-columns flag.
|
|
|
|
I went through every commit since the 0.10.0 release and added anything
that I thought was missing.
|
|
- .jspx for XHTML JSP files
- .properties for Java Properties files (resource bundles, etc.)
Closes #1242
|
|
|
|
This flag, when set, will automatically dispatch to PCRE2 if the given
regex cannot be compiled by Rust's regex engine. If both engines fail to
compile the regex, then both errors are surfaced.
Closes #1155
|
|
|
|
|
|
The default stack size is 32KB, and this increases it to 10MB. 32KB is
pretty paltry in the environments in which ripgrep runs, and 10MB is
easily afforded as a maximum size. (The size limit we set for Rust's
regex engine is considerably larger.)
This was motivated due to the fack that JIT stack limits have been
observed to be hit in the wild:
https://github.com/Microsoft/vscode/issues/64606
|
|
This flag will output details about the version of PCRE2 that ripgrep
is using (if any).
|
|
This adds the top-level is_jit_available and version free functions from
the underlying pcre2 crate, and also forwards the max_jit_stack_size
option.
|
|
This comes with PCRE 10.32 and a few new options we'll use in subsequent
commits.
|
|
This flag is commonly used in pipelines and it can be annoying to write
it out every time you need it.
Ideally, we would use -h for this to match GNU grep, but -h is used to
print help output.
Closes #1185
|
|
This sets up the release announcement and briefly describes the
versioning change. The actual version change itself won't happen until
the release.
Closes #1172
|
|
Fixes #1189
|
|
This commit adds support for showing a preview of long lines. While the
default still remains as completely suppressing the entire line, this
new functionality will show the first N graphemes of a matching line,
including the number of matches that are suppressed.
This was unfortunately a fairly invasive change to the printer that
required a bit of refactoring. On the bright side, the single line
and multi-line coloring are now more unified than they were before.
Closes #1078
|
|
This commit attempts to surface binary filtering in a slightly more
user friendly way. Namely, before, ripgrep would silently stop
searching a file if it detected a NUL byte, even if it had previously
printed a match. This can lead to the user quite reasonably assuming
that there are no more matches, since a partial search is fairly
unintuitive. (ripgrep has this behavior by default because it really
wants to NOT search binary files at all, just like it doesn't search
gitignored or hidden files.)
With this commit, if a match has already been printed and ripgrep detects
a NUL byte, then it will print a warning message indicating that the search
stopped prematurely.
Moreover, this commit adds a new flag, --binary, which causes ripgrep to
stop filtering binary files, but in a way that still avoids dumping
binary data into terminals. That is, the --binary flag makes ripgrep
behave more like grep's default behavior.
For files explicitly specified in a search, e.g., `rg foo some-file`,
then no binary filtering is applied (just like no gitignore and no
hidden file filtering is applied). Instead, ripgrep behaves as if you
gave the --binary flag for all explicitly given files.
This was a fairly invasive change, and potentially increases the UX
complexity of ripgrep around binary files. (Before, there were two
binary modes, where as now there are three.) However, ripgrep is now a
bit louder with warning messages when binary file detection might
otherwise be hiding potential matches, so hopefully this is a net
improvement.
Finally, the `-uuu` convenience now maps to `--no-ignore --hidden
--binary`, since this is closer to the actualy intent of the
`--unrestricted` flag, i.e., to reduce ripgrep's smart filtering. As a
consequence, `rg -uuu foo` should now search roughly the same number of
bytes as `grep -r foo`, and `rg -uuua foo` should search roughly the
same number of bytes as `grep -ra foo`. (The "roughly" weasel word is
used because grep's and ripgrep's binary file detection might differ
somewhat---perhaps based on buffer sizes---which can impact exactly what
is and isn't searched.)
See the numerous tests in tests/binary.rs for intended behavior.
Fixes #306, Fixes #855
|
|
An alternate can be empty at this point, so we must handle it. We didn't
before because the regex engine actually disallows empty alternates,
however, this code runs before the regex compiler rejects the regex.
|
|
This includes:
*.dtd for Document Type Definitions
*.xsl and *.xslt for XSL Transformation descriptions
*.xsd for XML Schema definitions
*.xjb for JAXB bindings
*.rng for Relax NG files
*.sch for Schematron files
PR #1243
|
