[FEATURE] Detect unpushed commits on non-current branches

[nilp0inter]

What problem does this solve?

CheckRepoState (internal/gitx/gitx.go) computes status only against <remote>/<currentBranch>, where the branch comes from git branch --show-current. Commits stranded on any other local branch are never examined.

So "I did work on feature/x, switched back to main, and forgot to push feature/x" is invisible — the scan only ever looks at whatever branch happens to be checked out.

Proposed solution

Enumerate all local branches and report unpushed/unpulled status per branch. A single network-free call covers it:

git for-each-ref \
  --format='%(refname:short)%09%(upstream:short)%09%(upstream:track,nobracket)' \
  refs/heads

Combine with git rev-list --count <branch> --not --remotes for a fetch-free unpushed count that also handles the no-upstream case (related issue).

Surface per-branch status in report.RepoState (e.g. Branches []BranchStatus) so JSON and TUI can show which branch is unpushed. This also delivers the existing roadmap item "Show branches with their states on each repo."

Out of scope

• Detection of the no-upstream case in isolation (separate issue, though the implementation here naturally fixes it too).
• Performing the push.

Split off from #46.

[mabd-dev]

Hey @nilp0inter
Thanks for suggesting this. As you may know already supporting all repos branches is in the pipeline.

I agree on how you suggested getting branch upstream status for each branch.

I have few concerns though, how do you plan to change RepoState struct ? Where would Branch and UncommittedFiles fields live in the structure ? And what about TUI rendering? Currently each RepoState correspond to a row in TUI table, what is your plan for this change ?

If you don't know, @frittlechasm is working on supporting jujitsu VCS in feat/jjSupport branch. We need to make sure we model this right to support both git and jj VCS
@frittlechasm can you help us with this

[frittlechasm]

I like the idea to showcase all branch status and not just the current checked out one.

Instead of adding Branches []BranchStatus, I think a VCS-neutral shape would fit better because Git has branches, but jj uses bookmarks. Something like:

type RefStatus struct {
    Name           string         `json:"name"`
    Kind           string         `json:"kind"` // "branch" or "bookmark"
    Current        bool           `json:"current,omitempty"`
    RemoteStatus   []RemoteStatus `json:"remoteStatus"`
}

RemoteStatus struct can stay as-is and be reused inside each ref:

type RemoteStatus struct {
	Remote          string   `json:"remote"`
	Ahead           int      `json:"ahead"`
	Behind          int      `json:"behind"`
	OutgoingCommits []string `json:"outgoingCommits,omitempty"`
}

Then RepoState could add this new field:

type RepoState struct {
    ID              string         `json:"id"`
    Path            string         `json:"path"`
    Repo            string         `json:"repo"`
    VCSType         string         `json:"vcsType"`
    Stashes         []string       `json:"stashes"`
    UncommitedFiles []string       `json:"uncommitedFiles"`
    Refs        []RefStatus `json:"branches,omitempty"`
}

The main table can stay repo-level and show aggregate totals across refs, for example:
⏳0 ↑3 ↓1 branches:2

The details panel can have all the branch specific details like:

Refs:
  main       origin/main    ↓1
  feature/x  no upstream    ↑2 local-only


Ref ( main ) : 
  File Changes:
    M ../../../main/docs/TODO.md
    A ../../../main/test.go
    A ../../../main/file.go
  
  Outgoing Commits:
    742bc6fd5b04 wip: this is a test commit
    4e8c2cab7d83 feat(posts): this is another test commit

Ref ( feature/x ) : 
  File Changes:
    M ../../../feature/docs/TODO.md
    A ../../../feature/testx.go
    A ../../../feature/filex.go

For Git, we can populate refs from local branches. For jj, we can populate refs from bookmarks and reuse the existing remote bookmark comparison logic.

We can discuss more on the implementation if required ..

⚠️ NOTE: The only downside to this would be that if we remove Branch, UncommitedFiles, and top-level RemoteStatus from RepoState, we might break any external JSON consumers or integrations / workflows people might have in place.

[mabd-dev]

@frittlechasm I like your suggestion

I would push back on how to show this in TUI, your suggestion works but won't work later when we introduce git/jj functions/keybindings to push/pull
I prefer to flatten RepoState in TUI so that each row show one ref, similar to how we currently do it for worktrees. Each worktree is a row in the table

This way we can manipulate (push/pull) each row (branch/bookmark) separately

Later on I am planning to update the TUI rendering a bit to support this multiple refs/worktrees better. Something like a expand/collapse menu. One row would show the project name and the current branch status, if you expand it, i will show all other branches (add more rows). Something like this, still thinking about it

---

⚠️ NOTE: The only downside to this would be that if we remove Branch, UncommitedFiles, and top-level RemoteStatus from RepoState, we might break any external JSON consumers or integrations / workflows people might have in place.

You are correct, this would break people automated workflows. Not sure if we can do anything about it, other than explicitly stating it in release notes. We also need to tell them how to migrate to the new data structure