No, Linus Torvalds Never Merges Code On Github!!

Key Takeaways

GitHub is a weird platform that lonus tools for a number of good reasons doesn't particularly like now it's no issue to use it as just any old server to host your code the Linux Cel does exactly that with one of its mirrors but when it comes to the actual tooling on GitHub it can create some kind of weird situations and this is a perfect example of that lonus tvols and the mainline kernel development never ever merges code through the GitHub interface that merge button on GitHub is never ever pressed GitHub can be used as a source for your patches to send up to Linux chel mailing list and there are a bunch of people that do that but GitHub is just treated as any other server that hosts your code but if they never merge through GitHub how do think like this happen merged this merged this merged this merged and the one I showed before this one also merged and to make it even clearer it even says it was merged by torold and this is his actual account this isn't some like impersonation account this is the actual account he has on GitHub but lonus does doesn't press the merge button this was not merged on GitHub now I'm sure that some of these users are operating completely in good faith for example this person here who made a PO request on GitHub and also sent the patches up to the Linux Kel mailing list but others here are likely exploiting a very amusing issue with how GitHub handles what it means for a poor request to be merged but even if you are operating in good faith the way that this happens is exactly the same okay let's talk about how this happens because this is definitely not the first time and definitely won't be the last time that something like this happens again the first thing you need to understand is a GitHub poqu does not actually exist in a GitHub por Quest is a concept entirely existent on G Hub itself and whatever databases they manag now git doeses have a concept known as the request pool this is something you can use and this is something that lionist had wanted the PO request system to be based off of to my understanding it's like partially inspired by it but what GitHub does with a por Quest does not interact with a git request pool and honestly it's fairly likely that you probably haven't interacted with either now the point I'm trying to make here is when you open a PO request when you close a PO request when you do anything with a GitHub pquest nothing special is happening with the underlying git repo obviously if you merge the code through GitHub through a PO request the code is going to get merged into the repo but merging it through that way to git looks exactly the same as just doing a regular git merge git has absolutely no no idea what a GitHub Pro request is all it sees is git commands are being run however in the other direction there are ways to make git interact with GitHub I talked about this in a private video on KL but there are keywords like fixers and closes if you include these alongside an ID you can then make get close a PO request or close an issue or fix an issue but there isn't a key word for mergers when these mer merges are being done this isn't something that is being done from the git side this is being done by ghub implicitly based on other information what's the information you might ask commit hashers if you use get for more than probably 3 minutes you're probably going to be aware that every single commit you make is given a mostly unique identifier just considering how big the address space is it's probably going to be unique this is done to ensure that even if two identical commits are made at different points in a Project's history those can still be addressed individually all of this nicely fits together when you're using GitHub as your development platform you make some code changes locally you then make a PO request on GitHub you discuss the changes and then merge it on GitHub but when GitHub is just being used as a Mir and merges are being done outside of GitHub things can get a bit weird like in the case of the Linux kernel let's imagine a scenario for a second so when you want to send patches to the Linux kernel you do so through the Linux kernel mailing list so let's say that's exactly what you're going to do now before they get merged by Linus tools through git you go and make a pquest on the Linux kernel GitHub and you attach the exact same series of patches that you also sent to the Linux Kel mailing list nobody is going to merge the PO request on GitHub so for now it's just going to sit open and basically just do nothing maybe you'll get some comments on there or some bot messages but it's not going to be merged later on though those patches you sent to the Linux interel maen list get merged by lonus into to the mainline git tree and then the mirror on GitHub is updated to include those patches you sent so now you have a situation where you have a set of patches that are merged into the kernel but you have the exact same set of patches with the exact same set of commit hashes that are sitting here in an open p request and this set of events is exactly the situation that causes this right here to happen you have an open p request with the exact set of patches that would just merged into the project so what should GitHub be doing with this open pquest should it just go and do nothing with it leave it there and let a developer clean it up that might work that's probably the easiest thing to do should they go and Market as closed well closed doesn't really make sense because it hasn't been closed that code is merged into the project so that's probably not the best thing to do either the absolute best possible thing they could do is what Forge Joe and giddy does which is have a manually merged button where you can indicate that this was merg outside of the tool we currently on and that completely resolves the issue but what GitHub decides is to use the merged indicator it uses for something merged on GitHub now this is not an issue if you are acting in good faith like we had this person here this is the person who authored the commits who then also made a PO request and also sent them to the Linux Kel meeting list the poor request they made on GitHub got marked as merged however this is where things get a little bit interesting commit hashes don't change when you clone a repo okay so what if for example you uploaded a copy of the repo to GitHub with the patches that you want to merge and then you open a PO request using your clone of the repo with the patches that you didn't author but still have the exact same commit hashers as the ones that just got merged into the kernel well you can do this where you can make a PO request where you were not involved in developing the code whatsoever if you go to the commits and you look at who actually made it this is a different person it was committed by a different person but GitHub does not care about who the author of the code is all they care about is are the commit hashers the exact same commit hashers if they are if those commit hashes exist in the repo Market as merged basically if you keep an eye on the Linux Kel mailing list and you know that a series of patches is about to be merged into the Kel you can then squat on those patches in a poor request on the Linux Kel GitHub and make it look like you were the person who made those patches and you were the person who got the merged is this a harmful thing to do not really everybody knows the Linux konel GitHub or at least they should apparently there's some people that don't hear the Linux Kel GitHub is not how development of the Kel is done nobody involved in the Kel actually cares about the GitHub outside of being a backup in case they lose all of their other backups what happens on the colonel GitHub doesn't really matter if you go through and look at a lot of the poor quests most of them are complete nonsense just trying to destroy the repo and nothing is really ever done with them because it doesn't really matter now don't go and do this on a project where the developers actually try to use the GitHub tooling and sometimes will merge things outside of GitHub that's annoying and you're probably going to get yourself banned from a project like that but when it's something like Linux this doesn't really hurt anyone is just a fun little side thing that people realize the GitHub interface let you do now I absolutely cannot take credit for realizing you can do this this video is primarily based on a comment and a Mastered on thread left by Hector Martin who you may know from the assah Linux project stuff they've done back in the home brew we days and a ton of other things have had their name attached to now the point of this video is to say that just because something is happening within the GitHub history that doesn't necessarily mean it's actually happening on git GitHub is just a kind of fancy in many ways wonky interface for interacting with Git itself and sometimes the choices they make lead to things that were never really expected to be possible to be very very easy to exploit but what do you think were you aware of this problem before have you ever seen it happen or maybe you were one of the people that have done this on the Linux konel GitHub I would love to know so if you like the video go like the video and if you really like the video and you want to become one of these amazing people over here check out the patreon scrubs lber Linked In the description down below that's going to be it for me and don't be [Music] stupid don't [Music] do something like this