Display more informative `pull-request` error when head repository is not a fork

[purpleidea]

$ hub pull-request 
Error creating pull request: Unprocessable Entity (HTTP 422)
Invalid value for "head"

Just got the above error. Searching found: https://github.com/github/hub/issues/1258 Turns out that was NOT the issue. I figured it out, but this is still a bug.

Let's call the repo foo. It came from user userone. So userone/foo. I cloned it, and github displays a little: forked from userone/foo message.

Fast forward a year, and people abandoned that fork, and someone pushed a new version to newuser/foo. I now write a patch locally. And then I run:

git push purpleidea bug/somefix and then: hub pull-request

I get the above issue. It's not obvious how you can fix this in the webui to point to the new upstream. Also the CLI bails with the above error.

The only fix I could find was deleting my github copy of the repo, and doing a hub fork to push a new copy.

Hopefully this well explained reproducer fixes this.

[mislav]

Thank you for reporting.

Fast forward a year, and people abandoned that fork, and someone pushed a new version to newuser/foo. I now write a patch locally. And then I run:

Just to clarify: is newuser/foo also a fork of userone/foo, or is it a GitHub repo that is a “source” (i.e. not a fork of anything) that just had all the historical commits pushed to?

[purpleidea]

@mislav It all depends on how GitHub internally decides what a "fork is". TBH, if you could answer that question, I'd love to know.

All I can confirm is that the two git trees have the same root commit at least. Whether "newuser" happened because someone either:

1. "clicked the fork button"

or

2. cloned from userone/foo manually, and then pushed to newuser/foo with git

But I don't know which. Should be pretty easy to reproduce this bug following both of these two scenarios and letting us know if it was one or both that causes it. Also if you want to let me know how the "fork from" message heuristic works, I'd love to know!

Thanks

[mislav]

@purpleidea How GitHub decides that something is a fork is not internal. Forks are repositories that were either created by the “Fork” button or explicitly through the API (such as via the hub fork command). Repositories that are forks say “Fork of OWNER/REPO” and thus reference their parent repository in both the web interface and the API.

It's only possible to submit PRs to other repositories if they belong to the same “network”, i.e. that you're either submitting a PR from a fork to the parent repo, or to another fork of the same repo.

1. cloned from userone/foo manually, and then pushed to newuser/foo with git

If that is what happened, then it was expected that you get a 422 validation error, since it's not possible to open a PR from purpleidea/foo to newuser/foo since they aren't in the same network, even though they share most of the same git objects.

[mislav]

Closing because this is an edge case caused by the fact that newuser/foo is not a real GitHub fork of userone/foo and therefore opening pull requests between those repositories is not possible.

[purpleidea]

Disappointed to see this closed. If a "fork" can only be created by using a GitHub specific API (the fork button or API equivalent) then it's an unfortunate proprietary add-on that doesn't make much sense IMO. A real fork should also exist if you git clone a repo and then git push the same repo somewhere. Otherwise I could do this to avoid being labelled as a "fork" and thus convince folks I'm the "original". In case it shouldn't error with 422 if the parent trees are the same.

[mislav]

If a "fork" can only be created by using a GitHub specific API (the fork button or API equivalent) then it's an unfortunate proprietary add-on that doesn't make much sense IMO. A real fork should also exist if you git clone a repo and then git push the same repo somewhere.

You are welcome to write to [email protected] to suggest having this changed on GitHub. This repo is for a command-line tool called hub which interfaces with GitHub via its API. It can only do what is possible to do via GitHub API, and currently it's not possible to submit PRs to another repo that is not in the same “network” as your repo. Hub's issue tracker is not a feature request tracker for GitHub.

[purpleidea]

You are welcome to write to [email protected] to suggest having this changed on GitHub. This repo is for a command-line tool called hub which interfaces with GitHub via its API. It can only do what is possible to do via GitHub API, and currently it's not possible to submit PRs to another repo that is not in the same “network” as your repo. Hub's issue tracker is not a feature request tracker for GitHub.

That's fair, however since this is under the github/ family and AFAICT you're github stuff and obviously very knowledgeable about the issue, perhaps you'd have a better chance communicating this point if you agree. If you don't agree, please let me know!

Thanks!

[luke-jr]

Is there any hope to making this actually work? Over at Bitcoin Core, we're trying to split GUI development into a new bitcoin-core/gui fork, and finding every developer needs to re-fork that to submit pull requests... (And GitHub also won't let us have multiple "forks" under the same organisation, so we can't even workaround it that way!)

[mislav]

@luke-jr I do not believe that this platform restriction will be lifted anytime in the foreseeable future. GitHub pull requests will have to be made from repositories that are explicitly a "fork" of a parent repository. I'm sorry for the inconvenience.

[luke-jr]

How about being able to have multiple "forks" in the same organisation with different names? (I think that used to be possible, but seems to no longer be?)

[mislav]

How about being able to have multiple "forks" in the same organisation with different names?

I don't think that's possible either; sorry! I think that GitHub assumes that a single entity should only ever need at most one fork of something.

Anyway, I hope you understand that this project is merely an API client for GitHub and not a space for platform feature requests. The github.community site might be a better bet: https://github.community/t/feature-request-team-fork-within-organization/1929