Package Details: ripgrep-git 11.0.1.r8.5ce2d73-1

Git Clone URL: https://aur.archlinux.org/ripgrep-git.git (read-only)
Package Base: ripgrep-git
Description: A search tool that combines the usability of The Silver Searcher with the raw speed of grep.
Upstream URL: https://github.com/BurntSushi/ripgrep
Licenses: MIT, Unlicense
Conflicts: ripgrep
Provides: ripgrep
Submitter: sigma
Maintainer: sigma (burntsushi)
Last Packager: sigma
Votes: 10
Popularity: 0.000286
First Submitted: 2016-09-24 00:05
Last Updated: 2019-05-14 09:31

Dependencies (5)

Required by (5)

Sources (1)

Latest Comments

SolarAquarion commented on 2019-05-10 13:28

ripgrep should probably have fish as a optdepend for completions

ronjouch commented on 2019-04-13 01:09

Since today and https://github.com/fish-shell/fish-shell/commit/5989a92dae3dcbed3f868345811ab178f04bf3c8 , build of fish-git succeeds but installation fails with:

error: failed to commit transaction (conflicting files)
fish-git: /usr/share/fish/completions/rg.fish exists in filesystem (owned by ripgrep)

What's the standard in Arch? Should fish or ripgrep provide the completions? Asked the same question in AUR / fish-git ( https://aur.archlinux.org/packages/fish-git/#news )

tei8ho commented on 2018-09-16 17:06

I assume this on me, but I get zsh completions but not bash ones.

==> Entering fakeroot environment...

==> Starting package()...

install: target '/home/USERNAME/Code/makepkg/build/ripgrep-git/pkg/ripgrep-git/usr/share/bash-completion/completions/rg' is not a directory

==> ERROR: A failure occurred in package(). Aborting...

warning: package ripgrep-git failed to build, skipping

[USERNAME@LAPTOP ripgrep]$ ls ~/Code/makepkg/build/ripgrep-git/pkg/ripgrep-git/usr/share/zsh/site-functions/

berquist commented on 2018-04-01 00:18

I was having trouble installing because the find call for the manpage was returning multiple hits. It's crude, but this solved it:

install -Dm644 $(find "$srcdir/$pkgname"/target/release/build -name "rg.1" | head -n 1) "$pkgdir/usr/share/man/man1/rg.1"

mrkline commented on 2017-01-23 18:58

Thanks for fixing things up so quickly! Unfortunately, I think a few more tweaks need to be made.

First, you grab the latest tag with
git tag | grep -v "^[a-zA-Z]" | tail -n1
but unless I'm mistaken, `git tag` prints tags in lexicographic order by default. (So, some future 0.4.10 release would be listed before 0.4.2). Based on http://stackoverflow.com/a/29601177, I believe we want something along the lines of:

git tag --sort=-v:refname | grep '^[0-9]' | head -1

Also, according to the VCS packaging guidelines, I believe we want a version string resembling:
<last tagged version>.r<commits since tag>.<SHA of HEAD>

But the current pkgver() gives
<last tagged version>.r0.<SHA of the last tagged version>

I believe a pkgver that gives the desired output resembles the following:

pkgver() {
local tag=$(git tag --sort=-v:refname | grep '^[0-9]' | head -1)
local commits_since=$(git rev-list $tag..HEAD --count)
echo "$tag.r$commits_since.$(git log --pretty=format:'%h' -n 1)"
}

Thanks again!

mrkline commented on 2017-01-21 20:54

After a bit more digging, the problems might be that the latest tag (wincolor-0.1.2-6) has a smaller version number than the one in the PKGBUILD (0.1.17.2). At least, that's the impression I get from cower:

$ cower -u
:: ripgrep-git wincolor.0.1.2.6.rb678862-1 -> 0.1.17.2.rf5eb36b-1

I assume the tags "wincolor-0.1.2", "ignore-0.1.6", etc. just pertain to dependencies, but could pkgver() in the PKGBUILD be adjusted accordingly?

mrkline commented on 2017-01-20 21:58

For some reason, pacaur attempts to rebuild this package every time I run `pacaur -Syu`, even without `--devel`. This suddenly started happening in the last few days - does anybody have any idea what might cause it?

I did notice that the version "number" now starts with `wincolor`, e.g., `ripgrep-git-wincolor.0.1.2.4.r7a926d0-1`. Could something be off about how `pkgver()` works in the PKGBUILD, compared to other dev packages?