Triangular workflow
- From
Harald Nordgren <haraldnordgren@gmail.com>
- Date
- Jan 18, 2026, 19:58 UTC
- Message-ID
- <20260118195845.16908-1-haraldnordgren@gmail.com>
- In-Reply-To
- <xmqq8qe0f2iq.fsf@gitster.g>
Show 29 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?I'm implemented this now. Please take a look at the latest patch!
But there seems to be a memory leak that I can't figure out after spending some hours running the CI over and over.
Harald