Agignore not using the same patterns as gitignore

[pablox-cl]

Ok, here's the issue:

# gitignore as used by github/gitignore/Rails.gitignore
/vendor/bundle

$ ag treetop
vendor/bundle/gems/rack-livereload-0.3.15/gemfiles/rails32.gemfile.lock
81:      treetop (~> 1.4.8)
$ git ls-files | ag treetop
$ # empty result

# gitignore
vendor/bundle/

$ ag treetop
Gemfile.lock
86:      treetop (~> 1.4.8)
$ git ls-files | ag treetop
$ # empty result

So this means, ag and git are interpreting different a directive, that at least to gitignore it's the same (so it seems, I don't use leading slashes and I believe I haven't had any drawbacks). According to git documentation:

A leading slash matches the beginning of the pathname. For example, "/*.c" matches "cat-file.c" but not "mozilla-sha1/sha1.c".

I don't know how ag interprets leading slashes, but clearly they do different.

---

It seems that:

/vendor/bundle
vendor/bundle/

It's the same for git, they don't have trouble tracking files inside, like public/vendor/bundle/a_file.txt.

[nubs]

What version of ag are you using? This appears to be fixed in master.

[jameswomack]

I've ag version 0.21.0 installed via Homebrew and I experience this issue.

[ggreer]

Please try the latest version of ag: 0.22.0

[jameswomack]

@ggreer Thank you. 0.22.0 seems to work.

[jameswomack]

...as long as the folders are prefixed by /

[pablox-cl]

Now I'm using 0.23.0, and works fine with .gitignore, when having leading slashes, but now it doesn't when they don't have (the opposite).

[jameswomack]

@pablox-cl Same here.

[chibicode]

Same issue here on 0.23.0

[iizukanao]

A simple workaround for the current version: just put the leading slash.

[pablox-cl]

Using 0.26.0, I'm still finding the same issue, ag doesn't seem to respect .gitignore.
Sorry, the issue it has to do with ctrlp or vim, but not ag.

[brandon-rhodes]

Under 0.29.1 I can confirm that ag seems to be working correctly, and that a pattern with slashes in it still applies whether or not it has a leading slash. So it is likely that this issue can now be closed! Thanks for getting this fixed.