Mark a commit from another branch as good during bisect

[djdev-gpu]

Can you actually use b to bisect commits on a branch that isn't checked out, or is LazyGit just gaslighting me? 😅

The Situation

So I ran into this hilarious little trap today while hunting down a pesky bug. You know how it goes: you're trying to do a clean git bisect, and naturally, you want to grab a commit or branch tip from somewhere outside your current HEAD branch.

Picture this classic mess:

1. I'm on dev, everything is broken, life is pain. I kick off the bisect (git bisect start) and mark the latest commit as bad
2. I know for a fact this bug didn't exist on staging, so I saunter on over to the Branches panel, click staging, open its commits, and proudly smash b to mark it good
3. LazyGit just stares back at me blankly. Absolutely nothing happens 🤡

Turns out, those bisect keybindings are apparently hiding exclusively in the main Commits panel of your active branch. Trying to do it from another branch's view is like trying to text someone on a calculator—it just doesn't speak the language.

My Sad Workarounds 🛠️

Right now, my choices are basically to Manually scrolling through a 500-commit dev log trying to eyeball the fork point like an absolute caveman and given up on the sleek TUI dream, dropping to the command line, and typing out git bisect good staging like a peasant. 😂

The Question

Okay so well m I completely blind and missing some secret ninja shortcut for this, or is bisect just permanently chained to the main Commits panel? Help a fellow developer out before I scroll my mouse wheel straight off my desk!

[CanReader]

Probably you've hit on a current limitation in LazyGit. As of right now, bisect actions (like marking a commit as good or bad with b) are indeed strictly scoped to the main Commits panel of your currently checked-out branch. When you open another branch's commit log from the Branches panel, those bisect keybindings are inactive.

LazyGit's git bisect wrapper is designed around the assumption that you are stepping through the active working tree's history. Because bisecting physically moves your HEAD and checks out commits as you go, running it across arbitrary, non-checked-out branch logs outside the primary panel isn't wired up yet.

Best Workarounds for Now

Until a maintainer adds cross-branch bisect support or a PR is opened for it, you have a couple of clean ways to handle this inside LazyGit without necessarily dropping to an external terminal:

[tevinch]

You can add this with a custom command in subCommits, the context opened when you press Enter on a branch. It can use the selected commit's hash without checking out that branch:

customCommands:
  - key: 'b'
    context: 'subCommits'
    description: 'Mark selected commit for bisect'
    prompts:
      - type: 'menu'
        title: 'Mark {{.SelectedCommit.Hash}}'
        key: 'Mark'
        options:
          - name: 'good'
            value: 'good'
          - name: 'bad'
            value: 'bad'
    command: 'git bisect {{.Form.Mark}} {{.SelectedCommit.Hash}}'
    output: 'popup'
    outputTitle: 'Git bisect'

Append that entry to your existing customCommands list. Start the bisect with the bad dev commit in the main Commits view, open staging's commits, select the known-good commit, then press b and choose good. The main view keeps its native b menu for testing subsequent checked-out candidates.

If the branches have diverged, Git may first ask you to test their merge base. Test that revision too rather than assuming it is good.

I put a complete example with a disposable, diverged repository here. Terminal validation on released LazyGit 0.66.2 recorded the selected staging hash in BISECT_LOG, tested the merge base, found the expected first bad commit, and used the native reset to return to dev with a clean working tree. No custom build or plugin is needed. The released custom-command documentation covers the context and placeholder.

[stefanhaller]

#6168 adds the b menu in the tags and branches views, so you can use a tag or branch as the initial good/bad starting points directly without the need for a custom command.