From: D. Ben Knoble Date: Sat, 24 Oct 2026 13:49:26 GMT Subject: Re: [PATCH v2] status: compare against both upstream and push branch by default Message-ID: In-Reply-To: On Fri, Oct 23, 2026 at 1:45 PM Junio C Hamano wrote: > > "Harald Nordgren via GitGitGadget" writes: > > > Showing both without any configuration was the original proposal for > > that commit. But some found the comparison with the push branch to be > > noise. So the comparison was made opt in [1], with the idea of > > flipping the default later if people like the option. > > The key phrase here is "if people like the option". > > > Those who find the comparison with the push branch to be noise can > > set status.compareBranches to "@{upstream}" to get the old output > > back. > > The presence of an escape hatch is described here. But its > existence is not a valid excuse to force people to use it, nor does > it answer the question "if people like the option" posed above. I agree, though I still support changing the default. I think we need to make a stronger case. > The paragraph above (and below) also assumes that comparing with > @{push} is not noise for many people. We have not yet heard a > convincing argument supporting that assumption in the proposed log > message. In a triangular workflow, @{upstream} is not under your > control, so you may want to monitor its progress closely. But isn't > your @{push} destination typically owned solely by you? In other > words, aren't you the only one who pushes to it? If so, whatever > you did locally would be the only change that could go on top of > @{push}, and unlike @{upstream} you would not see any unexpected > work over there appearing without your control. I think this paragraph assumes that either * I'm only pushing new commits to @{push}, or * I remember what the current state of @{push} is without checking. I may not see "unexpected" work appearing there in most cases, but I certainly appreciate the reminder when returning to a topic after working on something else. Have I rebased/amended/git-history'd lately and need to force-push? Do I care about the differences? Sometimes I already know the answer and want to validate what I'm about to send out, kind of like "git send-email" with sendemail.annotate (and multiedit, for me) configured. I have a number of ways of helping answer this question, personally: * git status: only ahead-behind count, but lets me know if there's anything to do. I don't actually check this output too often myself because I built the below prior the config under discussion, and they are focused + finger memory---I almost always run short status when I do look at status, but that's because I don't normally need the verbose output these days ;) That's not the case for most of our users. * "git sbup" = show-branch HEAD HEAD@{push} HEAD@{upstream}: a quick divergence check * "git rdup" = range-diff HEAD@{upstream} HEAD@{push} HEAD: a detailed comparison * "git div" [1] runs a triple-dot graph log (with more options) comparing HEAD against @{push} (if they differ) or @{upstream} (if they're the same), omitting some other inferences and ways to supply which topic to inspect. [1]: https://github.com/benknoble/Dotfiles/blob/master/links/bin/git-div So, I suppose my point is: as someone who almost exclusively has triangular workflows, I'm already checking this push--local divergence on a regular basis. I just built my own extensions to do so prior to Harald's welcome addition to status. Perhaps that can help Harald argue the case more convincingly in a proposed log message? (Julia and I discussed briefly off-list whether "git-div"/"git-vee" should be part of Git, and I'm noodling on whether such a thing might make sense as "git log --divergence" or something.) -- D. Ben Knoble