Will do, thanks! Meanwhile, I'll work around locally by changing off
'simple' in my config—if I can figure out how not to break everything
in the process...
On 3 November 2016 at 16:07, Jeff King <peff@xxxxxxxx> wrote:
> On Thu, Nov 03, 2016 at 03:59:13PM +0000, Chris Purcell wrote:
>
>> >> Thanks, Jeff! If I remove the explicit configuration of remote.pushdefault
>> >> = "origin", I get the same error message as you, so I suspect that's _not_
>> >> the default.
>> >
>> > That's really bizarre, because I get the same behavior with or without
>> > it set. Not only that, but it shouldn't even come into play, as
>> > branch.foo.remote should take precedence anyway.
>> >
>> > So now I'm really puzzled.
>>
>> That's because I lied. Sorry! Too many branches configured. I've actually got
>>
>> [branch "foo"]
>> remote = .
>>
>> If I change that to 'origin' like I claimed it was, it starts erroring.
>
> OK, now I can reproduce. And changing remote.pushdefault _does_ matter
> because builtin/push.c:is_workflow_triangular() uses it as a key to "we
> are in a triangular workflow".
>
> That was added by ed2b18292 (push: change `simple` to accommodate
> triangular workflows, 2013-06-19). TBH, I think the right solution is
> "stop using 'simple' in a triangular setup". But since that workflow
> exists for git-push, we probably need to support it via @{push}, too.
>
> I think the solution would be something like:
>
> - move is_workflow_triangular() into remote.c so it is accessible in
> both places
>
> - when branch_get_push_1 sees that is_workflow_triangular() is true,
> treat "simple" as "current"
>
> - new tests should go into t/t1514-rev-parse-push.sh to cover this
> case
>
> Want to take a stab at it?
>
> -Peff