From: Jeff King <peff@peff.net>
Date: Mon, 23 Feb 2026 13:30:34 GMT
Subject: Re: [PATCH v28 2/2] status: add status.compareBranches config for multiple branch comparisons
Message-ID: <20260223133034.GD215671@coredump.intra.peff.net>
In-Reply-To: <xmqqwm06rp6p.fsf@gitster.g>

On Sat, Feb 21, 2026 at 09:17:50AM -0800, Junio C Hamano wrote:

> Harald Nordgren <haraldnordgren@gmail.com> writes:
> 
> > Hi Junio and Jeff!
> >
> > I see that this topic has now been marked as "Stale". Isn't it time to
> > merge this now?
> >
> > We went to several rounds of reviews and edits to reach something that I
> > think everyone agrees with 🤗
> 
> The entry has been asking "What's the status of this topic?" in the
> past handful of issues of "What's cooking" report and we heard
> nothing from anybody (until you responded ;-)), so I moved it
> together with others to the [Stalled] section.
> 
> The topic has been paged out of my consciousness for quite a while,
> so it may take some time for me to answer this question myself, but
> list participants, do you imagine yourselves using this feature in
> your daily life?

I do not personally have any interest in using the feature (I only
joined the thread to complain that it could not be turned off ;) ).

So in that sense I don't care how far it takes things along the path of
what was discussed in the v27 review. My main concern is that we not
paint ourselves into a corner and be stuck forever with an interface
that is inconsistent with the rest of Git.

So what about this. We add a config option that takes a list of items to
compare against. But it _only_ supports @{upstream} and @{push} for now,
and interprets them as branch@{upstream} and branch@{push} (but probably
done manually, not via dwim_ref). That limitation gets documented.

Then later, if we choose to allow resolving arbitrary refs via
dwim_ref(), we can add that support on top:

  - rather than manually resolving @{upstream}, quietly rewrite it to
    branch@{upstream}. This is OK since branchless @{upstream} makes no
    sense in this context.

  - otherwise, pass what the user gives us to repo_dwim_ref()

  - optionally allow substitution via %s or similar. Technically I think
    "%" is allowed in a ref. I think that's probably OK in practice,
    though if we want to be really careful, then "[branch]" or something
    that's forbidden in the ref format would be a possible substitution.

But if we stop short of all of that today, we don't have to worry about
all of those weird corner cases I dug up in the earlier thread. And if
nobody ever _really_ cares about sticking arbitrary refs into their
compare-list, then we just never go there.

-Peff