fix-issue-12328: fix commit messages truncation in the CLI

[gonchihernandez]

🎫 Affected issues

Fixes: #12328

🧢 Changes

• Replaced hard-coded 50-character commit message truncation with terminal-width-aware truncation in but status
• Added truncate_text() helper that appends … when text is truncated
• Added terminal_width() helper (reusing the existing terminal_size crate dependency).
• Fixed three truncation sites in crates/but/src/command/legacy/status/mod.rs:
  • Commit messages (CommitMessage::display_cli): was .take(50), now uses terminal_width() - 15
  • PR titles (ForgeReview::display_cli): was .take(50), now uses terminal_width() - 25.
  • Common merge base message: was .take(40), now uses terminal_width() - 40
• All truncation sites now show … when text is shortened, instead of silently cutting off
• Fixed a bug in ForgeReview::display_cli where trim_end_matches would strip the … suffix — moved the trim to run on the raw title before truncation
• Added 7 unit tests for the truncate_text helper inline, following the project convention of keeping unit tests for private functions in-module

☕️ Reasoning

Commit messages longer than 50 characters were silently truncated in but status regardless of terminal width. For example, on a 120-column terminal:

Before:

┊●   d7959c7 this is a overly long commit message to demonstrat

After:

┊●   d7959c7 this is a overly long commit message to demonstrate truncation in the CLI status o…

The truncation limit now adapts to the actual terminal width, and whenever truncation occurs, an … character clearly indicates that the message continues. This follows the same patterns already used in crates/but/src/tui/table.rs and crates/but/src/command/help.rs.

🧪 Manual testing

1. Build the CLI: cargo build -p but
2. Create a test repository:

   mkdir ~/but-truncation-test && cd ~/but-truncation-test
   git init && git commit --allow-empty -m "initial commit"

3. Set up GitButler: but setup
4. Create a commit with a long message:

   echo "test" > test.txt
   but commit -m "this is a overly long commit message to demonstrate truncation in the CLI status output display"

5. Run but status on a wide terminal (~120 cols) → full message should be visible.
6. Run but status on a narrow terminal (~60 cols) → message should be truncated with ….
7. Run but status with a short commit message → no truncation, no ….
8. Verify the common base line (the ┴ line) also truncates with … on narrow terminals.
9. Cleanup: rm -rf ~/but-truncation-test

🔭 Improvements (out of scope for this PR) changes made in this commit

Shared text truncation — tui::text

Same "detect terminal width and shorten text" logic was in five places.
Now it's in one: crates/but/src/tui/text.rs.

Also fixed a panic in help.rs (byte-slicing non-ASCII) and wrong width
measurements in oplog.rs/pick.rs (char count vs display columns).

🎬 Demo

Before:

After:

[vercel]

@gonchihernandez is attempting to deploy a commit to the GitButler Team on Vercel.

A member of the Team first needs to authorize it.

[Copilot]

Pull request overview

Updates the legacy but status CLI rendering to truncate commit messages, PR titles, and the common-base line based on detected terminal width (with an ellipsis suffix), instead of using fixed .take(N) limits.

Changes:

• Added terminal_width() (80-col fallback) and truncate_text() (adds … on truncation).
• Replaced fixed-length truncation for commit messages, PR titles, and common merge base message with terminal-width-based truncation.
• Added in-module unit tests covering truncate_text() behavior.

[Byron]

Thanks a lot for making your first contribution!

What I like is that there are before/after screenshots, that's very helpful.
The PR description is too wordy to me and if I suspect it's waltzed out by AI I am not going to read it. This makes me wonder if I am missing anything by not reading "Possible Improvements", but for now let me assume that you will suggest follow-ups based on what you feel is needed.

Lastly, I truly think that the estimations have to be turned into knowledge for precise numbers for how much of the line is left for the comment.

Thanks again for making commit message handling 🙏.

PS: For commits, we use message(#issue-number)

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 2 comments.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 3 comments.

[gonchihernandez]

Thanks a lot for making your first contribution!

What I like is that there are before/after screenshots, that's very helpful. The PR description is too wordy to me and if I suspect it's waltzed out by AI I am not going to read it. This makes me wonder if I am missing anything by not reading "Possible Improvements", but for now let me assume that you will suggest follow-ups based on what you feel is needed.

Lastly, I truly think that the estimations have to be turned into knowledge for precise numbers for how much of the line is left for the comment.

Thanks again for making commit message handling 🙏.

PS: For commits, we use message(#issue-number)

Thanks a lot for the response and the guidance! I did a commit amend to use the message(#number-issue) and did the respective changes!

While working on this I noticed we now have three places doing terminal width + truncation — truncate_string() in tui/table.rs, an inline closure in help.rs, and this new truncate_text(). I think it might be worth pulling them into a shared util so we stop reinventing it.
Happy to do that as a follow up if you agree...

Thanks again for the review! I am happy :)

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 2 comments.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 6 comments.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 1 comment.

[Copilot]

Pull request overview

Copilot reviewed 7 out of 7 changed files in this pull request and generated 1 comment.

Comments suppressed due to low confidence (2)

crates/but/src/command/legacy/status/mod.rs:1096

• There are multiple trailing blank lines at the end of the file; this tends to get reverted by rustfmt and creates noisy diffs. Consider trimming the file to a single newline at EOF.
  crates/but/src/tui/table.rs:211
• There are a couple of extra blank lines at the end of this module after removing the old helpers. Trimming them will keep the file consistent with rustfmt output and reduce diff noise.

[Copilot]

Pull request overview

Copilot reviewed 7 out of 7 changed files in this pull request and generated no new comments.

[gonchihernandez]

@Byron I've been working a little bit more on the requested changes, also added the improvements on a separate commit and added an explanation into the Pr description.

[Copilot]

Pull request overview

Copilot reviewed 7 out of 7 changed files in this pull request and generated 3 comments.

[Byron]

Review Notes

• refactor
• look at each usage of the truncation - decide to not go down that path as it's not maintainable
  • dial that back to the previous hardcoded truncation
  • evaluate a pager to deal with truncation naturally (we have less now, that should do it)
• manual testing

[Copilot]

Pull request overview

Copilot reviewed 7 out of 8 changed files in this pull request and generated 1 comment.

[Byron]

@gonchihernandez Sorry for sending you down the prefix route, as I now believe this was the wrong call for being unmaintainable.

The goal here is to use the available width of the terminal to show more of the commit message. However, the prefix computations, which in theory would have to be handled for each and every command for consistency, seems like an impossible chore at the great expense of maintainability.

So I am going to see if the new pager implementation is suitable to allow not truncating at all.

[Copilot]

Pull request overview

Copilot reviewed 11 out of 12 changed files in this pull request and generated 5 comments.

[Byron]

And here is the result:

Generally all code that truncates now does so properly, aware of asian languages and ANSI codes.
But truncation only happens if no pager is configured.

Overall, this is a cleanup PR, with an easily revertable change to enable paging for but status in 9268ca0 .

No pager allowed via NOPAGER=1: truncation like before

See at the very bottom

Default: immediately quitting pager when less is available and there is space

Now there is no truncation at the bottom

╭┄zz [unstaged changes]
┊   kx A foorbar
┊
┊╭┄he [hello-world]
┊◐   aebe1c5 bsome nice title
┊●   865022f newnew different (no changes) {conflicted}
├╯
┊
┊╭┄hl [#hl] (no commits)
┊│
┊├┄g0 [st-branch-56]
┊●   ccf9b97 (no commit message)
├╯
┊
┊╭┄h0 [st-branch-54]
┊●   d264b80 (no commit message) (no changes)
├╯
┊
┊● cf10d3c (upstream) ⏫ 25 new commits (checked 18 minutes ago)
├╯ cebd8d5 [origin/master] 2025-02-24 Merge branch 'master' into B

Hint: run `but diff` to see uncommitted changes and `but stage <file>` to stage them to a branch
INFO     CLI [ 82.1ms | 47.67% / 100.00% ] cmd: Some(Status)
INFO     ┝━ setup [ 14.9ms | 18.19% ]
DEBUG    ┝━ 🐛 [debug]: Launched external pager | cmd: LESS="FXRS" "less"

but status -v long lines trigger less, and it won't wrap lines

Screen.Recording.2026-03-01.at.09.40.59.mov

but status triggered less due to not enough vertical space

Screen.Recording.2026-03-01.at.09.42.03.mov