Show 32 quoted lines
>
> 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).