mirror of
https://github.com/jesseduffield/lazygit.git
synced 2026-09-10 07:36:27 -04:00
2ed887d149
The existing git log logic fetched the first 300 commits of a repo and displayed them in the local and sub-commit views. Once a user selected a commit beyond a threshold of 200 commits the whole repository was loaded. This is problematic with large repos e.g. the linux kernel with currently ~138k commits as lazygit slows down substantially with such a large number of commits in memory. This commit replaces the current all or only the first 300 commits logic with an incremental fetching approach: 1. The first 400 commits of repo are loaded by default. 2. If the user selects a commit beyond a threshold (current limit-100) the git log limit is increased by 400 if there are more commits available. If there are more commits available is currently checked by comparing the previous log limit with the real commit count in the model, if the commit count is less then the limit it is assumed that we reached the end of the commit log. Ideally it would be better to call `git rev-list --count xyz` in the right places and compare with this result, but this requires more changes. Adding a "paginated implementation" by utilizing `git log --skip=x --max-count=y` and appending commits to the model instead of replacing the whole collection would be nice, but this requires deeper changes to keep everything consistent. Signed-off-by: Stefan Kerkmann <s.kerkmann@pengutronix.de> Co-authored-by: DeepSeek V4 Flash |
||
|---|---|---|
| .. | ||
| direnv | ||
| git_commands | ||
| git_config | ||
| hosting_service | ||
| models | ||
| oscommands | ||
| patch | ||
| testdata | ||
| git.go | ||
| git_cmd_obj_builder.go | ||
| git_cmd_obj_builder_test.go | ||
| git_cmd_obj_runner.go | ||
| git_cmd_obj_runner_test.go | ||