On Thu, May 12, 2016 at 11:06:26AM -0400, Damien Riegel wrote: > On Thu, May 12, 2016 at 10:39:00AM +0200, Oswald Buddenhagen wrote: > > the series is over-fragmented. 6, 7, and 8 definitely should be > > squashed, as the first two patches make no sense whatsoever without the > > third. > > I am used to kernel development, so I like to go from one state to > another through small and atomic changes. To me, it doesn't matter if a > feature takes multiple commits to get implemented as long as the code is > in a working state at every step. Keeping changes as small as possible > makes blame and bisect way more friendly. > i'm perfectly familiar with the concept of atomicity. the thing you're missing is that commits should not only not mix unrelated changes, but that they should also be self-contained/complete. there is no point in adding dead code in several steps as far as bisect is concerned (because the "dead" patches don't test anything except trivial compilation), and for any history-related operations it's actively counterproductive due to adding clutter/overhead, proactively tearing apart related parts, and making it harder to back out whole changes. if the answer to the question "does this commit make sense if not followed by other commits?" is "definitely not", then it's not atomic. or to put it into metaphors: you're supposed to deliver atoms, not quarks.
i for one would do the aforementioned cleanups/unifications separately in several mini-commits, and then introduce mx_ops including the first two callbacks in a single commit (there is wiggle room as to whether open and close should be added separately, but given the total size of the patch the consideration is somewhat pointless). but it's obviously up to kevin to decide that ...
