On Wed, Oct 03, 2018 at 12:12:10AM +0200, Miguel Ojeda wrote: > As I have read, -next is supposed to be a vision of what the merge > window will look like after merging everything, i.e. ideally -rc1. For > that to work for files out-of-tree (like these ones, which are not > maintained by a single tree), changes should be allowed to be stacked > on each other; otherwise, we cannot handle conflicts :-( In general, best practice is to base tree on an -rcX commit. I usually will use something like -rc4 which is after most of the major changes have gone in. This tends to reduce conflicts for most git trees. There are times when a commit in one tree needs to depend on a commit in another tree. What to do depends on the circumstances. One solution is to base one subsystem's git tree on another subsystem's git tree --- *if* that git tree is one that doesn't get rebase. You'll need to talk to the subsystem maintainer to find out whether or not that's the case. But that's actually not a great solution, because what can happen is if the tree A is based on tree B, and there is something in tree B which Linus objects to, tree B won't get pulled. And since tree A depends on tree B, Linus will refuse to pull tree A as well. We recently had a case where a subsystem pull got delayed by a full development cycle because of this. So another solution is to simply evade the problem. If the reason why tree A needs to depend on tree B is that tree B is using some interface which has changed, if it's a minor change, then Stephen will fix it up when he pulls the changes; just as Linus will. If the issue is that there is some common infrastructure which two git tree needs, what will often happen is that just those patches which provide the new infastructure will get put on a branch based on -rcX on one of the git trees. And then the subsystems will base their work on that sub-branche. For example, suppose the file system developers have collectively decided that there should be a new fallocate(2) flag, FALLOC_FL_DONT_RANDOMLY_LOSE (ala RFC 748). The work to define and enable that feature in the VFS layer might be placed on the randomly-lose git branch on xfs.git. And then the xfs and ext4 development branches will both be based on the randomly-lose branch. Yet another solution is to arrange the code changes to avoid needing commits that might conflict. For example, in fs/ext4/ext4.h, I very deliberately did this. /* Until this gets included into linux/compiler-gcc.h */ #ifndef __nonstring #if defined(GCC_VERSION) && (GCC_VERSION >= 80000) #define __nonstring __attribute__((nonstring)) #else #define __nonstring #endif #endif You included a cleanup patch to remove it in your git tree, but it wasn't actually necessary. If there was a merge conflict, it would be simple enough to just drop your cleanup patch, since I had carefully used #ifndef __nonstring... #endif. So the idea was that if someone defined __nonstring somewhere else, it wouldn't break the build with a duplicate #define since it was protected with an #ifndef. I didn't mind that you included a cleanup patch; but I set things up so that it would not be necessary, since often the best way to solve a merge conflict is by avoiding the need for the change (in some other git tree) in the first place. :-) Cheers, - Ted
