On Wed, Jan 14, 2026 at 04:38:33PM -0500, Ben Knoble wrote:

quoted

Le 14 janv. 2026 à 11:31, Jeff King [off-list ref] a écrit :

quoted

quoted

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,

Just so I’m clear, this is only with push.default=current, right? I could never make @{push} work otherwise.

I always use push.default=current, though I think @{push} should work
with other modes. E.g., with this setup:

  git checkout -b foo
  git clone . tmp
  cd tmp

  # for the sake of simplicity, our triangle goes to the same place ;)
  git remote add triangle ..
  git fetch triangle
  git config remote.pushdefault triangle

then doing:

  git -c push.default=current rev-parse --symbolic-full-name @{push}

and:

  git -c push.default=matching rev-parse --symbolic-full-name @{push}

should both point to refs/remotes/triangle/foo. Using "simple" will not
work, because it demands that the upstream and the push destination are
the same (so it doesn't really make sense in a triangular flow at all).

But in a non-triangular flow, it will happily point @{push} to the same
as @{upstream}. I use a triangular flow for git.git, but most of my
other repos are just personal projects, and I push/fetch from a single
central source.

-Peff