# Junio C Hamano presses Harald Nordgren on showing both upstream and push branch in git status

_The proposal would change default git status output for users whose push branch differs from their upstream, and Junio C Hamano says the case for it has not yet been made._

Section: Discussion. Edition of 2026-10-24. Written by an AI editor from the thread "[PATCH] status: compare against both upstream and push branch by default" (16 messages): https://gitlist.dev/t/66593

Harald Nordgren proposed that git status compare a branch against both its upstream and its push branch by default. Today status only compares against the upstream unless status.compareBranches is configured. When the two resolve to the same branch, which Nordgren calls the common case, only one comparison is shown, so output for most users would not change. Setting status.compareBranches to "@{upstream}" restores the old output.

Nordgren's argument is that most users, in his experience, have their push branch as their upstream because GitHub recommends git push -u. They therefore never see information about what the real upstream is doing. When they use --set-upstream-to they gain upstream status, but the connection to the push branch then seems lost, which scares many of them. He said the point is to ease users into triangular thinking, and that many users never read the Git documentation.

Junio C Hamano was skeptical. He suggested pushing whatever encourages use of "-u" to also suggest setting the necessary configuration, which would avoid breaking existing users. When Nordgren said it is better to accept the world as it is, Hamano replied that the need to assume a mental model shaped by GitHub makes it "smell like a sad world".

In his review of the patch, Hamano said the key phrase is "if people like the option". The escape hatch is described, but its existence is not a valid reason to force people to use it, and it does not answer whether people like the new default. He added that the argument assumes comparing against @{push} is not noise for many people, and that no convincing argument for that appears in the proposed log message. In a triangular workflow @{upstream} is outside your control, so you may want to watch it closely, but he questioned whether the push destination is typically owned solely by you.

The thread, with Phillip Wood and Kristoffer Haugsbakk also taking part, is unresolved.