On Tue, Nov 05, 2024 at 08:11:52AM -0700, Jens Axboe wrote: > On 11/5/24 8:08 AM, Theodore Ts'o wrote: > > On Tue, Nov 05, 2024 at 05:52:05AM -0700, Jens Axboe wrote: > >> > >> Why is this so difficult to grasp? It's a pretty common method for > >> cross subsystem work - it avoids introducing conflicts when later > >> work goes into each subsystem, and freedom of either side to send a > >> PR before the other. > >> > >> So please don't start committing the patches again, it'll just cause > >> duplicate (and empty) commits in Linus's tree. > > > > Jens, what's going on is that in order to test untorn (aka "atomic" > > although that's a bit of a misnomer) writes, changes are needed in the > > block, vfs, and ext4 or xfs git trees. So we are aware that you had > > taken the block-related patches into the block tree. What Darrick has > > done is to apply the the vfs patches on top of the block commits, and > > then applied the ext4 and xfs patches on top of that. > > And what I'm saying is that is _wrong_. Darrick should be pulling the > branch that you cut from my email: > > for-6.13/block-atomic > > rather than re-applying patches. At least if the intent is to send that > branch to Linus. But even if it's just for testing, pretty silly to have > branches with duplicate commits out there when the originally applied > patches can just be pulled in. I *did* start my branch at the end of your block-atomic branch. Notice how the commits I added yesterday have a parent commitid of 1eadb157947163ca72ba8963b915fdc099ce6cca, which is the head of your for-6.13/block-atomic branch? But, it's my fault for not explicitly stating that I did that. One of the lessons I apparently keep needing to learn is that senior developers here don't actually pull and examine the branches I link to in my emails before hitting Reply All to scold. You obviously didn't. Maybe the lesson I really need to learn here is that none of this constant pointless aggravation in my life is worth it. --D > > I'm willing to allow the ext4 patches to flow to Linus's tree without > > it personally going through the ext4 tree. If all Maintainers > > required that patches which touched their trees had to go through > > their respective trees, it would require multiple (strictly ordered) > > pull requests during the merge window, or multiple merge windows, to > > That is simply not true. There's ZERO ordering required here. Like I > also mentioned in my reply, and that you also snipped out, is that no > ordering is implied here - either tree can send their PR at any time. > > > land these series. Since you insisted on the block changes had to go > > through the block tree, we're trying to accomodate you; and also (a) > > we don't want to have duplicate commits in Linus's tree; and at the > > same time, (b) but these patches have been waiting to land for almost > > two years, and we're also trying to make things land a bit more > > expeditiously. > > Just pull the branch that was created for it... There's zero other > things in there outside of the 3 commits. > > -- > Jens Axboe
