Re: [PATCH] doc: clarify "explicitly given" in push.default
- From
Jeff King <peff@peff.net>
- Date
- Jan 27, 2020, 23:14 UTC
- Message-ID
- <20200127231459.GD19360@coredump.intra.peff.net>
- In-Reply-To
- <dfcf0201-b634-2274-f041-a6ec4491825a@googlemail.com>
On Mon, Jan 27, 2020 at 08:48:01PM +0100, Bert Wesarg wrote:
Show 21 quoted lines
> > > 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