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
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 <[email protected]>
0 commit comments