Fix delay with flicking through files or commits when git diff is very slow #4803
Conversation
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
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
|
stefanhaller
force-pushed
the
improve-ui-lag-for-very-slow-git-diff-commands
branch
from
cde15d5 to
2a1fb18
Compare
No need to do a runtime check if we already have the platform-specific files.
…y slow One reason why git diff can be very slow is when "diff.algorithm = histogram" is being used. In this case, showing a very long single-file diff can take seconds to load, and you'll see the "loading..." message in the main view until we got the first lines of the diff to show. There's nothing really we can do about this delay; however, when switching to another, shorter file (or commit) while the "loading..." message is still showing, this switch should be instantaneous. And it was before 0.54.0, but we broke this in 0.54.0 with 8d7740a (#4782); now users have to wait for the slow git diff command to output more text before the switch occurs. To fix this, don't block waiting for the process to terminate if we just stopped it.
The previous commit already fixed the user-visible lag, but there's still a problem with multiple background git processes consuming resources calculating diffs that we are never going to show. Improve this by terminating those processes (by sending them a TERM signal). Unfortunately this is only possible on Linux and Mac, so Windows users will have to live with the higher CPU usage. The recommended workaround is to not use "diff.algorithm = histogram".
stefanhaller
force-pushed
the
improve-ui-lag-for-very-slow-git-diff-commands
branch
from
2a1fb18 to
e056e33
Compare
stefanhaller
deleted the
improve-ui-lag-for-very-slow-git-diff-commands
branch
tmeijn
pushed a commit
to tmeijn/dotfiles
that referenced
this pull request
Aug 12, 2025
This MR contains the following updates: | Package | Update | Change | |---|---|---| | [jesseduffield/lazygit](https://github.com/jesseduffield/lazygit) | patch | `v0.54.1` -> `v0.54.2` | MR created with the help of [el-capitano/tools/renovate-bot](https://gitlab.com/el-capitano/tools/renovate-bot). **Proposed changes to behavior should be submitted there as MRs.** --- ### Release Notes <details> <summary>jesseduffield/lazygit (jesseduffield/lazygit)</summary> ### [`v0.54.2`](https://github.com/jesseduffield/lazygit/releases/tag/v0.54.2) [Compare Source](jesseduffield/lazygit@v0.54.1...v0.54.2) <!-- Release notes generated using configuration in .github/release.yml at v0.54.2 --> Here's another point release; this one fixes a performance regression in 0.54.0 that made flicking through diffs a little less snappy (or a lot less, in some scenarios) than it could be. For the changes in 0.54.0, see https://github.com/jesseduffield/lazygit/releases/tag/v0.54.0. #### What's Changed ##### Fixes 🔧 - Fix scrollbar in certain popup panels (e.g. the intro message for new users) by [@​stefanhaller](https://github.com/stefanhaller) in jesseduffield/lazygit#4804 - Fix delay with flicking through files or commits when git diff is very slow by [@​stefanhaller](https://github.com/stefanhaller) in jesseduffield/lazygit#4803 ##### Maintenance ⚙️ - Stop bumping our homebrew formula by [@​stefanhaller](https://github.com/stefanhaller) in jesseduffield/lazygit#4799 - Update the badges of golangci-lint and homebrew in `README.md` by [@​kyu08](https://github.com/kyu08) in jesseduffield/lazygit#4807 ##### Docs 📖 - Fix the useHunkModeInStagingView hint in the breaking changes message by [@​stefanhaller](https://github.com/stefanhaller) in jesseduffield/lazygit#4800 - Update `CONTRIBUTING.md` to clarify translation contribution process by [@​kyu08](https://github.com/kyu08) in jesseduffield/lazygit#4806 **Full Changelog**: jesseduffield/lazygit@v0.54.1...v0.54.2 </details> --- ### Configuration 📅 **Schedule**: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined). 🚦 **Automerge**: Enabled. ♻ **Rebasing**: Whenever MR is behind base branch, or you tick the rebase/retry checkbox. 🔕 **Ignore**: Close this MR and you won't be reminded about this update again. --- - [ ] <!-- rebase-check -->If you want to rebase/retry this MR, check this box --- This MR has been generated by [Renovate Bot](https://github.com/renovatebot/renovate). <!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiI0MS42MS4xIiwidXBkYXRlZEluVmVyIjoiNDEuNjEuMSIsInRhcmdldEJyYW5jaCI6Im1haW4iLCJsYWJlbHMiOlsiUmVub3ZhdGUgQm90Il19-->
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
One reason why git diff can be very slow is when "diff.algorithm = histogram" is being used. In this case, showing a very long single-file diff can take seconds to load, and you'll see the "loading..." message in the main view until we got the first lines of the diff to show. There's nothing really we can do about this delay; however, when switching to another, shorter file (or commit) while the "loading..." message is still showing, this switch should be instantaneous. And it was before 0.54.0, but we broke this in 0.54.0 with 8d7740a (#4782); now users have to wait for the slow git diff command to output more text before the switch occurs. To fix this, don't block waiting for the process to terminate if we just stopped it.
In addition, improve CPU usage by terminating git processes gracefully (by sending them a TERM signal); this helps keep CPU usage low when flicking through several of these huge diffs with "diff.algorithm = histogram", because it avoids having several git processes running in the background, calculating expensive diffs that we are never going to show. Unfortunately this is only possible on Linux and Mac, so Windows users will have to live with the higher CPU usage. The recommended workaround is to not use "diff.algorithm = histogram".
Fixes #4798.