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