Re: [PATCH] doc: clarify "explicitly given" in push.default

From: Bert Wesarg <bert.wesarg@googlemail.com>
Date: Jan 27, 2020, 20:53 UTC
Message-ID: <4715ac3d-0d85-c8f9-4cc1-cad58d1c1cd6@googlemail.com>
In-Reply-To: <dfcf0201-b634-2274-f041-a6ec4491825a@googlemail.com>

On 27.01.20 20:48, Bert Wesarg wrote:

Show 58 quoted lines

> 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