On Tue, Dec 23, 2025 at 4:38 PM Junio C Hamano [off-list ref] wrote:

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 may be speaking for the author here, but I think the reason why the
upstream discovery (or alternatively an additional configuration in
the repo) feature was suggested is that not everyone uses the
mechanism you described (which I think is the "pushRemote" config).
It's true that if you *do* indeed have separate push/pull remotes for
a branch, then both should ideally be shown in `git status`. However,
oftentimes when you set up a feature branch it may not be correct /
desirable to set up separate push/pull remotes for those, especially
if you need to collaborate with people on the feature and therefore do
need to pull from the same feature's branch. In this case, I think the
author still wants `git status` to be able to show the diversion from
the original upstream master/main.

Personally I wonder if this feature gets added, people will start
asking for a list of "upstream branches" to be able to be compared to,
rather than just a fixed upstream/HEAD or origin/HEAD. But maybe I'm
thinking too far ahead.

But for example, I maintain MacVim, which is a downstream fork of Vim.
As such, "upstream" is a fluid concept for me depending on what I'm
doing. It could mean deviation between ychin/macvim vs
macvim-dev/macvim, or macvim-dev/macvim vs vim/vim. For complicated
forks, it's feasible someone may ask for the ability to see the branch
comparison against multiple branches concurrently.