Linus Torvalds Is Sick Of Useless Git Merges

Key Takeaways

do you know what time it is it is time once again for a quarterly lioness 12 volt rant and as is generally the case it's about holding the Linux kernel up to really high development standards when we see the kernel from the outside whether that's as a desktop user a server user or anything else out there we see the result of that development we see 6.0 6.1 6.2 and anything else out into the future but when you're dealing with thousands upon thousands of commits every single release certain practices need to be followed to ensure things go over in a relatively smooth fashion and maintainers retain their sanity one such practice is how you handle mergers so recently there was a kernel patch set ready to merge by a developer called keys cook hi Linus please pull these hardening updates for 6.3 rc1 Beyond some specific load pin ubisan and fortify features there are blah blah blah doesn't really matter the specifics aren't too important the important part is how the commits were handled now overall it was mostly all well and good with the exception of a couple of these commits so I've pulled this but while looking at it I see Commit This string merge Branch for Linus hardening into four next slash hardening and that one line of short log part is literally the whole commit message I've said this before and apparently I need to say this again if you cannot be bothered to explain why a merge exists then that merge is buggy garbage by definition when we are talking about a project on the scale of the Linux kernel lack of documentation in and of itself is a bug we are not talking about some you know 500 line 10 terminal app where if there's something wrong with it you can read the entire code base in like 10 15 minutes maybe 20 minutes if you're a bit slow we're not talking about a couple thousand Lane application which probably should be documented but you can work around it not being so we are talking about a project that has millions of lines of code with thousands of lines being changed every single update if there ever happens to be a problem commit and that commit needs to be reverted which does happen from time to time it's incredibly useful to have that commit documented with both a short log message that explains what is being done and if relevant a longer description for those bigger commits that might need them now obviously if you're averting a commit you should be reading the code to find out exactly what it's doing so you know like what problem it was actually causing it and how you might go on address asset however having a good description there gives you a better idea of what you're looking at without having to First go and examine the code this really should be a rule that every single developer should take to heart I'm not just putting random words together in a random order now obviously that's an exaggeration that's hyperbole this isn't random words in a random order if you've ever used git before if you've ever used remotes like GitHub and gitlab you've probably seen commits like this plenty of times what is being done is merging the work from one branch into another Branch this is a totally normal function and for most repos is a totally normal way to name the commit but why are you merging work from one branch into another Branch all this says is the work is being merged but for what purpose what is it doing what is it adding was there any other way you could do it why is it named like this I repeat if you cannot explain a merge then just don't do it it's really that simple there is absolutely never an excuse for mergers without explaining why those merges exist in this case I really think that merge should not have existed at all and the lack of explanation is because there is no explanation for it but if there was a reason for it then just state it and make that merge commit look sensible because right now it just looks entirely pointless and I literally detest pointless mergers they only make the history look worse and harder to read now unless you're developing everything on a single Branch or before you send the code up to the kernel you throw everything away and rebuild a very clean commit log obviously you're going to have mergers inside of your development firstly name those merge as well so people know why they exist and what they're actually doing secondly you don't need to leave traces of a merge behind what you can do instead is have a read of the get documentation and you'll find things like rebase this will basically take the commits from one branch and stick them on another and this even lets you take multiple commits that don't need to be separate at all and then squash them down into fewer commits overall and there are a lot of videos out there a lot of guides on how to do exactly this and how to generally effectively use git and seeing as though lioness is the one who made git he expects that everybody involved in his project is using it in an effective way as well and one of those ways is handling merge commits in a sensible way this Dev was definitely not looking to start a fight with Linus 12 volts and said this in response once okay understood this was a merge of the fixes for 6.2 I'll explain that more clearly in the log from now on this would still be a better message than what was there but is still a fairly surface level description either way he says he's going to explain it better in the future totally fair now Linus also did continue he's used this as a platform to basically further explain with a lot to go on here uh why this is such a big deal if you want to go check out the full thing for yourself but we're just gonna skim over it for example one reason why people do these kinds of mergers as in the merge he's complaining about is because they are starting to do some new development for the next release and that new development then depends on fixes or infrastructure that they had in another Branch like a four Linus branch in case of fixes so then they mindlessly just do a git merge on that branch and the end result looks very much like what you sent me in a slightly better World they then actually write an explanatory commit message for that merge knowing that I ask for them and the merge commit message ends up being exactly that kind of slightly odd now I'm starting a new thing that depends on the fixes I already Upstream so I'm merging that branch which while certainly better than no explanation at all sounds a bit odd doesn't it yeah add a few details on just what you depend on and why and it gets much better but it's all going to be a bit of hand wavy about future work that you haven't even written yet and that will then maybe make you then go ah I'm doing things wrong because the nice Gateway through that kind of thing is to actually realize oh I'm starting new work that depends on the fixes I already sent Upstream so I should just make a new topic branch and start at that point that I needed and then once you've done all the new work that depend on that state only at that point do you merge the topic Branch instead of having to Waffle about future work depends on this feature there was in another Branch so I'm merging this Branch your merge commit now makes sense you're not merging some old state in order to create new features you are literally just merging the completed feature and the most important takeaway for why liners care so much is this because we have a very real history where people did mindlessly daily back mergers like this just because with absolutely no Rhyme or Reason Just because they want to start each day with the most recent bass and it really gets very ugly the development history can go from a dag that actually visualizes the different development streams nicely to a spider nest Maze of inexplicable mergers very quickly lioness is very proud of the fact that the Linux kernel has very clear guidelines and developers are expected to follow them he said in the past how he's really happy that the Linux kernel is basically the gold standard of how to run a fast project how to run git how to actually do development in this fashion in a really productive and effective way but what do you think do you think Linus cares too much do you think the way that most git reapers are run is totally fine it works for a small project so it's probably going to work on a large scale as well I would love to know your thoughts so if you liked the video remember to go and like the video and if you really like the video and you want to become one of these amazing people over here go check out my patreon Scrabble linked down below that's gonna be it for me and [Applause] [Music] thank you [Music]