Re: Bug in git rev-parse @{push}?
From: Chris Purcell <hidden>
Date: 2016-11-03 16:12:16
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 [off-list ref] wrote:
On Thu, Nov 03, 2016 at 03:59:13PM +0000, Chris Purcell wrote:quoted
quoted
quoted
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