Lately, I’ve been having a lot of heretical thoughts questioning standard software development best practice. So my ears perked up when I saw Linus Torvalds ask Chris Mason to NOT to do a merge before sending a pull request:
Gaah. Please don’t do this. Unless it’s a _really_ messy merge, I really do want to do the merge. It’s fine to have an alternate pre-merged branch for me to compare against, but please do that separately.
And it turns out, I agree with the reasons:
And yes, maybe it’s just me showing my insecurities again. I have various mental hangups, and liking to feel like I know roughly what is going on is one of them. Doing the merges and looking at the code that clashes makes me feel like I have some kind of awareness of how things are interacting in the development process.
Sometimes, the only time you’ll do a code review is when you have to – in order to merge the code correctly. Sure, it puts more work on a highly contended resource (the maintainer), but it’s work that needs to be done anyway – reviewing and understanding the code you are integrating.
But don’t expect standard kernel development process to change. You should still merge before asking a maintainer to pull – except when you shouldn’t. Guessing which it is today is all part of the joy of Linux kernel development!