Re: Triangular workflow

From: Jeff King <peff@peff.net>
Date: Jan 14, 2026, 21:10 UTC
Message-ID: <20260114211013.GB1008851@coredump.intra.peff.net>
In-Reply-To: <xmqq8qe0f2iq.fsf@gitster.g>

On Wed, Jan 14, 2026 at 10:54:53AM -0800, Junio C Hamano wrote:

Show 13 quoted lines

> Jeff King <peff@peff.net> writes:
> 
> > 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 ;-)

True, but then it also cannot pleasantly surprise people who didn't realize they wanted it.

Having your user experience regressed and then tweaking a config option to fix it is not too bad. The deciding factor to me is whether more people will be pleasantly surprised or annoyed. ;) I don't have a strong sense there.

As a general principle, though, I think a reasonable path forward for any behavior change is:

  1. Implement the new behavior, hidden behind a config option.

  2. Wait a while to see how people like the new option, and shake out
     any bugs.

  3. If people like the option and are puzzled why it isn't the default,
     then flip the default on.

In other words, let the utility of the feature be proven in practice by people opting into it. There is a chicken-and-egg problem if they don't know about it, but if it is truly solving a problem people have, then hopefully some of them would look for a solution and find it.

End philosophical rambling. ;)

> 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 haven't been following the feature closely, but my understanding is that yes, it's basically "also compare to @{push} if it is not the same as @{upstream}".

Show 13 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}
> 
> 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?

Interesting. That is more flexible, though I'm not sure how useful that flexibility is. I guess you could imagine putting in a static branch. E.g., if you base your branches off of "master", might you want to show ahead/behind to "maint" or "next"? I have trouble imagining a workflow where I would want to do that often enough for git-status (and checkout) to do it automatically, though.

But assuming it suppresses duplicates, then yeah, this feels like a more flexible superset of the functionality.

-Peff