Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"git commit --amend" scans entire working directory if no files are staged #129

Open
steadmon opened this issue Jul 1, 2019 · 1 comment · Fixed by aws-lumberyard/git-secrets#1 · May be fixed by #130
Open

"git commit --amend" scans entire working directory if no files are staged #129

steadmon opened this issue Jul 1, 2019 · 1 comment · Fixed by aws-lumberyard/git-secrets#1 · May be fixed by #130

Comments

@steadmon
Copy link

steadmon commented Jul 1, 2019

When "git commit --amend" is used when no files are staged (for example, to reword a commit message), git-secrets --pre_commit_hook scans the entire working tree. This is because the scan() function is called with an empty file list.

For large repos, this causes a bad user experience; the user expects their editor to open immediately, but instead the pre-commit hook runs for multiple seconds (9 seconds in the linux kernel on my workstation), with no progress indication. If the repo contains any previously committed files that match git-secrets patterns, the editor never opens, and git-secrets' error message is displayed.

We can make the pre_commit_hook() function return immediately if there are no changed files, which should match user expectations.

steadmon added a commit to steadmon/git-secrets that referenced this issue Jul 1, 2019
When "git commit --amend" is used when no files are staged (for example,
to reword a commit message), git-secrets --pre_commit_hook scans the
entire working tree. This is because the scan() function is called with
an empty file list.

For large repos, this causes a bad user experience; the user expects
their editor to open immediately, but instead the pre-commit hook runs
for multiple seconds (9 seconds in the linux kernel on my workstation),
with no progress indication. If the repo contains any previously
committed files that match git-secrets patterns, the editor never opens,
and git-secrets' error message is displayed.

We can make the pre_commit_hook() function return immediately if there
are no changed files, which should match user expectations.

Closes awslabs#129
@steadmon steadmon linked a pull request Jul 1, 2019 that will close this issue
@ujihisa
Copy link

ujihisa commented Dec 16, 2020

Looks like the same thing happens when you are removing files using git rm filename but not adding files.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants