On Mon, Sep 09, 2024 at 02:09:14PM GMT, Vlastimil Babka wrote: > On 9/9/24 13:02, Christian Brauner wrote: > > On Mon, Sep 09, 2024 at 12:42:53PM GMT, Christian Brauner wrote: > >> On Mon, Sep 09, 2024 at 12:35:37PM GMT, Vlastimil Babka wrote: > >> > On 9/9/24 12:13, Christian Brauner wrote: > >> > > On Mon, Sep 09, 2024 at 11:40:25AM GMT, Vlastimil Babka wrote: > >> > >> > >> > >> > change. Let me check and rollback if that was the case. > >> > >> > >> > >> Thank! > >> > > > >> > > No problem. I promised a stable branch so you'll get one. :) > >> > > > >> > > So I rebased vfs.file onto the previous patches and pushed it out. > >> > > Note that I've merged an additional series into vfs.file but that should > >> > > not matter to you as long as you keep using our shared base. > >> > > >> > > Note, I also pulled > >> > > > >> > > git pull -S slab slab/for-6.12/kmem_cache_args > >> > > > >> > > into vfs.file.slab for a test and that works fine so commit ids should > >> > > be back to their previous state. But please do double-check. > >> > > >> > It seems I'll be fine indeed as our shared base 0f389adb4b80 is back, but > >> > looks like the top-most merge commit 3a3e007d8946 is wrong as it has > >> > 6e016babce7c (the rewrite of 0f389adb4b80) as parent instead, so there are > >> > now duplicated commits in vfs.file itself: > >> > > >> > https://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs.git/log/?h=vfs.file > >> > >> Thanks! Ffs, let me go fix that. > > > > Ok, how's it looking now? > > vfs.file seems ok to me now, but vfs.all has merged the older version of it > thus is not ok yet, as Stephen pointed out. Thanks. Yeah, I hadn't pushed that yet in case something went wrong. Pushed now.
