Why is it that Pull Requests and Issues share the same numbering sequence on GitHub?

I am curious - what is the reason for the shared numbering sequence between GitHub pull requests and issues?

  • Was it a constraint?

  • Were Pull Requests, in the distant past, just glorified issues? Are they still?

  • Was it an engineering decision or a product decision?

  • Was it designed to allow the quick references (#23) to exist?

Any “GitHub historion” around here that can shed some light on this interesting design choice?

1 Like

I have wondered about this myself severval times and while I dont know if I have the have a real answer but I would like to take a stab at it. If I am wrong hopefully it can lead to some interesting discussions with people more knowledgable than myself. I think you may elluded to it but maybe with a bit more expanding it might make more sense. Apologies in advance that I am gonna ramble with some history/terminology for a bit but promise I will tie all back together at some point.

Technically a pull request is little more than a .patch file, a source url, and a destination URL. This goes into a bit more detail on the nuances but thats the gist of it. In many older open source projects you created a copy of the repo (what people commonly refer to as “forks”), make their changes, and email or upload / submit their patch (as a .patch file) to a maintainer which the maintainer then decides if they want to integrate those changes in.

In more modern git setups which have a lot of tooling built on top of vanilla git because while I love git it does leave plenty of room for ux improvement. In git a pull is how you integrate the remote changes with your local changes. If there is a conflict you must resolve them and push your changes back. The concept of a pull request was likely concieved by those that felt this process was not very user friendly. By requesting someone pull in your changes (even if it really is just a .patch file under the hood) made it I think easier for people to wrap their head around, as they just select a source + destination repository and branch that they would like their changes integrated into. This also changes the mindset that your “fork” may continue to live even if it is decided to not be integrated into the official upstream project, it remains your upstream project and you can do what you want with it. While I have not seen the code that powers popular git providers such as github, gitlab, bit bucket, etc I imagine that their pull request systems are little more than an issue with a .patch file attached (behind the scenes) with some amazing code review tools built on top of it. If you look at the URL for a pull request on github for example you can add a .patch to the URL and you get redirected to which is the actual patch file that informs git how to integrate the changes into the codebase.

Tying this all together because I don’t believe that a pull request (in the way its commonly refered to) is really all that different from requesting a change, help, reporting a bug, etc it was decided that they use the same primatives as an issue even if they use a different URL structure. Keep in mind that this is likely stored in the same database and its likely just an auto incrementing key. This might also be to ensure that you can add the .patch to a pull request and get redirected to a valid file where if you do that with an issue it does not attempt to make a direct to a non existent file.

Anyways those are my speculations as to why but I would love to hear peoples thoughts if this makes sense, if there is a better answer, etc.

1 Like