You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am using git to keep track of my configuration files in a 'dotfiles' repository. In my case my home folder is a git repository on its own and the git configuration for this is configured with status.showuntrackedfiles=no. Obviously the home folder contains quite a large amount of files and git-crypt status tries to show a status for each of it which results in the status being quite unusable.
Wouldn't it be useful if git-crypt status also (maybe even optionally) respects the configuration accordingly or even only cares about tracked files at all? I currently don't see why someone would care in the status about untracked files, but maybe I am missing something here.
The text was updated successfully, but these errors were encountered:
From the code I see that git-crypt status calls git ls-tree to get a list of files. For this operation the parameters -cotsz are used, with the -o causing ls-files to "show other (i.e. untracked) files in the output" (which is the description from the help page).
Here -ctsz should be enough to show all tracked files (including staged files). A manual test of calling git ls-tree -ctsz seems to work as expected on a first try.
Sadly I don't see any development going on here anymore, so unless AGWA hands over the project or someone creates a fork and continues to maintain it, I don't see that happen.
I am using git to keep track of my configuration files in a 'dotfiles' repository. In my case my home folder is a git repository on its own and the git configuration for this is configured with
status.showuntrackedfiles=no
. Obviously the home folder contains quite a large amount of files andgit-crypt status
tries to show a status for each of it which results in the status being quite unusable.Wouldn't it be useful if
git-crypt status
also (maybe even optionally) respects the configuration accordingly or even only cares about tracked files at all? I currently don't see why someone would care in the status about untracked files, but maybe I am missing something here.The text was updated successfully, but these errors were encountered: