Skip to content

Conversation

KarlK90
Copy link

@KarlK90 KarlK90 commented Sep 18, 2025

PR Description

Limit the number of (pre-)rendered pipesets which are visible when rendering a git graph to the actual currently visible number of commits. This is important for large repositories with a large number of commits when scrolling past the first 200 commits, which currently triggers a load of the complete commit history1. If this happens and the git graph rendering is enabled a potentially large number of pipes (~138k for the linux kernel) is allocated.

Please check if the PR fulfills these requirements

  • Cheatsheets are up-to-date (run go generate ./...)
  • Code has been formatted (see here)
  • Tests have been added/updated (see here for the integration test guide)
  • Text is internationalised (see here)
  • If a new UserConfig entry was added, make sure it can be hot-reloaded (see here)
  • Docs have been updated if necessary
  • You've read through your own file changes for silly mistakes etc

Limit the number of (pre-)rendered pipesets which are visible when
rendering a git graph to the actual currently visible number of commits.
This is important for large repositories with a large number of commits
when scrolling past the first 200 commits, which currently triggers a
load of the complete commit history[1]. If this happens and the git
graph rendering is enabled a potentially large number of pipes (~138k
for the linux kernel) is allocated.

[1]: https://github.com/jesseduffield/lazygit/blob/d56a9cf73e6a34550e42d2627c011c4b73e5a975/pkg/gui/controllers/local_commits_controller.go#L1265

Signed-off-by: Stefan Kerkmann <[email protected]>
@stefanhaller
Copy link
Collaborator

stefanhaller commented Sep 21, 2025

This makes memory usage much worse. The pipe set cache stores pipe sets based on commit hash plus number of commits, so as you move the selection around, you will end up with tons of duplicates of the pipe set data in the cache. And that data needs to be recalculated all the time as you scroll down, which makes navigating the list super sluggish once you scroll down enough.

I know that we have huge problems with memory usage and performance in large repos, but this is not a way to improve this I'm afraid.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants