Improve performance of discarding many files#5407
Open
stefanhaller wants to merge 8 commits intomasterfrom
Open
Improve performance of discarding many files#5407stefanhaller wants to merge 8 commits intomasterfrom
stefanhaller wants to merge 8 commits intomasterfrom
Conversation
This makes it mockable for tests, and is consistent with other uses in this file.
Previously it would only check that *if* removeFile was called, the passed argument was the expected one; but it didn't check whether it was called at all. Improve this by recording the file names that are removed, and checking them at the end of each scenario. This is going to be even more important for the tests that we are about to add in the next commit, because for those there can be several calls to removeFile in a single scenario.
We have integration tests for this functionality, but those only test the behavior, not the performance. In these unit tests you can see that we make individual calls to git checkout and git reset for each file, which is very slow when there are lots of files.
When discarding a directory, we only want to discard those files that are visible in the current filter view. The tests show that this already works correctly for discarding all changes, but it doesn't for discarding only unstaged changes: in this case, untracked files are handled correctly, but changes to tracked files are discarded without respecting the filter.
Useful when we need to call git with potentially tons of arguments that might exceed the OS' command-line length limit.
Previously it would iterate over all changed files and call git checkout or git reset for each one, which can take forever if there are hundreds or thousands of files. Now it batches these into a single command if possible (taking care of still passing the individual path names to the git call rather than just the directory, which is necessary for making it work correctly when filtering -- this was actually broken for the "Discard unstaged changes" command, which is fixed here).
This is probably the less severe case, but it could still be an issue for people who have many modified top-level files they want to discard, and have showRootItemInFileTree set to false; they could select all those files by pressing 'v' and '>'.
Coverage summary from CodacySee diff coverage on Codacy
Coverage variation details
Coverage variation is the difference between the coverage for the head and common ancestor commits of the pull request branch: Diff coverage details
Diff coverage is the percentage of lines that are covered by tests out of the coverable lines that the pull request added or modified: See your quality gate settings Change summary preferencesFootnotes
|
6 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
When selecting a directory containing many changed files, or when range-selecting many changed files, and then discarding them, this could be so slow that lazygit appeared to hang; especially since there was no UI feedback (e.g. a spinning status message).
This PR improves the performance greatly by batching the individual git calls into a single one if possible. It still doesn't add UI feedback though, hoping that the operation is now fast enough that it isn't needed.
While we're at it, we fix a bug that would cause "Discard unstaged changes" to discard more than just the visible files when filtering by path.
Fixes #4581.