Re: Triangular workflow

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 14, 2026, 18:54 UTC
Message-ID: <xmqq8qe0f2iq.fsf@gitster.g>
In-Reply-To: <20260113214059.GC288857@coredump.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 5 quoted lines

> And having the extra output from "git checkout" is just extra noise for
> me, especially because it is easy to see only the second message (which
> looks just like the upstream ahead/behind message, of course) and get
> confused. The first time I saw it I thought I had misconfigured
> something with my branch.

It now is clear to me that this should be _optional_, so that those who do really want extra output from the command should explicitly opt into the feature. After all, any optional new feature that you must opt into by definition cannot regress end user experience for those who do not ;-)

At the same time, I suspect that extra comparison on top of what we already give against the @{upstream} may not be limited to what Harald implemented (is it essentially the same as specyfing @{push}, or something else?). 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}

signals that the current branch is compared against these two branches, and not having the configuration (i.e., traditional behaviour, which is left the default) would be equivalent to have

	[status] compareBranches = @{upstream}

or something like that, perhaps?

Thanks.