Re: [PATCH] status: show default branch comparison when tracking non-default branch

From: Yee Cheng Chin <ychin.macvim@gmail.com>
Date: Dec 23, 2025, 23:11 UTC
Message-ID: <CAHTeOx_kSX7RhVvjjffSK849MMQbjNreqrq=ezHazw0GjMO2Ww@mail.gmail.com>
In-Reply-To: <pull.2138.git.git.1766451217075.gitgitgadget@gmail.com>

> The default branch is determined dynamically by checking:
> 1. refs/remotes/upstream/HEAD (if upstream remote exists)
> 2. refs/remotes/origin/HEAD (fallback)

I feel like this is making a lot of assumptions regarding remotes. "origin" and "upstream" are not inherently special names for remotes. I personally have different Git repositories where they could mean slightly different things, and I don't use the "upstream" wording myself (I sometimes use "official" for the upstream branch, and/or "ychin" for my own fork's remote). Feels like we should not be imposing such a hard-coded value when nothing else in Git enforces it.

Also, when there are multiple remotes, it's not always clear which one the user actually cares about. It's not always clear if they care about the upstream or the downstream remote, of a third one that actually matters more.

This would also work poorly with detached branches (e.g. the popular 'gh-pages' branches in a lot of repositories), or permanently foked branches like fixed versions (e.g. v2.x legacy branch when the software main branch moved to v3.0). Seems like for this to work well it would need to be configurable per branch. Even on a repository level there would likely be lots of edge cases with each branch having its unique circumstances.