This repository was archived by the owner on Sep 11, 2020. It is now read-only.
WIP: Improves gitignore performance & adds (future) option for force-commit of gitignored files #446
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR contains #444 and builds upon it.
Changed to WIP: testing on a collection of large repositories with nested .gitignore some inconsistencies have been identified
The problem: having gitignore matcher acting in the worktree on the diffs results in traversing over potentially massive trees of file names of directories which are fully excluded (think e.g. of a
vendor/
gitignore record for Go modules). This is noticeably slow.Solution: Unless forcing an ignored file into the commit, one could exclude these files at the file system level in the noder (as originally suggested), so the noder would not dive into the directory at all and save uncovering and then removing thousands of files. This PR combines the two approaches: if force disabled, then files are ignored at the file system level, if force is enabled, file system delivers the full tree and files are ignored in the diff, however those marked M or D in the worktree are forced through, along with all in staging. The point here was not to implement the force, but to speed up the normal case, and force comes as an added value, albeit not integrated into Status or Commit. Currently it is just a var flag set to false and only reset to true in the test to demo that force would work this way if added to Status and Commit.