Subject: Re: Triangular workflow

From: Junio C Hamano <[email-masked]>
Date: Wed, 14 Jan 2026 15:31:58 -0800

Harald Nordgren <[email-masked]> writes:

>> I wonder if we can come up with a flexible and
>> extensible notation to specify what branch(es) to compare with, so
>> that we can use it as the value of this opt-in configuration
>> variable?  Something like
>> 
>>         [status] compareBranches = @{upstream} @{push}
>
> If we go with that, then it becomes trickier code-wise to show push/pull
> advice for the correct branches. But not impossible since we can check if
> branch is the same as @{upstream} or @{push}.
>
> Philosophically, two main git commands are 'git push' and 'git pull'. So it
> makes perfect sense to me to signal that those two are special, and not
> allow other compareBranches.

You are falling into the same trap as what the folks who designed
the original ahead/behind comparison did by limiting yourself to
push and pull.  They said object transfer always interacts with the
@{upstream}, hence only comparison with that is sufficient and it
makes sense not to allow comparing with anything else.

Until you started wishing that you want to also compare with
@{push}, that is ;-).

A static point that has nothing to do with pushing and pulling
(e.g., "the latest official release tag") may be something useful to
compare with in certain workflows (presumably workflow of the
maintainer type), so limiting our sights to object transfer like
push and pull is likely to be a mistake.