Re: [PATCH v2] status: compare against both upstream and push branch by default

From: D. Ben Knoble <ben.knoble@gmail.com>
Date: Oct 24, 2026, 13:49 UTC
Message-ID: <CALnO6CBD2aGg_wDZZsT-mWJ99MXYUycx32JfsK8zJXfcmjTBDw@mail.gmail.com>
In-Reply-To: <xmqqld7o71ot.fsf@gitster.g>

On Fri, Oct 23, 2026 at 1:45 PM Junio C Hamano <gitster@pobox.com> wrote:

Show 17 quoted lines

>
> "Harald Nordgren via GitGitGadget" <gitgitgadget@gmail.com> 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.

Show 10 quoted lines

> 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