Use VirtualList for commits and file list

[mtsgrd]

Replace manual iteration with VirtualList in BranchCommitList and
FileList to improve performance with large lists. Create
ConfigurableVirtualList wrapper that applies user's scrollbar
visibility preference. Implement tree flattening for virtual scrolling
in tree mode with expand/collapse support.

• Add ConfigurableVirtualList component wrapping VirtualList with user
  settings
• Add flattenTree() to convert tree structure to flat list for virtual
  rendering
• Add max-height constraint to commit list container
• Remove transition from CommitRow to prevent scroll performance issues

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Preview	Comments	Updated (UTC)
gitbutler-web	Ignored	Preview		Nov 27, 2025 11:44am

[mtsgrd]

@PavelLaptev could you let me know what you think of this?

output.mp4

[PavelLaptev]

From a user experience perspective, this appears to be a regression.

• Scrolls within scrolls are confusing. Scrollbars that are always visible look cluttered. Scrollbars that are hidden make it hard to know you can scroll.
• Annoying and confusion scrolls. For example, if there's only one commit, it's frustrating to discover you need to scroll to see it.
• The commit list might have other sections like "Upstream commits" (see video), which makes scrolling more complicated.
• It’s difficult to use because one scroll accidentally overlaps with another and stumbles.
• We might change the design later. For instance, we could show not just commits but also file lists like we did in v2.

If we need to make other branches in the stack always visible, we can solve that problem in other ways.

cc @krlvi

Screen.Recording.2025-11-27.at.11.29.03.mov

[mtsgrd]

Just in short, the primary goal of this isn't to have branches always visible, but rather prevent against UI slowness if your branch happens to contain lots of commits, or your commit contains lots of changed files. What do you think we can do?

[krlvi]

From a user experience perspective, this appears to be a regression.

* Scrolls within scrolls are confusing. Scrollbars that are always visible look cluttered. Scrollbars that are hidden make it hard to know you can scroll.

* Annoying and confusion scrolls. For example, if there's only one commit, it's frustrating to discover you need to scroll to see it.

* The commit list might have other sections like "Upstream commits" (see video), which makes scrolling more complicated.

* It’s difficult to use because one scroll accidentally overlaps with another and stumbles.

* We might change the design later. For instance, we could show not just commits but also file lists like we did in v2.

If we need to make other branches in the stack always visible, we can solve that problem in other ways.

cc @krlvi
Screen.Recording.2025-11-27.at.11.29.03.mov

I don't have much to add, @PavelLaptev but this seems like a sound judgement re: scroll within a scroll and the other UX aspects

[krlvi]

Throwing a crazy idea: is "show more" thingie appropriate if there are more than say... 50 commits or something? No idea if this is right at all

[PavelLaptev]

Just in short, the primary goal of this isn't to have branches always visible, but rather prevent against UI slowness if your branch happens to contain lots of commits, or your commit contains lots of changed files. What do you think we can do?

Let’s load commits within the lane scroll, rather than within each branch. This approach would be ideal.

[PavelLaptev]

@mtsgrd, let’s keep the “scroll to bottom” button only for the chat. It doesn’t make sense to have it in other places where the list isn’t fully loaded.

[PavelLaptev]

Another important issue is the inability to drag and drop files and commits.

Screen.Recording.2025-11-27.at.12.54.22.mov

[mtsgrd]

Let’s load commits within the lane scroll, rather than within each branch. This approach would be ideal.

Let me see what I can do!

[PavelLaptev]

Throwing a crazy idea: is "show more" thingie appropriate if there are more than say... 50 commits or something? No idea if this is right at all

That could work. It’s better than scrolling. However, let’s not implement it within this PR. Instead, let’s make design drafts first.

[PavelLaptev]

Let’s load commits within the lane scroll, rather than within each branch. This approach would be ideal.

Let me see what I can do!

If you’re okay with not rushing virtual lists within lanes, we can try an idea that @krlvi added (if it's easier to implement). Then, we can make another PR.

[Byron]

(converted to draft as I somehow felt the urge to press this juice green merge button😅. On the topic: I am very excited for this!)