Re: Triangular workflow

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 14, 2026, 14:15 UTC
Message-ID: <xmqqecnsgu1i.fsf@gitster.g>
In-Reply-To: <20260114023408.GA858378@coredump.intra.peff.net>

Jeff King <peff@peff.net> writes:

> 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!).

Yes, exactly. I was wondering where Harald's suggestion to swap the two remotes came from.

Show 12 quoted lines

> 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
>
> to compare two iterations of a branch if I know that I haven't pushed.
> It is a bit of a cheat, because what I really mean is "do a range-diff
> since the last thing I sent to the list". But if I have just been
> working on a branch, and I haven't run an integration cycle since then,
> then I know that the pushed version will match it.

Great suggestion. It is fun to see that comparing notes among people with different workflows brings out these gems ;-)

> There is also branch.*.pushRemote, but I have not found that useful (for
> my triangular flow there is always a single repo to push to, not one per
> branch).