mirror of
https://github.com/jesseduffield/lazygit.git
synced 2026-09-10 07:36:27 -04:00
f8b7bab1ab
Whether a graph can be drawn was read from the filtering mode, while the graph itself is drawn over the commit list in the model. Those two only agree once the list has been reloaded for the new mode, and a filtering mode change reloads the list in the background, so in between we can be asked to draw a graph over a list the graph makes no sense for. That is not just cosmetic. Commits in a filtered list are almost never each other's parents, so no pipe ever terminates: the pipe set grows by one per row and every continuing pipe rescans it, which is cubic in the length of the list. Escaping out of filtering mode with a filtered list of 13000 commits — as you get once the 300 commit limit has been lifted, which happens for good as soon as the selection passes COMMIT_THRESHOLD — wedges the UI thread for around twenty minutes. Record whether the list was loaded with a filter, right where the list itself is stored, and decide from that. The graph now also stays up while the pre-change list is still on display, rather than vanishing a moment before the list it belongs to. |
||
|---|---|---|
| .. | ||
| common.go | ||
| common_commands.go | ||
| context.go | ||
| keybindings.go | ||
| modes.go | ||
| ref_range.go | ||
| refresh.go | ||
| rendering.go | ||
| search_state.go | ||
| suggestion.go | ||
| version_number.go | ||
| version_number_test.go | ||
| views.go | ||