Re: [PATCH] status: show default branch comparison when tracking non-default branch
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Dec 24, 2025, 00:38 UTC
- Message-ID
- <xmqqy0msogso.fsf@gitster.g>
- In-Reply-To
- <CAHTeOx_kSX7RhVvjjffSK849MMQbjNreqrq=ezHazw0GjMO2Ww@mail.gmail.com>
Yee Cheng Chin <ychin.macvim@gmail.com> writes:
Show 6 quoted lines
>> 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.
Good point. There is a mechanism to determine where a branch would be pushed to with "git push", and where the new material to update the branch would come from with "git pull", and these places need to be considered when doing comparisons. This series seems to punt on determining both repository and branch and instead uses a hardcoded "upstream" (or "origin") and "HEAD", which is not satisfactory.
Show 18 quoted lines
> 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.
Yes, unrelated branches like gh-pages gives us a very good example to think about.
Thanks.