Bare repositories: .Ref/.HEAD mishandle detached HEAD and reftables, and .Upstream holds the raw remote list

Code of Conduct

• I agree to follow this project's Code of Conduct

What happened?

getBareRepoInfo() (src/segments/git.go:425-438) is the entire IsBare == true render path, and it has two independent defects:

1. HEAD is misinterpreted, not just misread. It hand-rolls a three-line HEAD parse that only understands ref: refs/heads/…. A reftables repository renders .Ref as .invalid instead of the real branch name; a detached bare HEAD renders the full 40-character object ID with .Detached false and .Hash/.ShortHash empty. The non-bare path already interprets all of this correctly — the bare path just never reuses it.
2. .Upstream carries the remote list, not the upstream. src/segments/git.go:434 assigns g.Upstream = g.getGitCommandOutput("remote") — the newline-separated, alphabetically-sorted output of git remote. A repository with two remotes renders .Upstream as origin\nupstream, putting a line break in the middle of the prompt.

Expected: in a bare repository, .Ref/.HEAD/.Detached/.Hash behave identically to a non-bare repository (reftables, detached HEAD, everything), and .Upstream is either the branch's real upstream or empty — never the remote list.

Theme

version: 3
final_space: false
blocks:
  - type: prompt
    alignment: left
    segments:
      - type: git
        style: plain
        properties:
          fetch_bare_info: true
          fetch_upstream_icon: true
        template: 'Ref=[{{ .Ref }}] Up=[{{ .Upstream }}]'

# bare clone with two remotes configured, rendered from its root
oh-my-posh print primary --plain --config ./bare.omp.yaml --pwd /path/to/bare-root --shell zsh
# Ref=[] Up=[origin
# upstream]

What OS are you seeing the problem on?

Linux, macOS, Windows

Which shell are you using?

zsh

Log output

[DEBUG] map.go:debugf:71 → fetch_bare_info: true
[TRACE] terminal.go:FileContent(<bare>/config) - 80µs   # bare = true, two remotes
[TRACE] git.go:isBareRepo() - 198µs

Note

This depends on #7798 — the .Ref fix here reads HEAD through the same directory that issue's fix corrects.