Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

pull-request uses wrong base #461

Open
asmeurer opened this Issue · 18 comments

6 participants

@asmeurer

pull-request used to correctly use the base from my origin remote, but now it seems to want to make pull requests against asmeurer/repo:master (for a branch that I've pushed to my fork).

@mislav
Admin

Your hub version? How are your remotes named? What exactly did you expect for the base, and what happened instead? Where did you push your branch? Did you use upstream configuration?

@asmeurer

Hmm, so now I have to find another bug to fix so I can test it again :)

@asmeurer

git version 1.8.5.2
hub version 1.11.1

@asmeurer

My remote that I pull from is named origin. My github remote is named github. If it would help I could add a remote named asmeurer, though my personal convention is to use a remote named github, so it would be nice to be able to configure this if this is the issue.

It wants to create a pull request against asmeurer:master, instead of sympy:master (sympy is origin).

I pushed the branch to my fork (asmeurer).

I don't know what the upstream configuration is.

Does that help?

@mislav
Admin

Thanks, this is enough info.

The convention in hub is: if "github" remote exists, treat it as if points to the canonical repo, and then treat the "origin" remote as if it points to your fork.

In your repo, it's the reverse. "github" points to "asmeurer" (fork) and "origin" points to "sympy" (canonical). This is what got hub confused about what should be the base of the pull request.

I don't know if I'll change this convention in hub anytime soon. That means you have to manually work around the issue. You have 2 options:

  1. Manually specify pull request head & base via -h & -b flags to hub pull-request
  2. Rename your remotes. For instance, the one pointing to your fork could be named by your username. Or, the one pointing to the canonical repo could be named "upstream".
@asmeurer

Where does that convention come from?

I probably should be using asmeurer instead of github, but I've got a lot of forks, and a git alias for git push github. I think I started using github because the person who taught me git told me to do that. We also have it in the git tutorial we use for people (https://github.com/sympy/sympy/wiki/development-workflow, search for "git remote add"). The reason is that it's easier to give people uniform help if their GitHub remote is always called github, rather than their username.

Would it be possible to provide some kind of configuration to overwrite this behavior. Alternately, I can just change the convention on my local clone and keep it uptodate with this one, assuming that's not too complicated.

@mislav
Admin

Where does that convention come from?

From my limited understanding of popular conventions for naming git remotes.

Right now the precedence of remote names is this: "upstream", "github", "origin", "". The remote most likely to be the canonical repo is "github", then searches the list from the left; and the one most likely to be your fork is "", then searches from the right.

Maybe "github" and "origin" precedence should be switched? It would fix your problems. I would like to see more examples of conventions that various people have while naming remotes to be able to make a decision.

@asmeurer

I don't see why origin isn't first. Generally people clone from the official repo.

@mislav
Admin

That was at first in hub, then tons of people complained that it doesn't match their workflow where they clone their fork as "origin", then add the canonical repo as "upstream".

@asmeurer

I guess a lot of people do that, though it doesn't make sense to me (it's not like you fork every repo you clone). Why not just make it configurable?

@asmeurer

Allowing this to be configured would also allow things like hub remote add github to work.

@ivantsepp

Could we possibly use Github's api for repositories to fetch the parent object if it's a fork (or if it's not, we'll know through this api call). Then, store this information somewhere so hub only needs to make this call once.

@mislav
Admin

@ivantsepp That's an option as well, but I would rather avoid it and fall back to conventions.

I've created a survey and would appreciate if lots of people filled it out, including you.

@asmeurer

I have filled it out (you can guess which response is mine :)

But my guess is that you'll get a large chunk of people doing each incompatible way (assuming you get enough responses).

@asmeurer

Such a config option would also help with the fork command (which I just discovered and is awesome).

@silvenon

Yes, this is very weird for me, because I have to intentionally do it the wrong way. I think a bit of education in the README is in order.

EDIT: Actually, it works completely fine with my origin/<user-name> convention, that's nice.

@dain

Having some heuristics to pick the base is nice, but when they go awry, a configuration option escape hatch is good to have. In my case, I'd kill to have a config option.

@electrum

These conventions happen to exactly match my personal conventions, but it seems really strange for this not to be configurable.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.