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

[Junio C Hamano <gitster@pobox.com>]

Yee Cheng Chin <ychin.macvim@gmail.com> writes:

>> 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.

> 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.