5 ms·

Gotcha, that makes sense. Thanks, I've always been curious about how the Linux kernel works.

• kragen 1y ago
  I may not be the best source for information, not having written anything worth contributing myself.
  • scuff3d 1y ago
    Well I appreciate it none the less. I think the point I always get stuck on is how small is "small" when we're talking about commits/patches. Like if you're adding a new feature (to anything, not necessarily the Linux Kernel), should the entire feature be a single commit or several smaller commits? I go back and forth on this all the time, and if you research you're gonna see a ton of different opinions. I've seen some people argue a commit should basically only be a couple lines of code changed, and others argue it should be the entire feature. You commonly hear Linus talk about commits/patches having very detailed descriptions attached to them. I have trouble believing people would have time for that if each commit was only a few lines, and larger features were spread out over hundreds of commits.
    • kragen 1y ago
      When I'm reviewing commits, I find it useful to see refactoring, which doesn't change behavior, separated from functional changes, and for each commit to leave the tree in a working, testable state. This is also helpful for git bisect. Often, a change to a new working state is necessarily bigger than a couple of lines, or one of the lines has to get removed later. I don't want to have to say, "Hmm, I wonder if this will work at the end of the file?" and spend a long time figuring out that it won't, then see that the problem is fixed later in the patch series. Other people may have other preferences.