On Tue, Jan 28, 2020 at 12:15 AM Jeff King <peff@xxxxxxxx> wrote: > > 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). thanks. I will try to come up with a patch. Bert > > -Peff
