Hi Zhaoming, On Fri, Nov 8, 2024 at 11:01 AM Samuel Thibault <samuel.thiba...@gnu.org> wrote: > Here as well this breaks the build since at this point of the series you > haven't added rtc.h yet. Better just merge all the patches.
To expand on what Samuel says, the point is that the repo is expected to build successfully if you check out any specific Git commit. This is helpful for using 'git bisect' in particular to catch regressions [0], but is also generally a good practice. You might call it a part of Git hygiene. [0] which now that I'm typing this doesn't sound like a good enough reason to go through the pain of ensuring that every single commit builds... So not only are you expected to split your diff into a set of reasonably-sized, self-sufficient, reviewable patches; you should also consider the dependencies between your changes, and commit them in the right order. If you're adding an entire new component, like the new server here, and it is reasonably small, it makes sense to just do the whole thing in a single patch. But if you were adding a large new subsystem to Linux for example, you could be asked to split it into individual patches, so it could be reviewed step-by-step, while still keeping each of those steps functional (i.e. at least building successfully). You might add just the bare essentials/stubs which are enough to build *something* in the first patch for example, and then keep adding functionality in subsequent patches. But for your case here, you can just squash the patches into one. Sergey
