On Wed, Aug 22, 2018 at 11:23 AM Matthew Wilcox <willy@xxxxxxxxxxxxx> wrote: > > Dan added an entirely new function here: > > http://git.infradead.org/users/willy/linux-dax.git/commitdiff/c2a7d2a115525d3501d38e23d24875a79a07e15e > > which needed to be converted to XArray. So I should have pulled in his > branch as a merge somewhere close to the end of my series, then done a > fresh patch on top of that to convert it? No, it doesn't matter if you rebase on top of a broken branch, or you merge it in. Either way, it's broken and I can't merge your end result. You should simply NOT CARE about other branches. Particularly not other branches that might not even get merged in the first place! You should care about *YOUR* work. You should make sure *your* work is rock solid, and that it is based on a rock solid base. Not some random shifting quick-sand of somebody elses development branch. Sure, then linux-next will give a merge conflict, but at that point YOU DO NOT REBASE OR MERGE. You tell linux-next how to merge it, and mention it to me in the pull request. Because at that point, I have the *choice* of merging just one of the branches or both. Or I can merge them in either order, and test them independently? See how that is fundamentally different from you tying the two branches together and handing me a fait accompli? Yes, yes, sometimes you have to tie branches together because one branch fundamentally depends on the features the other branch offers. But that should be avoided like a plague if at all possible. And it damn well isn't an issue for something like xarray, which has a life entirely independently of libnvdimm (and vice versa), and the conflict was just random happenstance, not some "my changes fundamentally rely on the new features you provide". Linus
