Closed stephenyeargin closed 5 years ago
It's worth noting that if you don't have any patterns defined, the commit works without issue.
Looks like @t13a may have some work that could fix this? Looks like it touches the relevant code.
https://github.com/awslabs/git-secrets/compare/master...t13a:feature/fix-scan-files
I'm having the same issue. Just out of interest, what bash version are you on? #45 was meant to fix this error for bash version 4 but I'm still having the same problems.
I'm using the latest homebrew
installed version.
$ which bash
/usr/local/bin/bash
$ bash --version
GNU bash, version 4.4.19(1)-release (x86_64-apple-darwin17.3.0)
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Did confirm this is still an issue.
@mtdowling - Is there any progress with this issue? I'm just wondering as I've run into it myself.
Happens in my machine as well.
Running GNU bash, version 4.4.12(1)-release (x86_64-apple-darwin16.3.0)
Git Secrets installed via Homebrew git-secrets: stable 1.2.1 (bottled), HEAD
Committing a single file (with aws secret) will result in the warning. Committing multiple files that one of them includes the aws secret will produce the error above.
Using make install
to install the package from source will give the illusion of fixing the error.
When committing multiple files (using the make install method), git-secrets will not recognise the AWS secret that exists in one of them.
I'm not sure what's going on here, but I got exactly this error when executing git commit
:
fatal: ambiguous argument '<snip>': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'
So finally I figure out it's the pre-commit hook, and add a set -x
to which git-secrets
. The offending line turns out to be:
GREP_OPTIONS= LC_ALL=C git grep -nwHEI ${options} "${combined_patterns}" $files
This is because I installed it via homebrew as recommended in the README. That gets you version 1.2.1, released on Jun 27, 2016 (!).
PR #54 seems to have fixed this by adding --
to git grep
, although there is still an instance of this command without --
(line 105). Using brew install --HEAD git-secrets
installs the latest version, so I did that.
With regards to the previous comment, whether or not this fixes it, I don't know. What I do know is now I can finally commit stuff again, after spending a good hour debugging why git commit
was broken, which is pretty bad, along with finding out that the last release was two years ago.
If it is fixed in the build version, it sounds like the path forward is:
Anyone for tagging a new version? 😊 That would be really helpful for updating the formula in Homebrew. The workaround given by @tobywf will work in the meantime:
brew install git-secrets --HEAD
@mtdowling Can you tag a new release from master
when you get a moment?
I'm running into this problem as well. Would be nice to get a new version tag, so that brew
can update.
Sorry for the delay. I just tagged 1.3.0.
We're good to go in Homebrew. 🎉
$ brew info git-secrets
git-secrets: stable 1.3.0 (bottled), HEAD
Prevents you from committing sensitive information to a git repo
https://github.com/awslabs/git-secrets
/usr/local/Cellar/git-secrets/1.3.0 (8 files, 65.7KB) *
Poured from bottle on 2019-02-12 at 09:58:51
From: https://github.com/Homebrew/homebrew-core/blob/master/Formula/git-secrets.rb
==> Options
--HEAD
Install HEAD version
==> Analytics
install: 828 (30 days), 2,016 (90 days), 6,453 (365 days)
install_on_request: 805 (30 days), 1,991 (90 days), 6,403 (365 days)
build_error: 0 (30 days)
Splitting this out from #32 for easier discovery and to perhaps highlight the need for a fix or workaround.
My versions:
macOS 10.13.3 (17D47)
git-secrets 1.2.1
grep (BSD grep) 2.5.1-FreeBSD
git version 2.16.1
hub version 2.2.9