Re: Bug in git rev-parse @{push}?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]