here is preview :

@Hari-Oggy Thanks for the PR!

@extrawurst @naseschwarz I’m wondering whether we should go for the manual solution presented in this PR or rather for an automatic one that doesn’t require manual intervention, but would make customization impossible. What do you think?

@extrawurst @naseschwarz Friendly ping: what do you think about whether the left column’s width should be resized automatically by gitui vs. fully controlled by the user?

In this PR, GitUI automatically manages the left column's width while still allowing users to manually adjust both width and height. This approach provides a responsive layout with user customization options.

The preview shows two versions:

• Left side: Standard GitUI with automatic left column width
• Right side: Same layout with added user width customization options

an automatic one that doesn’t require manual intervention, but would make customization impossible. What do you think?

@cruessler what automated solution would that be?

@extrawurst Sorry for the long delay!

I was thinking of responsive web design where the layout is completely determined by CSS or of tiling window managers that arrange windows automatically according to the space available.

I think there might be different use cases here that made me hesitate:

• People who always use gitui at the same size. In these situations, I imagine it makes a lot of sense to give users the option to resize splits manually.
• People who use terminal multiplexers such as tmux or zellij and open gitui at more than one size. In these situations, it’s less clear to me that manual resizing is the optimal solution as the same percentages can look perfectly fine at one size, but less so at others.

I admit that this might not be the strongest argument for completely automatic layout. If you think it’s a good idea to provide the manual level of control proposed in this PR, I’m happy to start the actual review!

If I might chime in...

• Resizing top-left area to be larger than content and +1 line/column probably doesn't make sense as this already conveys "that's all we've got, no more content to show".

• As one of those "people who use terminal multiplexers", I can see situations where staged and unstaged changes compete for vertical space. In such situations manual resize of the horizontal split between them and vertical scrollbar in each would make a lot of sense.

EDIT

Builds on top of master, seems to work fine :)

Small issue: Up/Down arrows are reversed. E.g. Alt+down with "Unstaged changes" in focus increases size of the "Staged changes".

Another little issue: On the Log [2] tab, Alt+left/right does nothing when the leftmost column (Commit) is in focus.

@savchenko Thanks for catching these! Both issues have been fixed — Alt+Up/Down now resize the correct section, and Alt+Left/Right works properly in the Commit column.

This PR was opened before ratatui-hypertile existed (Oct 2025), so I implemented the resizing manually.

Since GitUI already has its own keybinding and action system, I kept it consistent with that instead of introducing a new dependency. Also, this change is limited to resizing a fixed set of panels, so a simple local implementation felt sufficient.

Happy to revisit this if you think using ratatui-hypertile would be a better fit.

@Hari-Oggy Thanks for the explanation, and that makes sense, both historically and in the context of the code base. I just happened to have run across the hypertile widget shortly before ending up here doing reviews — and incidentally having my own project that needs something similar, so I was evaluating approaches. Even if perhaps moving to hypertile down the road might make sense I do think starting out this way with something that addresses the need as directly and simply as possible is probably a good way to start.

Would the next logical step be to make sure this same change gets evenly applied to other similar pane scenarios, e.g. obsoleting the manual adjustment in #2772?