On Mon, Jan 27, 2020 at 08:48:01PM +0100, Bert Wesarg wrote: > > > There's another way of doing this, which is when you have a "triangular" > > > flow: you might pull changes from origin/master into your local branch > > > X, but then push them elsewhere. Usually this would be pushing to a > > > branch named X on a different remote than origin (e.g., your public fork > > > of upstream on a server). And for that you can set branch.X.pushRemote. > > … it does not play well if you have have both flows in one repository. > And I do have both flows. I track the upstream 'master' in the local > branch 'Y' and I have also a branch 'X' which is based on 'Y' but > should be pushed to a different remote as branch 'Y'. I have > configured 'branch.X.pushRemote = triangular' but with 'push.default' > set to 'upstream' I get this when: > > $ git push triangular > fatal: You are pushing to remote 'triangular', which is not the upstream of > your current branch 'X', without telling me what to push > to update which remote branch. > > In this simple case, without a renaming, I would expect that 'git > push' just works. May be just fallback to 'simple' if 'upstream' does > not resolve to a fully qualified push? I thought the point of "simple" was to be even more restrictive than "upstream". At any rate, your setup is sufficiently complicated that I think you'd be better off adding a branch.X.pushRef feature (essentially a refspec to be used just on branch X, though since the source side is implied, it's really just a destination ref). -Peff
