Re: Triangular workflow

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 14, 2026, 23:31 UTC
Message-ID: <xmqqecnrepox.fsf@gitster.g>
In-Reply-To: <20260114231202.61271-1-haraldnordgren@gmail.com>

Harald Nordgren <haraldnordgren@gmail.com> writes:

Show 14 quoted lines

>> 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.