Enterprise: Creating Pull Request shows incorrect info #123

Closed
HighwayofLife opened this Issue Dec 22, 2011 · 10 comments

Projects

None yet

3 participants

@HighwayofLife

Creating a Fork of a repo then creating a pull request using hub produces some interesting results...
Steps to reproduce:

$ GITHUB_HOST=github.enterprise.com git clone dalewis/repo
Cloning into 'repo' ...
$ cd repo; git checkout -b feature
//... do work
$ git commit -am "example message";git push origin feature
...
To git@github.enterprise.com:dalewis/repo.git
 * [new branch]      feature -> feature
$ git pull-request

The template that appears shows the following...

# Requesting a pull to dalewis:master from highwayoflife:feature
#
# ...

However, "highwayoflife" is my username on github, it's not used in our Enterprise domain. It should be requesting a pull into the source repo (in this example: "org"):

# Requesting a pull to org:master from dalewis:feature
#
# ...

Submitting the pull request produces an error...

Error creating pull request:  (HTTP 401)
Check your token configuration (`git config github.token`)

This is likely because it's trying to create a pull request across domains (github.enterprise -> github)

@HighwayofLife

Explicitly setting the repos produced the same error...

$ git pull-request "Pull request for gitignore" -b org:master -h dalewis:feature
Error creating pull request:  (HTTP 401)
Check your token configuration (`git config github.token`)
@mislav
GitHub member

Thanks for info on this. Creating pull requests on Enterprise is something I still haven't covered with tests and I suspect it might be broken (and you proved it). Will work on this

@mislav mislav closed this in a579aef Dec 25, 2011
@mislav
GitHub member

OK I've improved this a bit. But you have to be aware of something about pull-request before you proceed. You've pushed your feature branch like this:

git push origin feature

You haven't used the -u flag to set up tracking. The default behavior for pull-request on a branch without tracking is to assume you've pushed this branch to a fork under your own name. This makes sense on github.com and dealing with opensource.

However, it doesn't describe your case since you pushed the feature branch to the "origin" remote and not under your fork. So to make pull-request work for you, you have to set up tracking so pull-request can resolve the exact head:

$ git push -u origin feature
$ git pull-request
@HighwayofLife

Thanks @mislav!

It works the same as github.com: Your origin is your fork, upstream would be the source repo.
I'll try again at work this week. If it doesn't work, I'll try it with the -u flag. Thanks!!

@mislav
GitHub member

Err, not sure what you said just now, but in general "origin" should be the source repo and other remotes should point to forks (one of which is your own).

But forks really don't matter here because this is GH Enterprise and we're usually dealing with only one (private) repo. So just set up tracking and you'll be fine. Tracking is always better.

@damianb

@mislav According to what?
github's own forking instructions have origin as the repo that the end-user controls, with remotes being other forks or (if applicable) the source repo (as upstream).

@HighwayofLife

@mislav I meant: By default, when you fork a repo, that is your origin when you do a checkout. If you want to add the source repo, that would be "upstream" (or whatever you wish to call it) according to github's forking instructions. When I create the branch, I'll usually create it as a tracking branch, but that is not always necessary.

The way forking works in Enterprise Github is the same as Github.com

@mislav
GitHub member

@damianb @HighwayofLife Yes I know about GitHub's forking instructions, but those guides are tailored for beginners. Via github's web interface the way you do forks is press the "fork" button and clone the resulting repo. Hub allows you to clone the source repo (e.g. hub clone sinatra/sinatra) and then, when you have your own changes to push, fork with hub fork and push to this new remote named after you. This is the workflow that should be preferred between git users because it works in the best in the long run.

Hub assumes that the "origin" remote always points to the source repo. If this is not the case, hub can't know which remote points to the canonical repo. You then need to use the -b option for hub pull-request to set the base explicitly.

I should document this better.

@HighwayofLife

@mislav That sounds to me like the same workflow documented in the Github forking instructions?
You would fork a source repo, and clone your fork. Make changes to that fork and then create and submit a pull request from there. Or are you saying that you would clone the source repo, make your changes then prior to creating a pull request, you would fork from your local changes? So the forking action in hub is not the same as the [ Fork ] button on Github?

@mislav
GitHub member

Maybe I didn't explain myself well enough.

  1. GitHub's instructions: fork button, then clone your fork. Cons: you're forking before you have something to contribute; and the "origin" remote doesn't point to canonical repo.
  2. The hub way: clone canonical repo, then use hub fork. Pros: you fork only when you're ready to push something; and "origin" points to canonical so tools like hub can use that info to put stuff in the right context.
@aaronj1335 aaronj1335 added a commit to aaronj1335/hub that referenced this issue May 20, 2013
@aaronj1335 aaronj1335 escape branch name as uri component in hub browse
if your branch name contains any characters that are significant to
uri's, then `hub browse` sends you to a 404 page. this change uses
`CGI.escape` to properly encode that when constructing the URL.

an example of where this is a problem is if you use topic branches named
by issues stored in an issue tracker, i.e. `fix-something-#123`
indicating what you're working on and the corresponding issue number.
b62db15
@aaronj1335 aaronj1335 added a commit to aaronj1335/hub that referenced this issue May 20, 2013
@aaronj1335 aaronj1335 escape branch name as uri component in hub browse
if your branch name contains some characters that are significant to
uri's, then `hub browse` sends you to a 404 page. this change uses
`CGI.escape` to properly encode that when constructing the URL.

an example of where this is a problem is if you use topic branches named
by issues stored in an issue tracker, i.e. `fix-something-#123`
indicating what you're working on and the corresponding issue number.
6ccb758
@aaronj1335 aaronj1335 added a commit to aaronj1335/hub that referenced this issue May 20, 2013
@aaronj1335 aaronj1335 escape branch name as uri component in hub browse
if your branch name contains some characters that are significant to
uri's, then `hub browse` sends you to a 404 page. this change uses
`CGI.escape` to properly encode that when constructing the URL.

an example of where this is a problem is if you use topic branches named
by issues stored in an issue tracker, i.e. `fix-something-#123`
indicating what you're working on and the corresponding issue number.
2a3e69f
@mislav mislav added a commit that referenced this issue May 25, 2013
@aaronj1335 aaronj1335 escape branch name as uri component in hub browse
if your branch name contains some characters that are significant to
uri's, then `hub browse` sends you to a 404 page. this change uses
`CGI.escape` to properly encode that when constructing the URL.

an example of where this is a problem is if you use topic branches named
by issues stored in an issue tracker, i.e. `fix-something-#123`
indicating what you're working on and the corresponding issue number.
b00aa03
@mislav mislav added a commit that referenced this issue Dec 18, 2013
@aaronj1335 aaronj1335 escape branch name as uri component in hub browse
if your branch name contains some characters that are significant to
uri's, then `hub browse` sends you to a 404 page. this change uses
`CGI.escape` to properly encode that when constructing the URL.

an example of where this is a problem is if you use topic branches named
by issues stored in an issue tracker, i.e. `fix-something-#123`
indicating what you're working on and the corresponding issue number.
8652bf9
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment