Skip to content

pull-request uses wrong base #461

Open
asmeurer opened this Issue Jan 12, 2014 · 20 comments

8 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
GitHub member
mislav commented Jan 12, 2014

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
GitHub member
mislav commented Jan 13, 2014

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
GitHub member
mislav commented Jan 14, 2014

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
GitHub member
mislav commented Jan 14, 2014

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
GitHub member
mislav commented Jan 14, 2014

@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
silvenon commented Feb 1, 2014

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
dain commented Apr 30, 2014

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.

@SpainTrain

👍 and ping-a-doodle-doo on this issue

@benjamine
benjamine commented Jun 13, 2016 edited

well, we don't need to use a convention or heuristics for this, I don't remember when was this added to git, but you can get the upstream branch to merge to from the current branch config,
this is exactly what git rebase does, when called without parameters:

see: https://git-scm.com/docs/git-rebase

If <upstream> is not specified, the upstream configured in branch.<name>.remote and branch.<name>.merge options will be used

that config is set for you when you do git checkout -b mynewbranch upstream/abasebranch. that last parameter defaults to origin/master, but you normally specify upstream/master if you're on a fork, but in some cases you want to specify a different base, eg: git checkout -b hotfix/fixingstuff upstream/production.

I think that would be the ideal way to select the pull request base. (I'm using a shell script to do exactly that, and invoke hub with the right base)

if interested, here's my script to do a pull request to the right base branch, just for reference:
https://github.com/benjamine/paracas/blob/master/git/commands/pr#L18

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.