On Wed, Jul 17, 2024 at 11:53:04AM GMT, Linus Torvalds wrote: > On Sun, 14 Jul 2024 at 18:26, Kent Overstreet <kent.overstreet@xxxxxxxxx> wrote: > > > > Hi Linus - another opossum for the posse: > > (The kernel naming tends to be related to some random event, in this > case we had a family of opossums under our shed for a couple of > months) Oh cute :) > > bcachefs changes for 6.11-rc1 > > As Stephen pointed out, all of this seems to have been rebased > basically as the merge window opened, so if it was in linux-next, I > certainly can't easily validate it without having to compare patch ids > etc. DON'T DO THIS. I had to give this some thought; the proximate cause was just fat fingering/old reflexes, but the real issue that's been causing conflicts is that I've got testers running my trees who very much /do/ need to be on the latest tagged release. And I can't just leave it for them to do a rebase/merge, because a) they don't do that, and b) then I'm looking at logs with commits I can't reference. So - here's how my branches are going to be from now on: As before: - bcachefs-testing: code goes here first, until it's passed the testing automation. Don't run this unless you're working with me on something. - for-next: the subset of bcachefs-testing that's believed to be stable - bcachefs-for-upstream: queue for next pull request, generally just hotfixes But my master branch (previously the same as for-next) will now be for-next merged with the latest tag from your tree, and I may do similarly for bcachefs-for-upstream if it's needed. As a bonus, this means the testing automation will now be automatically testing my branch + your latest; this would have caught the breakage from Christoph's FUA changes back in 6.7. > Also, the changes to outside fs/bcachefs had questions that weren't answered. Yeah, those comments should have been added. Waiman, how's this? -- >8 --
