feat(tui): inline branch reword

[davidpdrsn]

The TUI supports rewording commits inline by pressing enter. This extends that functionality to also support branches.

Screen.Recording.2026-03-24.at.10.50.19.mov

[vercel]

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

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
gitbutler-web	Ignored	Preview	Mar 24, 2026 2:11pm

[Copilot]

Pull request overview

Adds inline branch renaming support to the legacy TUI status view, aligning the branch rename operation with the existing inline commit reword flow and returning the normalized branch name from the backend so the UI can re-select the renamed branch after reload.

Changes:

• Extend TUI inline reword mode to support branch renames (new InlineRewordMode::Branch path).
• Change update_branch_name in branch-actions and but-api legacy stack API to return the normalized new branch name (String).
• Rename legacy reword helpers for clarity and add a legacy wrapper for branch inline rename.

Reviewed changes

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

Show a summary per file

File	Description
crates/gitbutler-branch-actions/src/stack.rs	update_branch_name now returns the normalized name to support UI selection after rename.
crates/but-api/src/legacy/stack.rs	Propagates the new Result<String> return type through the legacy but-api surface.
crates/but/src/command/legacy/status/tui/operations.rs	Renames commit reword helpers and adds a branch inline rename operation wrapper.
crates/but/src/command/legacy/status/tui/mod.rs	Implements inline branch rename UI flow (mode enum, input handling, rendering, confirm behavior).
crates/but/src/command/legacy/status/tui/cursor/tests.rs	Updates cursor tests to the new InlineRewordMode enum shape.

[Copilot]

Pull request overview

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

Comments suppressed due to low confidence (1)

crates/gitbutler-branch-actions/src/stack.rs:95

• snapshot_update_dependent_branch_name is being called with branch_name (the old name). The snapshot API’s parameter is new_branch_name, so the oplog trailer will record the wrong value for rename operations. Consider normalizing new_name first and passing the normalized new name (and optionally recording both old/new names in trailers if needed).

    let mut guard = ctx.exclusive_worktree_access();
    ctx.verify(guard.write_permission())?;
    let _ = ctx.snapshot_update_dependent_branch_name(&branch_name, guard.write_permission());
    ensure_open_workspace_mode(ctx, guard.read_permission())
        .context("Requires an open workspace mode")?;

[Copilot]

Grammar: “Updates the name an existing branch” should be “Updates the name of an existing branch”.

Suggested change

	/// Updates the name an existing branch and resets the pr_number to None.
	/// Updates the name of an existing branch and resets the pr_number to None.

[slarse]

I very much skimmed the implementation, but it looks good. Feels good to use, too.

When dicking around with it, I of course tried to name the branch bad things. And, unexpectedly, HEAD stuck. Which is bad because that's not an allowed branch name. I don't think this is at all related to the TUI (can do the same thing in CLI), so I'll make a separate bug ticket for it.

I was unable to get out of that state using GitButler, it gets very confused about it all (and rightfully so). I'll open a separate bug ticket for it and address it ASAP.

[davidpdrsn]

Oh good catch! That's indeed a backend bug

[Byron]

refs/heads/HEAD is a valid ref-name though, and I'd think that this is what happened.
The backend does validate and normalizee branch names, ensuring they are valid refs.

[slarse]

@Byron

refs/heads/HEAD is a valid ref-name though, and I'd think that this is what happened. The backend does validate and normalizee branch names, ensuring they are valid refs.

You appear to be correct.

$ git check-ref-format refs/heads/HEAD
$ echo $?
0

I think I'm missing something here, is there a distinction between refs/heads/X and branches? In my world view, every ref in there is a local branch.

But Git explicitly prohibits naming a branch refs/heads/HEAD, it's just a hard-coded not allowed refname for branches.

$ git branch HEAD
fatal: 'HEAD' is not a valid branch name
hint: See 'git help check-ref-format'
hint: Disable this message with "git config set advice.refSyntax false"

git help check-ref-format says nothing about refs/heads/HEAD, by the way.

So all I can surmise is that refs/heads/HEAD is a syntactically correct ref name that is disallowed as a special case of ref name rules? But I think we should disallow the use of it to maintain Git compatibility, as opposed to trying to make it work? It bricks GitButler entirely and makes Git angry.

Although Git does allow me to rename the ref afterward, GitButler just gets sad as it resolves both the workspace commit and the branch tip commit.

[test-repository]$ but status
Initiated a background sync...
╭┄zz [unstaged changes]
┊     no changes
┊
┊╭┄my [my-valid-branch] (no commits)
├╯
┊
┴ 60dd738 [origin/main] 2026-02-23 Update README in GUI

Hint: run `but help` for all commands
[test-repository]$ but reword my -m HEAD
Renamed branch 'my-valid-branch' to 'HEAD'
[test-repository]$ but status
╭┄zz [unstaged changes]
┊     no changes
┊
┊╭┄HE [HEAD] (no commits)
├╯
┊
┴ 60dd738 [origin/main] 2026-02-23 Update README in GUI

Hint: run `but help` for all commands
[test-repository]$ but reword HE -m my-valid-branch
Error: The reference "refs/heads/HEAD" should have content c78d24390465ce7ce6d2a3aa3581ebd510eb2bc1, actual content was 60dd73885f3371ab2c1f78ced86976b9bb4ace3a

[slarse]

@davidpdrsn Sorry about derailing your merged PR :D

[davidpdrsn]

Unacceptable!