TUI: `o` / `shift+o` do nothing in the details pane for committed-file diffs

Open Beginner friendly
  • Is something wrong?
#16,982 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
78/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
rust
Domain
desktop, devtools

Research direction

Start in crates/but/src/command/legacy/status/tui/app/mod.rs at selected_openable, then compare its committed hunk handling with resolve_source in crates/but/src/command/open.rs and the IDs assigned in crates/but/src/utils/diff_rendering.rs. Check existing tests for opening files from the TUI and add coverage for o and shift+o on a committed hunk; done means both actions open the file at the hunk’s line or show the picker.

Written by the indexing model from the issue text.

Description

Version

but 0.23.2

Operating System

macOS (arm64)

Distribution Method

dmg (Mac OS - Apple Silicon), installed with the Homebrew cask

Describe the issue

In but tui, o (open) and shift+o (open with picker) do nothing when the details pane shows the diff of a committed file. The details help (?) lists both keys. No program opens, no picker appears, and no toast is shown.

The cause appears to be in selected_openable in crates/but/src/command/legacy/status/tui/app/mod.rs (checked on main at 0f8a975):

  • In Mode::Details, the selection comes from self.details.selected_section_cli_id().
  • For a committed file, render_committed_hunk_section in crates/but/src/utils/diff_rendering.rs gives each section a CliId::CommittedHunk ID.
  • selected_openable handles CliId::UncommittedHunkOrFile and CliId::CommittedFile, but maps CliId::CommittedHunk to Ok(None).
  • handle_open_in_default_program and handle_pick_program_then_open then return early without any feedback.

The non-TUI path already supports committed hunks. resolve_source in crates/but/src/command/open.rs maps ResolvedCliIdArg::CommittedHunk to Openable::try_from_hunk(repo, &committed_hunk.hunk, false).

A possible fix is to add the same case to selected_openable:

CliId::CommittedHunk(committed_hunk) => {
    Openable::try_from_hunk(&*ctx.repo.get()?, &committed_hunk.hunk, false).map(Some)
}

That would also open the file at the hunk's line, like o does for uncommitted hunks. Note that try_from_hunk resolves the path in the current worktree, so it opens the working copy of the file, not the committed version.

It might also help to show a toast when selected_openable returns None, so the key does not fail silently.

How to reproduce (Optional)
  1. Run but tui in a workspace with at least one commit.
  2. Select a file inside a commit in the status pane.
  3. Focus the details pane (l / →) so a hunk of that committed file's diff is selected.
  4. Press o or shift+o.

Expected: the file opens in the default program, or the program picker appears.
Actual: nothing happens.

Based on the code, o with the committed file selected in the status pane (a CliId::CommittedFile) should still work; I have not checked this separately.

Dominant language
Rust
Stars
21.9k
Forks
1k
Avg merge
6h 1m
Merged PRs (30d)
657

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from gitbutlerapp/gitbutler

All issues in gitbutlerapp/gitbutler

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.