From: Jeff King <peff@peff.net>
Date: Wed, 14 Jan 2026 16:24:27 GMT
Subject: Re: Triangular workflow
Message-ID: <20260114162427.GA885771@coredump.intra.peff.net>
In-Reply-To: <20260114075309.32911-1-haraldnordgren@gmail.com>

On Wed, Jan 14, 2026 at 08:53:09AM +0100, Harald Nordgren wrote:

> > I could (and in fact the script names the remote directly already,
> > because you can't pass refspecs without specifying the remote). But I do
> > occasionally push a single branch with a bare "git push". Usually this
> > is the integration branch, when I am trying to trigger CI manually
> > (e.g., when piling hacks on top in order to debug a CI failure ;) ).
> > 
> > So even if I only do it infrequently, it feels weird that a bare "git
> > push" would try to push to the upstream remote (which I don't even have
> > write access to!).
> 
> Maybe ’push.default=simple’ or ’push.default=nothing’ are better settings
> in your scenario. Then you get explicit pushing because no push branch gets
> set. And thus 'git status' reports not additinal status.

If I did that, then the occasional "git push" (without arguments) that I
do would fail. Likewise, @{push} would not be usable.

> > Yeah, though @{push} is usually not explicitly configured in the same
> > way @{upstream} is, but rather a consequence of how push.default and
> > remote.pushdefault interact. But it was added for exactly this kind of
> > triangular workflow. I sometimes will do stuff like:
> > 
> >   git range-diff origin @{push} HEAD
> 
> I imagine the same thing could be achieved with
> 
>     origin/$(git rev-parse --abbrev-ref HEAD)

Sure, but:

  1. It is a lot shorter to type @{push}. ;)

  2. Using @{push} works everywhere, even on my non-triangular repos,
     because it takes into account the push configuration. So it's a
     much nicer muscle-memory to acquire.

-Peff