Re: [PATCH v17 1/2] refactor format_branch_comparison in preparation

From: Harald Nordgren <haraldnordgren@gmail.com>
Date: Jan 12, 2026, 19:47 UTC
Message-ID: <20260112194733.23192-1-haraldnordgren@gmail.com>
In-Reply-To: <d2ea8560-1473-43c0-96c1-e1869e22c721@gmail.com>

Show 6 quoted lines

> It is hard to discuss this without knowing what actually breaks. Are you
> talking about the tests added in this series? If so that means we're
> expecting a different behavior to what "git push" actually does. As Ben
> has pointed out elsewhere in this thread, if you're pushing back to a
> different branch on the same remote as the upstream branch you need to
> set `push.default=current`.

Yes, it's my new tests that are breaking. Maybe it's easiest if you check out the `seen` branch which now has this logic, play with the code and run the tests to see when it breaks.

I designed the feature around 'push.default=current' which I use.

If we would design the feature around 'push.default=upstream' then what is the point? 🤗 Why do we need to show status for both an upstream and a push branch if we are already pushing to our upstream branch?

> The benefit is that you get a sane interface rather that returning two
> different versions of the same string in two different ways (one from
> the function's return value and the other from a function parameter). It
> also matches what we do for the upstream branch.

That's a good point about matching what we do for upstream branch, I'll take a look.

> I can't seem to see that test. If we're printing the advice once for the
> upstream branch and once for the default push remote I think that would
> be ok.

This test is also part of my patch 🤗

I disagree about showing the same advice twice.

> But we set show_divergance_advice to false for the push branch so there
> is no need to check the flag.

Good point! I'll update it!

Harald