From: Bert Wesarg Date: Mon, 27 Jan 2020 20:53:58 GMT Subject: Re: [PATCH] doc: clarify "explicitly given" in push.default Message-ID: <4715ac3d-0d85-c8f9-4cc1-cad58d1c1cd6@googlemail.com> In-Reply-To: On 27.01.20 20:48, Bert Wesarg wrote: > Dear Jeff, > > On 27.01.20 08:00, Bert Wesarg wrote: >> On 25.01.20 21:05, Jeff King wrote: >>> On Sat, Jan 25, 2020 at 08:38:04AM +0100, Bert Wesarg wrote: >>> >>>> thanks for this pointer. My initial pointer was the help for push.default: >>>> >>>>   From git-config(1): >>>> >>>>         push.default >>>>             Defines the action git push should take if no refspec is explicitly >>>>             given. Different values are well-suited for specific workflows; for >>>> >>>> Thus I expected, that this takes effect, when just calling 'git push'. >>> >>> Yeah, I agree "explicitly given" is vague there. Perhaps the patch below >>> is worth doing? >>> >>>> What I actually want to achieve, is to track a remote branch with a >>>> different name locally, but 'git push' should nevertheless push to >>>> tracked remote branch. >>>> >>>> In my example above, befor adding the 'push.origin.push' refspec, rename the branch: >>>> >>>>      $ git branch -m local >>>>      $ git push --dry-run >>>>        To ../bare.git >>>>         * [new branch]      local -> local >>>> >>>> Is it possible that this pushes to the tracked branch automatically, >>>> and because I have multiple such branches, without the use of a push >>>> refspec. >>> >>> I think if push.default is set to "upstream" then it would do what you >>> want as long as you set the upstream of "local" (e.g., by doing "git >>> branch --set-upstream-to=origin/master local). >> >> Thanks. This pushes only the current branch and honors the 'rename'. > > while this works … > >> >>> >>> 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? Falling back to simple/current seems to work for my case: diff --git a/builtin/push.c b/builtin/push.c index 6dbf0f0bb7..6b2fac7977 100644 builtin/push.c --- a/builtin/push.c +++ b/builtin/push.c @@ -259,7 +259,10 @@ static void setup_default_push_refspecs(struct remote *remote) break; case PUSH_DEFAULT_UPSTREAM: - setup_push_upstream(remote, branch, triangular, 0); + if (triangular) + setup_push_current(remote, branch); + else + setup_push_upstream(remote, branch, triangular, 0); break; case PUSH_DEFAULT_CURRENT: It has some fallouts in the test suite, obviously. But is this something we should pursue at all? Bert