Thread (4 messages) flat view 4 messages, 2 authors, 2016-11-03

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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help